Monday, May 3, 2010

Effective Use of an External Watchdog Timer

It's a good idea to use an external watchdog timer chip if you have a critical application. That way if the main microcontroller chip fails you have an independent check on its operation. (Ideally, make sure the external watchdog has its own oscillator so a single failed oscillator doesn't fool the watchdog and CPU into running too slowly.)

I recently got a question about how to deal with a simple external watchdog chip that didn't give a lot of flexibility in setting a timeout period. You want the timeout period to be reasonably tight to the worst-case watchdog kick period. But with external chips you might have a huge amount of timing slack if the watchdog period settings are really coarse (for example, a 1 second external watchdog when what you really wanted was 300 msec).

Here's an idea for getting the best of both worlds. Most microcontrollers have an internal watchdog timer. Rather than turn it off and ignore it, set it up for a nice tight kick interval. Probably you will have a lot of control over the internal watchdog interval. Then set the external watchdog timer interval for whatever is convenient, even if it is a pretty long interval. Kick both watchdogs together whenever you normally would kick just a single watchdog.

The outcome is that you can expect the internal watchdog will work most of the time. When it does, you have a tight timing bound. In the rare cases where it doesn't work, you have the external watchdog as a safety net. So for most single-point failures (software hangs) you have tight timing protection. For the -- hopefully -- much rarer double point failures (software hangs AND takes down the internal watchdog with it; or a catastrophic hardware failure takes down the CPU including the internal watchdog), you still get protection from the external watchdog, even if it takes a while longer.

Note that this approach might or might not provide enough protection for your particular application. The point is that you can do better in a lot of cases by using the internal watchdog rather than turning it off when you add an external watchdog. Chapter 29 of my book discusses watchdog timers in more detail.


  1. Hey Nice Article...
    I would like you to suggest an example chip as a External Watch dog IC. I am using it for a GPS/3G based project where the Modem itself acts as a host so I definitely need an external watchdog chip to reset the system in case something goes wrong.
    which one do u suggest. I need to pull the reset line low for about 50ms in case the system doesnt respond for one second.

  2. Sorry, but I can't offer detailed design advice on this blog. A web search will reveal alternatives from multiple vendors and the rest all depends upon the details of your application (power, size, cost, environmental requirements, and so on...)

  3. At what scenario internal watchdog may fail its operation? Execution of errant code to force watchdog config register(s) to default settings (let's assume watchdog remains turn off by default)? If application stuck due to pointing to an unknown location, then Watchdog should still remain in operation as it's a different hardware. Please let me know your suggestion.

    1. On-chip watchdogs are indeed subject to interference by software on the same chip. It is desirable for an internal watchdog to be configured so that once it is started its configuration can't be changed until after the next system reset. In life-critical applications it is common to see off-chip watchdogs to improve isolation of the watchdog from the software it is watching.

  4. Access to an internal WD can be made tricky by the HW manufacturer, say, kick registers for configuration, question-and-answer mode for servicing. Then the risk that the WD is fooled by out-of-control execution of code or data is negligible compared with other contributions to non-availability (power supply).

    What kind of "catastrophic hardware failure takes down the CPU including the internal watchdog" and would be healed by a reset?

    Anyways, a life-critical application should not rely on the functioning of a single microcontroller.


  5. In which cases internal watchdog in micro controller may fail.

    1. On many chips a software defect can turn off the watchdog. (Good idea to get a chip on which once the watchdog has been started it can't be turned off.)

      In general, once something goes wrong on a chip it is very difficult (research I've seen indicates it is impossible) to isolate the effects to only one part of the chip. That's likely one of the reasons a previous comment said you don't want to rely on a single microcontroller.

  6. If the operating frequency of microcontroller and external window watchdog are different say 100 MHz and 2MHz respectively. How can I match the timeout period to service external WDG properly.(open period 10 ms)

    and be sure that you do NOT simply kick the watchdog with a timer interrupt. That defeats the whole point!


Please send me your comments. I read all of them, and I appreciate them. To control spam I manually approve comments before they show up. It might take a while to respond. I appreciate generic "I like this post" comments, but I don't publish non-substantive comments like that.

If you prefer, or want a personal response, you can send e-mail to
If you want a personal response please make sure to include your e-mail reply address. Thanks!

Static Analysis Ranked Defect List

  Crazy idea of the day: Static Analysis Ranked Defect List. Here is a software analysis tool feature request/product idea: So many times we...