How do I avoid a reset when using the watchdog in interrupt mode and changing the timeout?

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

I'm writing a program for an ATtiny85. I want to use the watchdog to wake up from power down in certain intervals. I need to change these watchdog timout intervals during the program. It all works fine as long as the intervals for a watch dog event don't change (i.e. I don't change bits WDP0-3 after I've set them once).

As soon as I change the timeout of the watchdog, it does an unwanted reset. I don't have the WDTON fusebit enabled, so the whactdog is not always on but rather has to be enabled by software. (In fact the fuse bits are: Low=0xe2, High=0xdf and Extended= 0xff make the controller run at 8 Mhz from the internal oscillator, not that it matters). I linked a more detailed example of my program in the first sentence. Here is the short version:

 

void Config_wdt(uint8_t timeout) {
    cli();
    wdt_reset();                  // reset watchdog timer
    MCUSR &= ~(1<<WDRF);          // clear reset flag
    WDTCR = (1<<WDE) | (1<<WDCE); // enable watchdog
    WDTCR = (1<<WDIE) | timeout;  // watchdog interrupt instead of reset
    //+reset, timeout can be 15,30,60,120,250,500ms or 1,2,4,8s
    sei();
}

int main() {
    Config_wdt(WDTO_500MS);
    Do_something();
    go_to_sleep();
    
    // This causes an unwanted reset
    Config_wdt(WDTO_4S);
    Stuff();
    go_to_sleep_again();
}

 

I hope you can help me, because the datasheet could not.

 

The datasheet has this to say:

If WDE is set, WDIE is automatically cleared by hardware when a time-out occurs. This is useful for keeping the Watchdog Reset security while using the interrupt. After the WDIE bit is cleared, the next time-out will generate a reset. To avoid the Watchdog Reset, WDIE must be set after each interrupt.

But even if I set the WDIE bit immediately after waking up from sleep mode, it still does the unwanted reset.

So how do I change the watchdog timeout in my code, without the unwanted reset?

This topic has a solution.

Last Edited: Fri. Oct 31, 2014 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now maybe that isn't ALL your code but if it is you are enabling WDIE and not providing an ISR() to catch it.

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

clawson wrote:

Now maybe that isn't ALL your code.

What I showed is just the part where it goes wrong. A more complete version is linked in my first sentence (and now in this). I'm using an empty "EMPTY_INTERRUPT(WDT_vect)", so literally nothing happens there. I use the watchdog only to wake up from power down after a certain amout of time.

 

Even stranger now, I played around with the timing a little bit. If I use "WDTO_2S" instead of "WDTO_4", it works perfectly normal. I'm begninning to think it's some sort of glitch. I know some AVRs don't support above two seconds watchdog timeout but the ATTiny85 certainly does.

Last Edited: Fri. Oct 31, 2014 - 03:50 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
WDTCR = (1<<WDIE) | timeout;  // watchdog interrupt instead of reset

That won't work for values of timeout longer than WDTO_2S.

 

The timeouts are defined as this:

#define WDTO_15MS   0
#define WDTO_30MS   1
#define WDTO_60MS   2
#define WDTO_120MS  3
#define WDTO_250MS  4
#define WDTO_500MS  5
#define WDTO_1S     6
#define WDTO_2S     7
#define WDTO_4S     8
#define WDTO_8S     9

However on the t85, WDTCR looks like this:

#define WDIF 7
#define WDIE 6
#define WDP3 5
#define WDCE 4
#define WDE  3
#define WDP2 2
#define WDP1 1
#define WDP0 0

Note that WDP3 isn't adjacent to WDP2.  If you 'or' timeout with (1<<WDIE) and stuff that into WDTCR when timeout is WDTO_4S you're actually enabling WDTO_15MS because WDTO_4S is 0b1000, so you're setting WDE instead of WDP3.

 

Just use wdt.h provided by AVR Libc, it properly handles WDP3.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Nov 1, 2014 - 07:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you very much, that explains it and I can happily live my life again. It's been bugging me for some time. In my defence, here is what I looked at:

 

From the wrong version of the datasheet

Notice how it doesn't say "Bits 5, 2:0" as it should. A more recent version of the data sheet has the five in there. Though in both versions, I could've seen it in in the diagram a page above:

 

