A watchdog timer (WDT) is a hardware timing circuit that is used to detect system anomalies and reset the microcontroller or microprocessor if any occur. It is an essential component of many embedded systems, providing an extra layer of robustness and reliability.
The main purpose of a WDT is to reset the system if the main program crashes or gets stuck in an endless loop. This prevents system lockups and allows the system to recover to a known good state. Here is a typical example of how a WDT is utilized:
- The WDT is initialized and enabled at system startup. This sets the timeout period (e.g. 1 second).
- The main firmware loop has a section of code that periodically restarts or “kicks” the WDT before the timeout expires. This is usually done by writing a specific value to a WDT control register.
- If the main loop crashes or gets stuck, the firmware will no longer restart the WDT. After the timeout period expires, the WDT will reset the microcontroller.
- The system then boots up again, allowing the main program to restart and recover.
In this way, the WDT provides a self-recovery mechanism and prevents system hangs or crashes from bringing the whole system down. As long as the firmware can restart properly after a reset, the WDT allows it to recover from software glitches and continue operation. The timeout period determines the WDT’s “heartbeat” – the main firmware must restart the WDT at least once per timeout period.
Example WDT Implementation
Here is a specific example to illustrate how a WDT could be implemented in practice:
The system is built around an ARM Cortex-M4 microcontroller running at 80 MHz. The firmware is written in C and provides control, monitoring, and communications functions for an industrial motor drive. Reliability is critical, as an uncontrolled motor shutdown could be hazardous and result in costly downtime.
The microcontroller has an on-chip WDT module. The firmware enables the WDT at startup, configuring it for a 1 second timeout period. The WDT clock runs continually at 40 kHz regardless of the main system clock speed. The micro’s WDT module has a 16-bit counter that increments on each clock pulse. Therefore, it will overflow and trigger a reset after 2^16/40 kHz = 1 second.
The main firmware loop has a dedicated WDT handler function that executes periodically. Here is the relevant code: // WDT handler function void wdt_handler(void) { // Refresh the WDT WDT_REG->REFRESH = 0xABCD; } int main(void) { // Enable WDT with 1 sec timeout WDT_REG->CR = 0x1; while(1) { // Main firmware tasks executed here // Restart the WDT every 500 ms if(time_has_elapsed(500)) { wdt_handler(); } } }
The wdt_handler() function restarts the WDT by writing a specific refresh value to the WDT’s control register. This resets the internal counter before it reaches the overflow value. It is called every 500 ms to keep refreshing the WDT well within the 1 second timeout period.
If the main firmware ever gets disrupted due to a crash, infinite loop, or any other reason, the WDT refresh will cease happening. After 1 second without a refresh, the WDT will hit its timeout period and generate a reset signal. This brings the microcontroller back to a known good state to start execution again after reboot.
In this way, the WDT provides an ongoing integrity check of the health of the firmware. If the predefined “heartbeat” refresh stops for any reason, the system automatically resets before the motor potentially becomes uncontrolled. The 1 second timeout provides enough headroom for the firmware to refresh the WDT reliably, while still detecting crashes quickly enough to prevent disaster.
Key Characteristics of Watchdog Timers
This example highlights some key characteristics and capabilities of WDTs:
- Hardware-Based Operation – The WDT relies on a hardware timer integrated in the microcontroller or processor. It functions independently from the main firmware.
- Fixed Timeout Period – The WDT timeout is preset and fixed. The firmware cannot accidentally modify or disable the WDT.
- Reset Generation – The WDT can force a system reset when its timeout expires. The system reboots automatically.
- Simplicity – WDTs have basic control registers. The firmware just needs to write a specific value periodically to refresh the timer.
- Flexibility – Timeout periods are often configurable to match system reliability needs.
- Low Overhead – Little processing time is needed for the periodic refresh, allowing the firmware to focus its efforts on the main application.
These attributes make WDTs a robust and efficient method for embedded systems to achieve high reliability through periodic self-checking and automatic recovery.
Other WDT Use Cases
While the example above demonstrates a WDT monitoring the main program loop, there are other potential use cases as well. Some other ways WDTs can be utilized include:
- Monitoring a Critical Task – A WDT could check on a crucial background task like motor speed regulation. If the task crashes, the system can be restarted.
- Communication Watchdog – Reset the system if expected data stops arriving from an external device within a certain window.
- Secondary Timeout – Some microcontrollers have multiple watchdog modules. One WDT could implement a long system reset, while another provides a faster timeout for critical loops.
- Actuator Timeout – Restart a solenoid, motor, or other actuator if it gets stuck and fails to finish its cycle in an expected time window.
- Debugging Tool – Short WDT timeouts can help identify areas of code that accidentally block for too long.
The use cases are extensive – whenever there is a need for automatic timeout monitoring and system reset capability, a WDT can potentially fill that role and enhance system resilience.
Conclusion
In summary, watchdog timers provide an indispensable layer of robustness for many embedded systems. The example of the motor drive highlights how a WDT can detect crashed or stuck firmware and safely reset the system. Key characteristics like hardware independence, automatic reset generation, and simplicity of implementation make WDTs a staple of embedded system design. Their configurability, low overhead, and wide range of applications make them a versatile tool for enhancing reliability. By forcing periodic self-checks and resets, WDTs can keep systems up and running reliably even in the face of software glitches or exceptions.