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.