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

On Fri, 27 Jun 2008 00:32:48 -0400, Neil <NeilKurzm@worldnet.att.net>
wrote:

>John B wrote:
>> On 25/06/2008 B1ackwater wrote:
>> 
>>> On 25 Jun 2008 11:02:23 GMT, "John B"
>>> <spamj_baraclough@blockerzetnet.co.uk> wrote:
>>>
>>>> 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.
>>>    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 ?