WDT Tracking down

[E_Blue]

I'm using CCS C Compiler 5.048, PIC18F67J50.

My fuses

[temtronic]

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

[E_Blue]

I don´t know how to know which µC have and which haven´t that feature.
_________________
Electric Blue

[temtronic]

You _should_ be able to go to Microchips 'select a PIC' website and choose that as an option ? maybe ??

Jay

[Ttelmah]

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.

[temtronic]

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

[Ttelmah]

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...

[E_Blue]

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

[Ttelmah]

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:

[E_Blue]

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 Break­points).

I confused now.
_________________
Electric Blue

[temtronic]

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

[Ttelmah]

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: