Columnists

Use a watchdog timer even with perfect code

By Bonnie Baker, Microchip Technology Inc -- EDN, 4/17/2003

A watchdog timer may one day save your life or, better yet, your career. Although this statement is a little melodramatic, the proper use of this tool separates the hackers from the programmers in microcontroller and microprocessor land. The function of a watchdog timer is easy enough to understand. It is a counter that counts down with time from an initial value to zero. If your firmware ignores this tool long enough, the watchdog timer resets or interrupts the system without human intervention when the counter reaches zero. You can use many strategies to implement this type of protection, but the three this column addresses are the "kiss" method, the check-twice method, and the watchdog-timers-and-multitasking strategy.

A reasonable approach to this programming chore is the "kiss" (keep it simple, stupid) method. You can easily implement this style of watchdog-timer function when a single loop controls the entire system. In this type of firmware, you initialize the watchdog timer, execute your functions in a sequential manner, and loop back to the top of the firmware, which then resets the watchdog timer before it times out. If the firmware gets hung up in a function, spends too much time in an interrupt-service routine (ISR), has its data corrupted by a power surge, becomes locked into an infinite loop, and so on, the watchdog times out, forcing a reset function. This reset can be as simple as a software restart or complex enough to identify the failure and verify that all systems are still working.

With the check-twice method, the watchdog performs a different style of firmware monitoring. This type of system assigns each task a flag bit, indicating the successful completion of the task. If the system executes a task incorrectly, the flag clears, and the firmware proceeds to the next task. At the end of the cycle, if the firmware sets all flag bits as COMPLETE, the watchdog timer resets, and the cycle starts over. Otherwise, the system records flags that the firmware does not set as COMPLETE, and the watchdog timer initiates a system reset. Following the reset, the firmware resets all flags to the INCOMPLETE state and executes. Using this style of operation, two safeguards in the firmware exist: the watchdog timer, which guards against catastrophic failures, and completion flags, which assist with a quick recovery by identifying the task or tasks that failed so that the firmware can execute appropriate recovery algorithms.

On the other hand, monitoring the health of your system in a multitasking environment requires a multilayered approach. The watchdog-timer strategy in this environment is similar to the above scenarios with a few enhancements. The watchdog timer should detect infinite loops and deadlocks as well as the failure to run lower priority tasks. Infinite loops and deadlocks can occur within a task when two or more related tasks are so far out of synchronization that they lock up waiting for each other. An effective way to use the watchdog-timer function in this environment is to run it as a separate task. This high-priority task checks the status of the other tasks at regular intervals, watching for tasks that stall or tasks that are executing functions that are inconsistent with the rest of the system. If all tasks in the system pass the health test, the watchdog timer reinitializes. If not, it initiates a system reset.

The object of this game is to have an environment in which you never use this tool and your firmware runs smoothly. You achieve this objective by keeping your watchdog-timer function out of ISRs and residing in one place. If your equipment gets itself into a corner due to electromagnetic interference, static discharge, or a supply drop that corrupts your data, or if your firmware experiences an unanticipated combination of events, the watchdog timer helps you recover from these transient failures and gives you a self-reliant recovery solution.


Author Information
Bonnie Baker is the analog/mixed-signal-applications engineering manager for Microchip Technology's microperipherals division. You can reach her at Bonnie.Baker@microchip.com.


References
  1. Ganssle, Jack G, "Born to Fail," www.embedded.com, Dec 12, 2002.
  2. Brown, Doug, "Solving the Software Safety Paradox," www.embedded.com, Dec 26, 2002.


ADVERTISEMENT

ADVERTISEMENT

Feedback Loop


Post a CommentPost a Comment

There are no comments posted for this article.

Related Content

 

By This Author


ADVERTISEMENT

Knowledge Center



Technology Quick Links

EDN Marketplace


©1997-2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites

ADVERTISEMENT
You will be redirected to your destination in few seconds.