Sleep with watchdog off causes immediate reset?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an ATTINY88, and putting it to sleep until we receive a wakeup IR command (which is obviously an interrupt).

Here's a code snippet:

wdt_disable();
SMCR=0b00000101;  // power down
sleep_cpu();

When this executes, the system resets immediately. If I comment out wdt_disable(), the system successfully sleeps, and wakes up when the watchdog timer triggers.

I don't have the watchdog fuse set, so why wouldn't this just let the ATTINY sleep without regard to the watchdog timer?

(The same thing happens if I use the sleep_mode() and related macros.)

Thanks for any tips! This is baffling.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We probably need to see a bit more context. (As usual, best is a complete program, the smallest that demonstrates the symptoms.)

So we know it is a Tiny88 target. The normal question about clock speed probably isn't pertinent here. Can we infer GCC?

Apparently you have the WDT interrupt enabled. Does the GCC wdt_disable() correctly turn off WDIE? (The simulator might even tell you that.)

Quick test is to do a WDR before the disable and see if that helps.

Trap and examine "8.5.1 MCUSR – MCU Status Register" to see what the reset cause is. If none, then put in the GCC trap for "bad vector" or whatever it is called.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. I'm using AVR studio 6, and clock is 8MHz, non-divided-by-8.

I don't think the WDT interrupt was enabled, unless it was somehow enabled to have a short time duration. The reset happened immediately, and I had the WDT interval set to 8 seconds.

I did do the MCUSR addition, and somehow the sleep mode is working now. All I did was read the register, then clear it to zero. I don't understand how they could be related.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't think the WDT interrupt was enabled,

???
Quote:

If I comment out wdt_disable(), the system successfully sleeps, and wakes up when the watchdog timer triggers.

I guess I ass-u-me-d that if you wanted to catch the wakeup event, the provided interrupt would be used rather than a full system reset.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a little confused. The WDT was disabled, and it led to an immediate reset upon sleep. If the WDT was enabled, it slept correctly, until the WDT triggered at 8 seconds. There is no specific WDT interrupt programmed (a system reset is fine during a normal WDT timeout).

We do want to catch the wakeup of course, but wouldn't that just be in the subsequent code after sleep_cpu()?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suspect wdt_disable is setting WDP[0-3] to zero, which is 16ms, disabling WDIE, but not actually turning off the watchdog timer. 16ms after sleep_cpu(), the watchdog will go off and reset the AVR.
https://github.com/baerwolf/USBa...

If I get a chance I'll try it on one of the t88's I have.

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked at the wdt_disable code in avr-libc and the t88 datasheet. I suggest you change your code as follows:

MCUSR &= ~_BV(WDRF);
wdt_disable(); 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

There is no specific WDT interrupt programmed (a system reset is fine during a normal WDT timeout).

That was my ???. As we now have the capability to do a "soft" wakeup with everything in the app intact after sleeping in power-down with low power draw for some seconds, why would you want to do a full reset? Re-setup all the I/O and so on. Lose all the values in variables and I/O registers.

I guess if speed of response to the wakeup event isn't critical, the extra time is measured in maybe a few milliseconds--so no big deal? OTOH in apps where I'm doing this I want to get back to deep sleep ASAP if nothing to do. Why stay awake longer than I have to? And let's say I send a message to the home base with RF every minute or so. So I count 7 or 8 8-second WDT timeouts and then send from my remote sensor. if you r4eset each time, where are you going to count to 7/8?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.