| View previous topic :: View next topic |
| Author |
Message |
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
| PIC hanging on delay_ms call |
 Posted: Tue Feb 22, 2011 5:05 am |
 |
|
Hi All,
I am having a strange problem when I call the delay_ms function, when I call this function, the code stops running (in debug mode) and I then have to press RUN (play button) to continue running the code.
I am using a PIC18F2520 with CCS compiler PCH v4.114. I am using the MPLAB ICD3 debugger and using the MPLAB IDE v8.60 for debugging.
The code is pretty simple, when I see the input on RC0 go low, I run a sub routine to check the health of one of the devices connected to the inputs.
The ouput PIN RC1 is connected to a relay which then switches off the device and I check to see if the input then switches off. Then I switch the output ON again and check that the input also switches on. If this sequence is followed then I know that the device and all cabling in between is healthy.
I allow a delay between switching the output on/off to allow the device to switch off/on completely.
Problem is, whenever this subroutine is called, the code stops running at the #use delay(clock=8000000) line.
Any ideas on what may be causing this? Am I doing something wrong?
The code is:
| Code: |
//--------------------------------------------------------------------------------
// Set PIC type and settings
//--------------------------------------------------------------------------------
#include <18F2520.h>
#device ICD=TRUE //disable this for production as it removes code protection
#FUSES INTRC_IO //Internal RC Osc, no CLKOUT
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES BROWNOUT //Enable brownout reset
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOPUT //No Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES DEBUG //Debug mode for use with ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES MCLR //Master Clear pin enabled
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOWRTB //Boot block not write protected
#use delay(clock=8000000)
//--------------------------------------------------------------------------------
// define inputs and outputs
//--------------------------------------------------------------------------------
#define IP_KSW_O PIN_C0
#define IP_PC PIN_C5
#define OP_CHK_PC PIN_A1
#define OP_BUZZER_OB PIN_A4
//--------------------------------------------------------------------------------
// define global variables
//-------------------------------------------------------------------------------
//Global variables
int In_KSW_Open = 1;
int pc_healthy = 0;
void check_photocell(void)
{
int status1 = 0;
int status2 = 0;
//Turn off the transmitter
output_high(OP_CHK_PC);
delay_ms(250);
//Check if input can see PC as off
if (input_state(IP_PC) == 1)
{
status1 = 1;
}
else
{
status1 = 0;
}
//Turn on the transmitter
output_low(OP_CHK_PC);
delay_ms(250);
//Check if input can see PC as on
if (input_state(IP_PC) == 0)
{
status2 = 1;
}
else
{
status2 = 0;
}
//determine health of PC
if((status1 == 1) && (status2 == 1))
{
pc_healthy = 1;
}
else
{
pc_healthy = 0;
}
}
//--------------------------------------------------------------------------------
// initialise the PIC
//--------------------------------------------------------------------------------
void initialise_pic(void)
{
// Setup ports // 76543210
SET_TRIS_A( 0xC0 ); // 11000000 1 - Input, 0 - Output
SET_TRIS_B( 0xFF ); // 11111111 1 - Input, 0 - Output
SET_TRIS_C( 0xFF ); // 11111111 1 - Input, 0 - Output
// Setup Internal Clock
setup_oscillator(OSC_8MHZ);
}
void main()
{
initialise_pic ();
while(1)
{
In_KSW_Open = input(IP_KSW_O);
if(In_KSW_Open == 0)
{
check_photocell();
}
}
}
|
Thanks in advance for any help you may be able to give me. I am at the scratch my head stage now!
Gurdeep |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Tue Feb 22, 2011 8:11 am |
|
|
Any debug or simulator will NOT run at the normal speed, so delays will be longer. How much, you'll have to run a simple test to see, or maybe others here will know.
I do not need or use 'debuggers' or 'simulators' as they do NOT emulate the real world. |
|
|
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
|
| Posted: Tue Feb 22, 2011 8:26 am |
|
|
Hi Temtronic,
Thanks for your reply. I am not relying on the debug to be accurate timing wise, it is just helpful sometimes to be able to see the values of some of the variables when trying to resolve bugs.
I am not too precious on the timing, so even if the delay takes longer it is not a problem when I am trying to fix bugs, not ideal, but still better than not being able to step through the code.
Just a bit confusing as to why it would just stop running. I have used the delay_ms call in other blocks which I have stripped away and it worked fine on those, it is just something about the 'check_photocell' block that is causing the code to stop running and I cannot see why this is happening.
Thanks
Gurdeep |
|
|
rnielsen
Joined: 23 Sep 2003
Posts: 852
Location: Utah
|
|
| Posted: Tue Feb 22, 2011 10:18 am |
|
|
I can't say if this will help but I, once, had a similar problem. I did not have any ISR's defined and didn't think I needed to since I wasn't using any and my program would 'hang' on a delay() statement. When I defined each ISR then the program no longer got stuck. So, you might want to define all of your ISR's and see if that helps.
Might be a shot in the dark but who knows, you just might hit the target with it.
Ronald |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Tue Feb 22, 2011 10:46 am |
|
|
| Quote: | | Problem is, whenever this subroutine is called, the code stops running at the #use delay(clock=8000000) line. |
This would imply that the pic is getting stuck in some hidden code (built in functions) which you do NOT appear to have OR it is resetting.
Not sure about this but you don't have a WDT or NOWDT fuse setting. Could be the WDT is enabled and resetting your pic.
I thought the debugger disabled the WDT when running though.
Try #FUSES NOWDT |
|
|
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
|
| Posted: Tue Feb 22, 2011 10:57 am |
|
|
Hi Wayne,
Thanks for replying.
| Quote: |
I thought the debugger disabled the WDT when running though.
Try #FUSES NOWDT
|
I tried with the NOWDT fuse as well but it did not make a difference. I think you are right, it must be something to do with the delay_ms function, I might just be using it wrong, but it is not immediately obvious to me why the way I have used it is causing problems.
Gurdeep |
|
|
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
|
| Posted: Tue Feb 22, 2011 11:00 am |
|
|
Hi Ronald,
Thanks for your reply.
| Quote: |
So, you might want to define all of your ISR's and see if that helps.
|
Did you have to define every possible ISR (all timers, ccp, etc)?
Gurdeep |
|
|
Douglas Kennedy
Joined: 07 Sep 2003
Posts: 755
Location: Florida
|
|
| Posted: Tue Feb 22, 2011 11:45 am |
|
|
Try using only the setup_oscillator(OSC_8MHZ); and a very simple flash led
program using delay_ms to set the flashing freq.
Perhaps the setup_oscillator(OSC_8MHZ); never gets the osc going .. this setup code comes in as boilerplate from CCS after the fuses are set by you
and maybe a conflict is the issue. |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Feb 22, 2011 11:48 am |
|
|
| I see the code executing correctly in MLAB SIM. Did you try it, too? |
|
|
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
|
| Posted: Tue Feb 22, 2011 11:49 am |
|
|
Hi All,
I also emailed CCS support about this issue and this was the response I got
| Quote: | | Try disconnecting the relay. A noise pulse on B7 can cause the debugger to act like it hit a breakpoint. EMI from the relay might be the cause. |
I then disconnected the device (a presence detector) from the output and ran the code and it worked fine, no stopping. As soon as I reconnected the device, then the code would stop again. I put a scope on the output and there is a bit of noise but not that much, but obviously it is enough for the ICD3 to think there is a breakpoint there.
Has anyone come across noise problems on the PGD line (RB7 on my PIC) and any suggestions on how to make the PGD line more immune to noise?
Thanks
Gurdeep |
|
|
sseidman
Joined: 14 Mar 2005
Posts: 159
|
|
| Posted: Tue Feb 22, 2011 2:52 pm |
|
|
| Drive your relay through a FET, and be careful with your grounds. You might also try pulling the output high through a resistor. |
|
|
gurdeepsembi
Joined: 22 Dec 2010
Posts: 14
Location: UK
|
|
| Posted: Wed Feb 23, 2011 8:12 am |
|
|
Hi all,
Managed to find the cause of the problem and a fix for it. It appears that when the relay connected to my output RC1 (driven with a transistor) was switching the device on/off, noise was picked up on the PGD line which made the debugger think it had hit a breakpoint and so the code stopped.
Because the device was switched on/off and then I had a delay in the code, the breakpoint always happened during the delay and so the code stopped there.
I then put a 22uF capacitor between the NO contact of the relay (to which the device's power line was connected) and 0V and this solved the problem. I have had the relay switching power to the device rapidly without the code stopping.
Thanks to everyone for your help, much appreciated!! 
Gurdeep |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Feb 23, 2011 9:27 am |
|
|
CCS support did a good job in this case. I wish, they would be just as effective when dealing with compiler bugs.
Now, I got a PCD bug fixed in V4.119, that I reported in November 2008, 27 month ago. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Feb 23, 2011 8:11 pm |
|
|
| temtronic wrote: | Any debug or simulator will NOT run at the normal speed, so delays will be longer. How much, you'll have to run a simple test to see, or maybe others here will know.
I do not need or use 'debuggers' or 'simulators' as they do NOT emulate the real world. |
That's not quite true.
I use an ICD3 and have had a scope hooked up and can TELL you that delay_ms and other things concerning time run exactly the same in debug vs release mode.
That doesn't mean a breakpoint won't slow you down or possibly stop peripherals (that's an option in the debugger settings)...
But delay_ms(1000) will take the same time with or without debug mode.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Feb 23, 2011 8:12 pm |
|
|
| gurdeepsembi wrote: |
Because the device was switched on/off and then I had a delay in the code, the breakpoint always happened during the delay and so the code stopped there.
I then put a 22uF capacitor between the NO contact of the relay (to which the device's power line was connected) and 0V and this solved the problem. I have had the relay switching power to the device rapidly without the code stopping.
|
Did you put a diode across your relay to prevent the inductive spike when the relay is de-energized?
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
