If the chip has to be woken by the WDT and a external interrupt! what the worst that can happen if you clrwdt after the wake up??
Hi,
If i understand you right, if the chip wakes up and then clrwdt, that's fine, it's what happens next that i think is the problem.
If the program does not get another clrwdt before the wdt timeout period, i think the wdt resets the chip back to address 0000.
If there were any registers initialized then they will get initialized again, which would clear all the data read from anything or generated internally, which of course would only work in some applications.
The max prescaler value is 128 which gives a wdt timeout period of about 2.3 seconds, but we have to realize that is not an exact time period it could vary considerably according to the data sheet. That's part of the issue, but the main issue is that say we have the following pseudo code:
initialize [ox0000]
startmain [ox0050]
LoopA
clrwdt
codeblock[0x0060] [takes from 1 to 3 seconds to execute the entire code, modifies reg AK]
sleep [about 2 seconds of sleep]
nop
clrwdt
goto loopA
In the above, a register AK is initialized to 0x00, the prescaler is set to max which is 128 which is about 2 seconds. Then start main.
We enter the loop, clrwdt, then exectute the code block, then sleep. When it wakes up it does a clrwdt, then loops again.
But that only works if codeblock takes from 1 to near 2 seconds to execute.
If codeblock takes 3 seconds, this is what happens:
Enter loopA, clrwdt, wdt timer starts. codeblock takes 3 second, but never gets to finish because wdt times out and causes a reset after about 2 seconds, so it jumps back to initialize, which makes register AK zero again when it should have the last value given to it in codeblock.
That's the way i understand it anyway. What happens in the MPLAB IDE is the wdt keeps timing out and stopping the code execution at some unusual place and a warning comes up on the screen that states that the wdt timed out. That's if the time between clrwdt instructions is longer than the wdt timeout period. If i insert more clrwdt's i get no interruptions, unless of course it reaches a sleep instruction.
What this means for longer delay function calls (like maybe 500ms several times is that just before the call i have to do a clrwdt, but if the delay is longer than about 1.5 seconds i have to incorporate a clrwdt right in the delay loop so it keep clearing it to prevent the reset.
It's too bad they did not make that an interrupt vector. That way i could detect that it was the wdt and just return back to the code when needed. I dont know yet if this is possible using the restart 0000 vector. That's the worst choice i think.
Maybe there is some way around this though.