Searching \ for '[PIC]: 16F877 -TO bit and SLEEP problems' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: '16F877 -TO bit and SLEEP problems'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F877 -TO bit and SLEEP problems'
2001\08\19@192456 by Andrew E. Kalman

flavicon
face
Hi All.

I'm observing some behavior on the 16F877 that doesn't jive with the
manual. Can someone shed some light on this?

Application: WDT enabled, interrupts enabled, interrupts on RBO/INT
enabled via INTE. No other interrupts enabled, no other peripherals
in use.

Behavior: The PIC goes to sleep just fine, and wakes up each time the
WDT expires (roughly every 16ms). It also wakes up upon a change on
the RB0/INT pin, and processes the interrupt properly.

Problem: Regardless of the source of wake-up (WDT or RBO/INT), the
-TO bit is always cleared (0) after waking up. My reads of the manual
suggest that this is NOT expected behavior -- the -TO bit should be
cleared after waking up only if the reason for waking up was the WDT.

Relevant code looks like this:

  for(;;) {
    ...
    CLRWDT();
    SLEEP();
    if ( TO == 0 )
      DoTimerFn();
    ...
  }

The compiler has compiled the if() statement properly. I "trapped" T0
== 1 and it never happens. I can view on the logic analyzer that no
matter when the RB0/INT interrupt occurs relative to the periodic
wake-up due to WDT, DoTmerFn() is _always_ called. I want it to be
called only when the wakeup is due to WDT expiring.

Any ideas?
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   spam_OUTaekTakeThisOuTspampumpkininc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\08\19@194344 by Andrew E. Kalman

flavicon
face
Hi All.

I'm observing some behavior on the 16F877 that doesn't jive with the
manual. Can someone shed some light on this?

Application: WDT enabled, interrupts enabled, interrupts on RBO/INT
enabled via INTE. No other interrupts enabled, no other peripherals
in use.

Behavior: The PIC goes to sleep just fine, and wakes up each time the
WDT expires (roughly every 16ms). It also wakes up upon a change on
the RB0/INT pin, and processes the interrupt properly.

Problem: Regardless of the source of wake-up (WDT or RBO/INT), the
-TO bit is always cleared (0) after waking up. My reads of the manual
suggest that this is NOT expected behavior -- the -TO bit should be
cleared after waking up only if the reason for waking up was the WDT.

Relevant code looks like this:

  for(;;) {
    ...
    CLRWDT();
    SLEEP();
    if ( TO == 0 )
      DoTimerFn();
    ...
  }

The compiler has compiled the if() statement properly. I "trapped" T0
== 1 and it never happens. I can view on the logic analyzer that no
matter when the RB0/INT interrupt occurs relative to the periodic
wake-up due to WDT, DoTmerFn() is _always_ called. I want it to be
called only when the wakeup is due to WDT expiring.

I've also noticed one other thing - if I set a breakpoint in the ISR,
and then run from there, the -TO bit is correct when tested. But if I
let it run free, -TO is always 0.

Any ideas? Any example code of wake-from WDT and at least one other source?
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   aekspamKILLspampumpkininc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\08\20@084359 by Olin Lathrop

face picon face
> The compiler has compiled the if() statement properly. I "trapped" T0
> == 1 and it never happens. I can view on the logic analyzer that no
> matter when the RB0/INT interrupt occurs relative to the periodic
> wake-up due to WDT, DoTmerFn() is _always_ called. I want it to be
> called only when the wakeup is due to WDT expiring.
>
> Any ideas?

Yeah, check the INTF bit in INTCON.  I have never used the TO bit in STATUS,
but I would have thought it would be 0 after restart due to a watchdog
timeout.  This smells like something else is going on you aren't thinking
about yet.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, EraseMEolinspam_OUTspamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\20@114715 by Andrew E. Kalman

flavicon
face
Olin wrote:

>Yeah, check the INTF bit in INTCON.  I have never used the TO bit in STATUS,
>but I would have thought it would be 0 after restart due to a watchdog
>timeout.

I want to use -TO because INTF is cleared in the ISR, and is
therefore not available to test after wake-from-sleep. I could set a
flag in the ISR and check-and-clear it outside, but I'd rather not do
that.

and

>  This smells like something else is going on you aren't thinking
>about yet.


Indeed. I wonder what it is ...
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   aekspamspam_OUTpumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\20@150641 by Olin Lathrop

face picon face
> I want to use -TO because INTF is cleared in the ISR, and is
> therefore not available to test after wake-from-sleep. I could set a
> flag in the ISR and check-and-clear it outside, but I'd rather not do
> that.

I was suggesting that more for testing to find the problem than a clean
solution.  It might be illuminating to disable interrupts immediately before
the sleep and see how the bits come back after wakeup before any other code
runs.  Is there a CLRWDT in the ISR?  If so, could some other interrupt be
true on wakeup so that TO gets reset before you can see it in the main code?
...  Just grasping at straws.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, @spam@olinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\08\20@161208 by Andrew E. Kalman

flavicon
face
Olin wrote:

>I was suggesting that more for testing to find the problem than a clean
>solution.  It might be illuminating to disable interrupts immediately before
>the sleep and see how the bits come back after wakeup before any other code
>runs.  Is there a CLRWDT in the ISR?  If so, could some other interrupt be
>true on wakeup so that TO gets reset before you can see it in the main code?


From my reading of the manual, the _only_ thing that resets (i.e.
makes 0) the -TO bit is if the watchdog times out on its own.  All
other things (e.g. sleep and clrwdt instructions) set the bit.

I've done a couple of tests, and the only consistent thing I find is
that if I set a breakpoint (MPLAB_ICD or MPLAB-ICE2000) sometime
after the wake-from-sleep, the -TO bit is as expected. But if I left
it run free, it's not. Hmmm ...

I'll get this code running one way or the other (may have to disable
ints before going to sleep, and then test INTF upon wake as you
suggested, AND still have an ISR fro when RB0/INT changes when not
asleep). I might make an ultra-small test program to prove or
disprove the -TO bit behavior.

Thanks, and I'll report back on what I find.
--

 ______________________________________
  Andrew E. Kalman, Ph.D.   KILLspamaekKILLspamspampumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...