avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] known issues with Mega168 and wdt.h?


From: Joerg Wunsch
Subject: Re: [avr-chat] known issues with Mega168 and wdt.h?
Date: Mon, 1 May 2006 22:02:18 +0200 (MET DST)

"Steve Franks" <address@hidden> wrote:

> 1) The uC would reset, say, every 125mS, not every 2s.

Well, it initially got reset after 2 s, and afterwards probably even
each 15 ms (shortest possible reset interval).

The point is that you really need to read the fine print here in the
datasheet.  I tried to point these requirements out in the explanation
blurb on top of the <avr/wdt.h> documentation.  On the "new
architecture" watchdog (basically any watchdog implementation that
also has the option to trigger an interrupt), once the watchdog hit,
the watchdog will remain active even after a reset (except power-on,
obviously).  Unlike the suggestion of the datsheet, the remainder of
the watchdog control register has been initialized though, resulting
in a watchdog timeout of the shortest possible value (as this is the
reset value of that register).  So you have to act quickly after a
reset.

In addition (and this is, well, a bit hidden in the docs, and comes
out rather unexpectedly at first), the WDRF bit in MCU[C]SR, while
active (indicating a watchdog reset happened), prevents the watchdog
from being disabled.  Thus, a simple wdt_disable() is not sufficient
after a watchdog reset.  You *must* clear WDRF at some point before
that.

When I discovered that feature (on an ATmega1281 which also has a "new
architecture" watchdog), I was tempted to add that code to
wdt_disable().  However, I've got two arguments against it:

. It's the application's business to handle the various reset source
  indication flags in MCU[C]SR, not the librarie's business.  The
  application might really want to know the reason so the library
  should not mess with it, e. g. if you've got section(".noinit")
  variables, you probably don't want to reinitialize them after a
  watchdog reset.

  So IMHO every application should fetch and clear MCU[C]SR at the
  earliest possible occasion (perhaps already in .init3).  For
  applications that use the watchdog, this "should" now just becomes
  mandatory with the new watchdog hardware.

. wdt_disable() and wdt_enable() might be used throughout the entire
  application more than once, not only right after a (watchdog) reset,
  e. g. if you know you're going down into some long-running piece of
  code without the possibility to regularly re-trigger the watchdog
  (but you're really sure the code will never hang), you could want to
  turn off the watchdog before.  Thus it would only add useless code
  to mess with MCU[C]SR in wdt_disable().

So instead, I opted to emphasize that feature in the documentation.
But of course, I know the proverb: "If all else fails, read the
documentation."...

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]