OK ... a minor mystery ... 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." Well, it doesn't. I *do* have GIE enabled, and INT1, because the PIC needs to be awakened by an external device. WDT timeouts DO happen. The external interrupt DOES work also, awakening from sleep and calling the ISR just like it's supposed to. 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 program is writ in MikroPascal, but the actual SLEEP command is an in-line ASM statement, so MP ought not be saving the current program counter or anything else before SLEEP. Any clues as to why this may be happening ? Mystery registers that could de-rail the call to the ISR when interrupts are enabled ? Any info helpful.
Sleeping PICs Lie ? - WDT + GIE <> ISR but Just Resumes Main Code
Started by ●June 24, 2008
Reply by ●June 24, 20082008-06-24
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
Reply by ●June 24, 20082008-06-24
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
Reply by ●June 25, 20082008-06-25
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
Reply by ●June 25, 20082008-06-25
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.
Reply by ●June 25, 20082008-06-25
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 ...
Reply by ●June 25, 20082008-06-25
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 ... :-)
Reply by ●June 25, 20082008-06-25
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)
Reply by ●June 25, 20082008-06-25
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
Reply by ●June 27, 20082008-06-27
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.
