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 ?

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.

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.

-- 
John B

On Jun 25, 9:27 am, b...@barrk.net (B1ackwater) wrote:

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

That's one of the few areas where a PDF document trumps a paper one:
searchability.

(Portability/archivability being another.  But even with large dual
monitors, it's a pain to reference one while trying to code / test)

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

On Wed, 25 Jun 2008 00:11:07 GMT, John Temples <usenet@xargs-spam.com>
wrote:

>On 2008-06-24, B1ackwater <bw@barrk.net> wrote:
>> While I've used PICs for many things, I've never made
>> use of the SLEEP mode. For my 18f2620, the docs state :
>>
>> "All external interrupts (INT0, INT1 and INT2) can
>> wake-up the processor from SLEEP, if bit INTxE was
>> set prior to going into SLEEP. If the global interrupt
>> enable bit GIE is set, the processor will branch to
>> the interrupt vector following wake-up."
>
>[...]
>
>> BUT ... a WDT timeout while sleeping does NOT branch to
>> the ISR, but instead just picks up the program exactly
>> where it left off, ie executing the code beyond the
>> SLEEP instruction. This is OK, convenient even ... 
>> but not what the docs SAY it will do. 
>
>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.

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

On Tue, 24 Jun 2008 23:20:27 GMT, Pete <pjetson@pobox.com> wrote:

>B1ackwater wrote:
>
>> "All external interrupts (INT0, INT1 and INT2) can
>> wake-up the processor from SLEEP, if bit INTxE was
>> set prior to going into SLEEP. If the global interrupt
>> enable bit GIE is set, the processor will branch to
>> the interrupt vector following wake-up."
>
>> BUT ... a WDT timeout while sleeping does NOT branch to
>> the ISR, but instead just picks up the program exactly
>> where it left off, ie executing the code beyond the
>> SLEEP instruction. This is OK, convenient even ... 
>> but not what the docs SAY it will do. 
>
>The paragraph that you quoted doesn't seem to mention the WDT.  I 
>downloaded the data sheet and a quick check turned up this:
>
>  > If the device is not executing code (all Idle modes and
>  > Sleep mode), the time-out will result in an exit from
>  > the power-managed mode (see Section 3.2 "Run Modes" and
>  > Section 3.3 "Sleep Mode"). If the device is executing
>  > code (all Run modes), the time-out will result in a WDT
>  > Reset (see Section 23.2 "Watchdog Timer (WDT)").
>
>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.

   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. 

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.

-- 
John B

On 2008-06-24, B1ackwater <bw@barrk.net> wrote:
> While I've used PICs for many things, I've never made
> use of the SLEEP mode. For my 18f2620, the docs state :
>
> "All external interrupts (INT0, INT1 and INT2) can
> wake-up the processor from SLEEP, if bit INTxE was
> set prior to going into SLEEP. If the global interrupt
> enable bit GIE is set, the processor will branch to
> the interrupt vector following wake-up."

[...]

> BUT ... a WDT timeout while sleeping does NOT branch to
> the ISR, but instead just picks up the program exactly
> where it left off, ie executing the code beyond the
> SLEEP instruction. This is OK, convenient even ... 
> but not what the docs SAY it will do. 

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.

-- 
John W. Temples, III

B1ackwater wrote:

> "All external interrupts (INT0, INT1 and INT2) can
> wake-up the processor from SLEEP, if bit INTxE was
> set prior to going into SLEEP. If the global interrupt
> enable bit GIE is set, the processor will branch to
> the interrupt vector following wake-up."

> BUT ... a WDT timeout while sleeping does NOT branch to
> the ISR, but instead just picks up the program exactly
> where it left off, ie executing the code beyond the
> SLEEP instruction. This is OK, convenient even ... 
> but not what the docs SAY it will do. 

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

  > If the device is not executing code (all Idle modes and
  > Sleep mode), the time-out will result in an exit from
  > the power-managed mode (see Section 3.2 "Run Modes" and
  > Section 3.3 "Sleep Mode"). If the device is executing
  > code (all Run modes), the time-out will result in a WDT
  > Reset (see Section 23.2 "Watchdog Timer (WDT)").

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