Watchdog Timer

Many issues can cause a system to enter an illegal or frozen state, e.g., software bugs or electrical noise. One safety measure available on the Relevant Devices is the Watchdog Timer (WDT). This is a timer that runs independently from the rest of the system, with a separate clock source. When the timer overflows, it will cause a Reset. The system firmware must periodically clear the WDT using the dedicated instruction Watchdog Timer Reset (WDR). If the firmware is not able to do so, e.g., due to a system hang or run-away code, the system will be Reset.

Normal mode

In Normal mode, the watchdog counts from 0 to the MAX value and can be cleared at any time. The period in Normal mode can be configured with a duration from 8 ms to 8s.

Window mode

For increased robustness, Window mode is available. In Window mode, both a closed and an open window are configured, with the closed window being at the start of the period. While in the closed window, clearing the WDT is an illegal operation, resulting in a Reset. Once the closed window is over, the open window starts and the WDT can now be cleared. Using Window mode puts more requirements on the firmware, as it must clear the watchdog in the open window only. Both windows can be configured with a duration of 8 ms to 8s. This gives a total WDT period of 16 ms to 16s.

The WDT period and window timeouts can be configured by fuses so that it is active immediately after Reset. Should there be any issue with the firmware, causing it to not start properly, the WDT will reset the system. The WDT will start to count from 0 after Reset, regardless of the Reset source.

As one of the goals of implementing a watchdog timer is to be able to recover from the run-away code, there are a few things the software engineer may consider. The run-away code does not influence the execution of an interrupt. Any interrupt vector will be correctly loaded, even when the system for some reason is executing the wrong code. Therefore, do not clear the WDT from an interrupt handler. Also, try to limit the amount of WDR instructions. If clearing the WDT is done in many parts of the firmware, it becomes more likely that one of these is executed when the run-away code is being executed. Ideally, only one WDR instruction may be implemented. This can be hard to achieve, but it is important to try to limit the amount of WDR instructions. Using the Window mode can also help catch erroneously executed WDR instructions.