What I should&#039;ve looked at

 

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

con-f-use wrote:
Notice how it doesn't say "Bits 5, 2:0" as it should. A more recent version of the data sheet has the five in there.
Yeah, Atmel datasheets aren't known for their exquisite accuracy ;)

 

An eagle-eyed reader might also have noticed that bits 2:0 account for only three bits, while WDP[3:0] suggests there should be a fourth.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Yeah, Atmel datasheets aren't known for their exquisite accuracy ;)

C'mon, guys.  Just because you got bit (read: were bitten) bu the way you happened to put the bits together has nothing to do with the "accuracy" of the datasheet.

 

AFAICR Atmel is consistent in this nomenclature.

 

So if you want to set REFS1 and REFS0, "• Bit 7:6 – REFS1:0: Reference Selection Bits", to select internal reference you put 3 into ADMUX?  What about MUX5..0?  You select the temperature channel putting all the bits into ADMUX, because they share the same root "MUX"?

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

Lee, I think you've misread.  The earlier version of the t25/45/85 datasheet (apparently.  I don't possess such an early version) show:

Bits 2:0 – WDP[3:0]: Watchdog Timer Prescaler 3, 2, 1, and 0

Whereas more recent versions show:

Bits 5, 2:0 – WDP[3:0]: Watchdog Timer Prescaler 3, 2, 1, and 0

This is clearly a copy/paste errata in the Atmel techwriter's office in the early version, and not a matter of nomenclature.

 

As I mentioned, a careful reader would see the discrepancy and investigate further.

 

As you point out, there are other examples of non-adjacent related bits.  That was indeed the OP's issue, but it seems he was misled by A) a datasheet errata, compounded by B) a less-than-thorough reading of the relevant datasheet section.

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Lee, I think you've misread.  The earlier version of the t25/45/85 datasheet (apparently.  I don't possess such an early version) show:

Bits 2:0 – WDP[3:0]: Watchdog Timer Prescaler 3, 2, 1, and 0

Whereas more recent versions show:

Bits 5, 2:0 – WDP[3:0]: Watchdog Timer Prescaler 3, 2, 1, and 0

This is clearly a copy/paste errata in the Atmel techwriter's office in the early version, and not a matter of nomenclature.

 

As I mentioned, a careful reader would see the discrepancy and investigate further.

 

 

In my defence, here is what I looked at:

 

From the wrong version of the datasheet

Notice how it doesn't say "Bits 5, 2:0" as it should. A more recent version of the data sheet has the five in there.

 I still think y'all are claiming sour grapes.  Yes, I'll be early in line to agree that AVR8 datasheets are not great works of literature.  Yes, the cut-and-paste code examples that don't run on the particular model are amusing at best.  And I certainly understand the frustration when the datasheet is mis-read, or flat-out wrong, and will empathize. But let's poke at >>this particular situation<<...

 

1)  How does a value greater than 7 fit into the mentioned Bits 2:0?

2)  It is late 2014, nearly 2015.

3a) Rev. A datasheet for this family came out in February 2005.  So nearly 10 years ago.

3b) There have been a dozen or more datasheet revisions in that decade.  Many changes were probably to fix such "inaccuracies" you are railing at.

3c)  It would be interesting to see the entire page of the quoted image with the 2:0, so that the document number and revision could be seen.  The rev. C datasheet, mid-2005, already had 5,2:0.

4)  Given the above, why is OP working on new dev using a nearly-original datasheet version from a decade ago?

 

 

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.

Last Edited: Sun. Nov 2, 2014 - 03:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) it doesn't, and I've pointed that out twice now.

 

2,3a,3b,3c,4,5) Remember, I didn't have a problem with my WDT code, or with the datasheet.  The OP did.  I simply commiserated over the fact that there are annoying errata in Atmel datasheets.  I never suggested they were rife with gross errors.  And I'm pretty sure no one is 'railing'.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

I simply commiserated over the fact that there are annoying errata in Atmel datasheets. 

Certainly they aren't perfect.  If they were, why are there datasheet revisions?  Anyone who insists on using the first preliminary datasheet for new work is ... can't think of a term.

 

As I have a number of revisions of that family datasheet downloaded, I'm interested to see which version/date had that info.

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.