Sleeping PICs Lie ? - WDT + GIE <> ISR but Just Resumes Main Code

The paragraph that you quoted doesn't seem to mention the WDT. I downloaded the data sheet and a quick check turned up this:

That suggests to me that the operation you're observing is what the chip was designed to do. It's been a very long time since I've written code for a PIC, but that's also how I remember sleep mode working.

Peter

The WDT does not generate an interrupt, so it will not branch to the ISR. When it times out, it wakes from sleep if sleeping, or resets the PIC if running.

You need to decide whether you want the WDT or the interrupt to wake up the processor. If it's the latter, then you must turn off the WDT before putting the processor to sleep.

I'll check that section and see (this is what you get with 350+ page documents ... the info you need is scattered all over the place).

Apparently it means that if the CPU is righteously hung (or most anything that delays clearing the WDT) then it WILL jump to the ISR on WDT timeout if GIE is set - but if it's sleeping, then it just resumes where it left off regardless of the GIE status.

Alas, section 3 says "all run modes" but doesn't mention the effect of GIE ... where you don't get a true "reset" but instead a jump to the ISR. There oughtta be an "also see ..." footnote at least.

Anyway, this is fine with me ... except it means I have to write a little extra code to deal with THREE modes of program resumption now ... GIE enabled (->ISR), GIE disabled or power-cycle (->reset) and SLEEP (->resume) :-(

Thanks.

After reading some other parts of the manual pointed out by another poster, it's clear that what I had first read applied only to exiting SLEEP because of an external interrupt ... where the state of GIE will decide whether you jump to the ISR or do a device reset.

A WDT exit from SLEEP resumes from where you left off while a WDT trigger during normal running (or a hang) causes a device reset.

Another case of where the info you need is scattered in several places across 350+ pages of small print.

Hmmm ... does MicroChip have a seperate document entitled "About Interrupts" or something, where all the pertinent data and possible register/state interactions are brought together in one place ? As so many people seem to go so wrong with interrupts it would seem a smart thing to do. I'll try to search ...

Actually, I need BOTH to wake up the processor. The "normal" mode is a wakeup interrupt from one of several possible external devices saying "I've got something for you !".

However I'd ALSO like the WDT to kick in every so often just in case the processor got hung-up and can't hear the external requests anymore. "Wastes" a tiny speck of power every few minutes, but ensures the device is always working (these are going out "in the field" ... WAY out).

A couple of good docuphiles pointed out ANOTHER section that affected my interpretation of events ... that it's only an INTERRUPT during sleep that can cause a jump to the ISR if GIE is set. A WDT timeout during sleep just resumes the code, regardless of GIE, and a WDT timeout during normal running (or a hang-up) resets the processor as if the power had been cycled.

So, I've gotta write code to deal with each possible scenerio ... POR/WDT, SLEEP+GIE & SLEEP+WDT. What fun ... :-)

Hmmm, sounds pretty chaotic. I think I'll stick with my tried and tested AVRs thanks.

No it make perfect sense if you are asleep and an interrupt happens you expect to goto an interrupt. If the watchdog is used to wake from sleep it would require it own flag so you could tell which interrupt happened.

Followup :

Although the WDT does indeed set its own flag so you can tell if that's why the CPU restarted, I didn't actually need to use it. Just set up my initiallization code so it didn't care whether it was a WDT or a power-on reset ... a restart was a restart regardless. This was easier than using a seperate re-init routine JUST for WDT resets.

My app is working just fine now ... waits for an external interrupt to wake it up and, if the wait is long enough, the WDT periodically reboots the thing so it will never become 'stuck' (for long) - whereupon it just goes back to sleep again almost immediately. Power is conserved and the app remains robust ... who could ask for more ?