View previous topic :: View next topic |
Author |
Message |
E_Blue
Joined: 13 Apr 2011 Posts: 417
|
WDT Tracking down |
Posted: Tue Jan 19, 2016 9:14 am |
|
|
I'm using CCS C Compiler 5.048, PIC18F67J50.
My fuses
Code: |
#fuses HSPLL,PLL2,NOCPUDIV,NOIESO,NOFCMEN,STVREN,CCP2E7,WDT,WDT4096,PROTECT |
I was debugging with ICD3 and get a WDT Timeout.
Now I want to know where the code get stucks, I make a little research on Internet and find that some chips have a WDT interrupt debug vector.
Quote: | In MPLABX Debugger
Debug>NewBreakpoint->Breakpoint Type->Event->Break when watchdog timer has expired |
I'm using MPLAB IDE v8.92 and found the same at Event Breakpoints , but is greyed, like disabled feature.
This µC doesn't have that feature, do I need another debugger or is MPLAB unavailable feature and need to use MPLABX? _________________ Electric Blue |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Tue Jan 19, 2016 11:49 am |
|
|
hmm... This µC doesn't have that feature
You've answered your own question.. you need a differenet PIC if you want a WDT interrupt debug vector.
NO new development programs or hardware will help, you need a different PIC.
Kinda like a car NOT having a trailer hitch. Trading in your boat trailer for a dump trailer doesn't work, neight hookup to the car, you need a new car( one with a hitch !).
Jay |
|
![](templates/subSilver/images/spacer.gif) |
E_Blue
Joined: 13 Apr 2011 Posts: 417
|
|
Posted: Wed Jan 20, 2016 7:56 am |
|
|
I don´t know how to know which µC have and which haven´t that feature. ![Sad](images/smiles/icon_sad.gif) _________________ Electric Blue |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Wed Jan 20, 2016 8:00 am |
|
|
You _should_ be able to go to Microchips 'select a PIC' website and choose that as an option ? maybe ??
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Wed Jan 20, 2016 8:27 am |
|
|
The primary 'point' of the watchdog, is to recover the chip if it has for some reason fundamentally stopped doing as it should, and so the watchdog will always normally reset the chip.
The exception to this is chips that have the PTG module. On this the module can accept as one of it's triggers the PTGSWT input (a separate watchdog), and use this as a trigger. This is a programmable state machine that can accept a number of trigger inputs, so you can program it to do particular jobs when certain events occur. One of these events can be it's own dedicated watchdog. So it can (for instance) reset a particular output if no activity occurs in a particular time. The PTG WDT, can trigger an interrupt.
This is independant of the main watchdog.
The "Break when watchdog timer has expired" option is dependant on the debugger used. Only some devices like 'RealICE" support this.
The way to find what is happening, is use a breadcrumb.
Have a global variable. Initialise it to 0, and then throughout your code have it being changed to values reflecting where you have got to. Add a breakpoint at the reset, and when this is reached, look at what the last value was. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Wed Jan 20, 2016 8:42 am |
|
|
hmm 'breadcrumb'. Neat terminology !! Reminds me of the POST codes on a PC decades ago... The POST card would display a number for each test,when it 'hung' you knew which test failed.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Wed Jan 20, 2016 9:46 am |
|
|
Intel motherboards still do it.
They have literally hundreds of codes on some (server boards), with a combination of a hex display, and about 15 LED's reflecting the status of several peripherals.
Some of the non server boards get 'silly', with a surface mount LED 'skull' in the motherboard, which flashes various parts according to what is going on... |
|
![](templates/subSilver/images/spacer.gif) |
E_Blue
Joined: 13 Apr 2011 Posts: 417
|
|
Posted: Tue Jan 26, 2016 7:14 am |
|
|
Thanks, for answering, the device didn't reset by WDT again since that time but I will take the "breadcrumb" method in account. _________________ Electric Blue |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Tue Jan 26, 2016 9:14 am |
|
|
One thing I'd look at is temperature....
There are two obvious possibilities:
1) The code did get stuck, and the watchdog was 'genuine'.
2) The watchdog just was not refreshed quickly enough.
Now your chip has a relatively accurate watchdog (nominal period of 3.4 to 4.6uSec), however this is still a nearly +/-20% change. The timing depends on supply voltage and temperature. If at any point your timing might be a bit 'close' on reaching the refresh, then it might simply be that you stepped over the margin at the particular temperature/supply voltage you were using.
However I'm also puzzled by your comment about using ICD3. When the ICD is in use, the watchdog by default will always be off. The compiler will do this automatically. In the debugger limitations from Microchip, you have the note for the ICD3:
Quote: |
Debugger Limitations
The Watchdog Timer (WDT) cannot be used when debugging.
|
Problem is that the watchdog timer is independant of the CPU itself, and will not stop if the debugger stops the code, or if the debugger delays the code. So if enabled, it will timeout when debugging. |
|
![](templates/subSilver/images/spacer.gif) |
E_Blue
Joined: 13 Apr 2011 Posts: 417
|
|
Posted: Tue Jan 26, 2016 1:28 pm |
|
|
That is strange, I been debugging with the WDT enabled until last week, the only warning that I get is about disable the code protection bit.
Now I disabled WDT in CONFIG and activate the WDT by using SWDTEN bit by software.
On MPLAB IDE Help says
The Watchdog Timer (WDT) cannot be used when debugging unless the device is set to “Break on Watchdog Timer” (Debugger>Breakpoints, Event Breakpoints) .
And I even using SLEEP instruction while in the same help states.
The SLEEP instruction cannot be used when debugging unless the device is set to “Break on SLEEP Instruction” (Debugger>Breakpoints, Event Breakpoints).
I confused now. ![Confused](images/smiles/icon_confused.gif) _________________ Electric Blue |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Tue Jan 26, 2016 2:36 pm |
|
|
some points....
rule #1 you cannot use WDT if in 'debug ' mode
rule #2 MPLAB default for 'build configuration' is 'debug'
rule #3 You MUST set 'build configuration' to 'release' and recompile(build) BEFORE blasting PIC with your code.
Now you can set the MPLAB default to 'release' so you don't run into this in the future.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19367
|
|
Posted: Wed Jan 27, 2016 2:51 am |
|
|
There is another thing here.
The 'IDE' help, is generic for the IDE. Separately there are limitations for the individual ICD devices involved.
The one being quoted from the IDE:
Quote: |
The Watchdog Timer (WDT) cannot be used when debugging unless the device is set to “Break on Watchdog Timer” (Debugger>Breakpoints, Event Breakpoints) .
|
Is the overall limitation for the IDE.
The one I quote:
Quote: |
Debugger Limitations
The Watchdog Timer (WDT) cannot be used when debugging.
|
Is for the ICD3.
So for the ICD3, the watchdog cannot be used at all. Some ICD devices (RealICE for example), allow you to have 'Break on watchdog', and for these the watchdog can be used if this is enabled. |
|
![](templates/subSilver/images/spacer.gif) |
|