In short: a watchdog timer is a free-running hardware counter that resets the microcontroller unless firmware periodically "kicks" it before it expires. It is the last line of defence against a hung or runaway program, turning a silent lock-up into an automatic recovery.
A watchdog timer (WDT) is a dedicated hardware counter inside a microcontroller whose only job is to detect when software has stopped behaving normally. The counter counts down (or up) from a preset value toward a threshold. Healthy firmware must repeatedly reload the counter before it reaches that threshold — an action called "kicking", "feeding", "petting" or "refreshing" the watchdog. If the firmware ever fails to refresh in time, the counter expires and the watchdog forces a system reset, pulling the device out of a frozen state without any human intervention.
The underlying assumption is simple but powerful: a correctly running program will always reach its refresh point on schedule, while a crashed, deadlocked, or runaway program will not. The watchdog therefore acts as a hardware proxy for "is the software still alive?".
Embedded systems frequently run unattended for months or years — in a car engine controller, a pacemaker, a water meter, or a satellite. When the main program hangs, there is usually no operator to press a reset button. Faults that a watchdog guards against include:
Without a watchdog, any of these leaves the product dead until power is physically cycled. With one, the system reboots itself within milliseconds and, in most cases, resumes normal operation. This is why functional-safety standards such as ISO 26262 (automotive) and IEC 61508 (industrial) effectively mandate watchdog supervision for critical controllers.
At reset or during initialisation, firmware configures the watchdog with a timeout period (often a few milliseconds to a few seconds) and then enables it. From that point the counter runs continuously off a clock source — frequently an independent low-speed oscillator so the watchdog keeps ticking even if the main system clock fails.
During normal operation the program periodically writes a specific value or key sequence to a watchdog register, reloading the counter. The common structure looks like this:
A well-designed refresh does more than blindly write the register. Good firmware gates the kick behind evidence that every critical task is actually running — for example, each task sets a flag, and the supervisor only feeds the watchdog when all flags are present, then clears them. This catches a single stalled task even while the rest of the system still loops.
Not all watchdogs are the same. Two variants dominate modern microcontrollers, and interviewers love the distinction.
An independent watchdog runs from its own dedicated low-speed oscillator, electrically separate from the main CPU clock tree. Because it does not depend on the system clock or PLL, it still fires even if the primary clock dies or the PLL fails to lock. This independence makes it the preferred choice for safety-critical designs. Its one weakness is that you can usually only refresh it "early" — it enforces a maximum interval but not a minimum.
A windowed watchdog enforces both a lower and an upper bound. The refresh is only accepted inside a valid time window: if firmware kicks too early it is treated as a fault just as surely as kicking too late. This catches a subtle failure mode the independent watchdog misses — a program stuck in a tight, fast loop that happens to hit the refresh instruction far too often. The window therefore verifies that timing, not just liveness, is correct. Many MCUs let you use both an independent and a windowed watchdog together for layered protection.
Choosing a good timeout is an engineering judgement. Too short and legitimate long operations (a flash erase, a bootloader update) trip a false reset; too long and the device sits frozen for an uncomfortable interval before recovery. Teams typically size the timeout a little above the worst-case loop time with margin, and temporarily suspend or extend the watchdog around known long blocking operations.
Production practice also includes:
Real projects and industry tool flows, with certification.
Explore CourseTron Courses →Because a timer interrupt keeps firing on its own hardware schedule even if the main application has crashed or deadlocked. Kicking the watchdog from that ISR would keep the counter alive while the real program is dead, so the watchdog can never detect the hang. The refresh must sit on the main execution path, ideally gated by proof that all critical tasks ran.
An independent watchdog runs off its own clock and only enforces a maximum refresh interval, so it survives a main-clock failure. A windowed watchdog enforces both a minimum and maximum interval — refreshing too early is also a fault — which additionally detects code that is looping far too fast or running out of expected timing.
Measure the worst-case time of your main loop including the longest legitimate blocking operation, then add margin. The timeout should be long enough that normal operation never trips it, yet short enough that a genuine hang is recovered quickly. Long known operations such as flash writes are handled by refreshing within them or briefly reconfiguring the watchdog.
Most MCUs latch the reset source in a status register that survives the reset. On boot, firmware reads this register, distinguishes a watchdog reset from a power-on or brown-out reset, and logs it. Counting watchdog resets in the field is a key reliability metric and a starting point for root-cause debugging.
Related: interrupts in embedded systems · the VLSI Glossary · all courses.