A watchdog timer (WDT) is a hardware countdown timer that resets the microcontroller if the firmware fails to periodically "kick" (reload) it before it expires. It is used to recover automatically from software faults such as infinite loops, deadlocks, or stack corruption.
In practice
In a typical bare-metal design, the application kicks the watchdog at one or more well-chosen points in the main loop. If the loop stalls — due to a hung peripheral driver, runaway pointer, or unexpected exception — the WDT times out and forces a hardware reset. The timeout period is configured at startup and is usually chosen to be longer than the worst-case loop execution time but short enough to meet the system's recovery requirements.
On most MCUs the WDT is a dedicated hardware peripheral with its own clock source, often an internal low-speed RC oscillator (e.g., the IWDG on STM32 devices runs from the 32 kHz LSI). Running from an independent clock means the watchdog can fire even if the main system clock fails or is misconfigured — a meaningful safety net during bring-up. Some parts, such as the AVR ATmega series and many MSP430 devices, also allow the WDT to be used as a general-purpose interval timer rather than a reset source.
A common pitfall is kicking the watchdog inside an ISR or a tight polling loop rather than from the main application flow. This pattern can mask hangs in other parts of the code, defeating the watchdog's purpose entirely. Another pitfall is disabling or skipping the watchdog during development and forgetting to re-enable it in production firmware; many safety standards (IEC 61508, ISO 26262) call for safety mechanisms and diagnostics appropriate to the design, and an active, correctly configured watchdog is a common expectation in safety-critical applications.
On systems running an RTOS, kicking the watchdog correctly is more complex. A common approach is to have each task set a flag or feed a software counter, and a dedicated watchdog task only kicks the hardware WDT when all tasks have checked in within their deadlines. This detects per-task hangs rather than just a stuck scheduler.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between an independent watchdog and a windowed watchdog?
A standard (independent) watchdog resets the
MCU if it is not kicked before the timeout expires; some MCUs also support a pre-timeout
interrupt before the reset fires. A windowed watchdog adds a lower bound: kicking it too early also triggers a reset. This catches firmware that is looping too fast, which can indicate a software fault just as a stall can. STM32 devices, for example, offer both an IWDG (independent, free-running) and a WWDG (windowed, clocked from the
APB bus).
Should I kick the watchdog inside an interrupt service routine?
Generally, no. Kicking the WDT from an
ISR means the watchdog will keep being fed as long as interrupts are firing, even if the main application thread is completely hung. For the watchdog to be effective, it should be kicked from a code path that exercises the parts of the firmware you actually want to monitor.
How do I choose the watchdog timeout period?
Measure or bound the
worst-case execution time of your main loop (or the interval between intended kicks), then set the timeout to a comfortable margin above that — typically two to five times the expected kick interval. Too short risks spurious resets under heavy but legitimate load; too long delays recovery from a real fault. Some teams use a heartbeat LED during development to make loop timing visible before finalising the timeout value.
Can the watchdog be disabled at runtime?
On many MCUs, the watchdog can be disabled in firmware or via configuration fuses, but some parts lock the WDT once enabled and do not allow it to be turned off without a reset. For example, the STM32 IWDG cannot be stopped once started. Check the specific device datasheet, and be aware that safety-critical applications often require the watchdog to be always active.
How should a watchdog be handled in an RTOS-based system?
Kicking the hardware WDT directly from one task only confirms that task is alive. A more robust approach is a software 'task monitor': each RTOS task periodically signals a central watchdog task (using flags,
semaphores, or a counter array), and the watchdog task kicks the hardware WDT only after all monitored tasks have checked in within their expected periods. This way a hang in any individual task will eventually cause a system reset.
Differentiators vs similar concepts
A watchdog timer is sometimes confused with a general-purpose hardware timer or a software timeout. A general-purpose timer generates an
interrupt or sets a flag on expiry but does not reset the CPU on its own. A software timeout is simply a counter checked in application code, which cannot fire if the code itself has hung. The watchdog is distinct because its reset action is autonomous in hardware: assuming it is correctly configured and its clock source is running, it fires regardless of the state of the CPU or software
stack.
