Looking for some WDT guidance

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

Our app runs on an xmega256a3. We run our watchdog timer at the 8 second configuration. We sleep the processor for extended periods. But we leave the WDT enabled during sleep. So if our sleep goes longer than 7.5 seconds, we wake up briefly every 7.5 seconds to reset the watchdog.

Now I've stumbled on this bit of info from an AVR application note (AVR1310, doc8034.pdf):

Quote:
The typical accuracy of the clock for the WDT is +/-30% (please refer to datasheet for exact information on accuracy of the clock).

When we refer to the xmega256a3 data sheet though, we find scant little on the ULP Oscillator:

Quote:
Output frequency 32 kHz ULP OSC
T = 85°C, VCC = 3.0V
26 kHz

Part of me thinks we should just go with the 30% and go adjust our minimal watchdog reset time to 5.5 seconds (70% of 8 seconds). But what's odd, is that we have around 500 of these devices running, and I don't think any of them have displayed a tendency to reset on long sleeps when the ought not. So it almost seems as if 7.5 seconds (roughly 93% of 8s) is good enough. And the specific datasheet doesn't seem to give a specific range.

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

Silly question but why not simply turn the watchdog off while sleeping - you cannot lock up if it's not executing or aer you trying to protect the entry/exit to/from sleep?

BTW I simply don't believe that 30% figure and would suspect an error where it's been quoted. RC oscillators are bad but usually well within 10% - not 30%.

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

The original concern was that we basically wanted a backup that would bring the processor back alive. If stray neutrinos or ESD or whatever, somehow altered the sleep state, we wanted a reassurance that the processor would come back alive and return to work, even with a hiccup.

It actually did help find an intermittent bug I eventually had where I rarely computed a RTC.COMP wakeup time that was in the past, and would have had to wait for a counter roll to wake back up.

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

Quote:
Part of me thinks we should just go with the 30% and go adjust our minimal watchdog reset time to 5.5 seconds (70% of 8 seconds). But what's odd, is that we have around 500 of these devices running, and I don't think any of them have displayed a tendency to reset on long sleeps when the ought not. So it almost seems as if 7.5 seconds (roughly 93% of 8s) is good enough. And the specific datasheet doesn't seem to give a specific range.

The Watchdog timer only resets according to what it thinks is 8sec in your case. If it is off by +30%, then the watchdog timer period is 10.4sec. So none of your parts should accidentally have a watchdog timer reset because the watchdog oscillator is off.

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

That's great for the +30% case... What about the -30% case?

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

It should be the same. The watchdog timer will issue the system reset when it's counter hits the selected value. Watchdog timer is based on the actual bit value in the counter, not on absolute time.

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

Keep in mind that 30% is the absolute maximum error. Atmel don't so sample distribution graphs but most likely it would be a bell curve, with most devices fairly close to the rated speed. Chances are very very few are 30% off.

As manufacturing improves the number will go down, but Atmel probably haven't bothered to re-test the devices or maybe they just kept the pass/fail limits the same.

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

Put a nice margin in above the 30% - I would budget 40%.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!