5.5.23 · D5Embedded Systems & Real-Time Software
Question bank — Watchdog timers — purpose, feeding, types
This page assumes only the ideas from Watchdog timers — purpose, feeding, types: a watchdog is a hardware down-counter that resets the system unless software "feeds" (reloads) it in time, and it comes in hardware-only, software-controlled, and window flavours.
Symbols this page uses (defined before we trap you)
Before any trap, look at the timeline below — it is the mental picture behind every question on this page.
The counter starts full and ticks down. When it hits zero, the reset fires. The picture makes three moments vivid: the safe feed window, the countdown to zero, and the race that happens if your feed lands exactly at zero.
True or false — justify
A watchdog timer's only job is to catch infinite loops.
False. It catches any condition that stops the feed from happening in time. Concrete cases: a deadlock where two tasks each wait for the other forever; memory corruption that jumps the program counter into garbage that never reaches the feed; a stalled clock; a sensor read that blocks waiting for hardware that died. The infinite loop is just the most famous of these.
Feeding the watchdog proves the whole program is working correctly.
False. Feeding only proves the feed instruction was reached in time — nothing about what value you computed. Picture a thermostat whose control math is buggy and commands 200°C, but whose main loop still runs on schedule and feeds happily: the watchdog stays silent while the output is dangerously wrong. A watchdog checks liveness ("is the code still moving?"), never correctness ("is the code moving to the right answer?").
A hardware-only watchdog, once enabled, cannot be switched off by software.
True. That is exactly what "hardware-only" means: the enable is locked by a fuse or a write-once bit, so even a wild pointer or a runaway ISR scribbling across registers cannot clear it. Compare a software watchdog, where a single bad register write can silently disable your whole safety net.
If the main CPU clock stops, the watchdog can no longer save you.
False (for a well-designed WDT). A robust watchdog runs on a separate clock source, usually an internal RC oscillator. So when the main clock dies and the CPU freezes, the independent counter keeps ticking down to zero and fires the reset. On the timeline figure, the countdown line simply keeps sliding even though the CPU is frozen — that independence is the whole reason for the separate clock.
Doubling the prescaler doubles the timeout period.
True — and here is the vivid version. Say , ticks/s. With prescaler = 64: s. Now double the prescaler to 128: each tick waits for twice as many clock pulses, so each tick takes twice as long, and s. Nothing else in the formula changed, so the whole time scaled by exactly 2.
A window watchdog fed exactly halfway through its window behaves the same as a normal watchdog.
Partly true, and that's the trap. A mid-window feed is fine for both kinds. But the window watchdog additionally resets you if you ever feed before . So a window watchdog can only ever be stricter, never more lenient, than a plain one — a plain watchdog would happily accept the too-early feed a window watchdog rejects.
A software-controlled watchdog gives strictly more protection than a hardware-only one because it has more configuration options.
False. More options ≠ more protection. Because software can disable it, corrupted or buggy code can silently switch it off — the exact failure you wanted protection against. Imagine a stack overflow that overwrites the config register with zeros: a hardware-locked watchdog shrugs; a software one is now dead. Flexibility is bought with a weaker guarantee.
Choosing a very long timeout is the "safe" choice because it avoids false resets.
False. A long timeout makes false resets rare but makes real recovery slow — the system stays hung for the entire timeout before restarting. If that watchdog guards a motor controller, a 30-second timeout means 30 seconds of frozen, possibly runaway motor before recovery. Timeout is a tradeoff between false resets and recovery latency, not a "bigger is safer" dial.
Spot the error
wdt_reset() placed as the very first line of the main loop, before any work.
Error: no hang inside the loop can ever be detected. The counter is reloaded before the potentially-hanging work runs, so a hang inside that work still leaves a full fresh timeout at the start of every iteration. You feed, then hang — buying a whole wasted timeout period. Feed after the critical work completes, so the feed is proof the work finished.
A window watchdog fed with HAL_WWDG_Refresh() on every pass of a loop that runs far faster than .
Error: every feed is "too early" and trips the lower bound. The window watchdog resets on feeds before ; a too-fast loop feeds early, so the system resets even though nothing is hung. You must gate the feed behind a time check so it only fires once the clock is inside .
Enabling the watchdog with a 250 ms timeout, then calling delay(400) between feeds "because 400 ms of real work is fine".
Error: the delay exceeds the timeout, so the reset fires mid-delay. The margin must be positive: your longest gap between feeds must sit safely below , not above it. Here the counter reaches zero 150 ms into the delay, so the system resets roughly every 250 ms forever.
A "recovery" reset handler that re-runs the same initialization that caused the hang, with no record of why.
Error: it can create a reset loop with no diagnosis. Recovery should read the reset-source register (defined above) to know a watchdog fired, log or count it, and possibly enter a safe state instead of blindly re-attempting the crashing path. See also Fault Tolerance.
Disabling the watchdog inside a long firmware-update routine, then forgetting to re-enable it.
Error: the system now runs unprotected forever. If the disable path is taken but the re-enable is skipped (an early return, an exception, a jump), protection is silently gone with no visible symptom. Prefer a hardware-locked watchdog, or a design where the update path feeds the watchdog rather than disabling it. This ties to Bootloader Design.
Feeding the watchdog from inside a timer interrupt so "it's always fed on schedule".
Error: the interrupt can keep running while the main program is dead. If the ISR still fires but
main() has deadlocked, the ISR feeds the watchdog and hides the hang. The feed must depend on the thing you want to prove alive actually running — not on an independent timer that runs regardless.Why questions
Why feed the watchdog after critical work rather than at the top of the loop?
Because the feed is meant to be evidence that the critical work actually completed. Feeding first turns it into a rubber-stamp that proves nothing; feeding last makes a missed feed genuinely mean "we didn't finish this iteration."
Why does a window watchdog need two bounds instead of one?
The upper bound catches hangs (the feed never comes). The lower bound catches runaway behaviour — a tight loop or interrupt storm that feeds far too fast — which a one-sided watchdog cannot distinguish from healthy operation. Together they check "running and running at the right rate."
Why give a hardware watchdog its own separate clock source?
So a failure of the main clock — the most catastrophic hang, where the CPU is completely frozen — is still recoverable. A watchdog clocked from the same failing clock would freeze alongside the CPU and never fire.
Why can a watchdog reset be dangerous if you don't design the safe state first?
The reset yanks the system back to boot mid-operation. If outputs (motors, heaters, valves) aren't driven to a known-safe condition on reset, a repeated watchdog reset loop can leave actuators in an undefined, possibly hazardous state each cycle.
Why is checking the reset-source register on startup important?
A normal power-on reset and a watchdog-triggered reset look identical to naive boot code, but mean very different things. Reading the source lets you distinguish "fresh start" from "we just recovered from a hang," so you can log the fault, count it, or escalate to a safe state. See System Reset Sources.
Why is a watchdog considered part of Fault Tolerance rather than debugging?
Debugging finds and removes faults before deployment; a watchdog contains the faults you failed to remove, giving the field system automatic recovery when the unexpected happens — a tolerance mechanism, not a diagnosis tool.
Why can't a watchdog protect against a bug that produces wrong but timely outputs?
A watchdog only measures whether the feed happened in time. A program that runs on schedule but computes garbage feeds perfectly on time, so the watchdog stays silent. Correctness must be caught by other means — plausibility checks, redundancy, or a second monitoring channel.
Edge cases
What happens if the timeout period is shorter than your longest legitimate operation?
You get false resets: the valid long operation blows past before it can feed, and the system restarts mid-task repeatedly. The timeout must exceed your worst-case time between feeds, with margin.
What if a corrupted program counter jumps into the feed instruction repeatedly by accident?
A plain watchdog would be fooled — it sees feeds and stays quiet. This is where a window watchdog helps: random jumps rarely produce feeds at the right rate, so early or late feeds still trip a reset.
What happens at the exact instant the counter reaches zero while a feed is executing?
This is a genuine race — see the red "race at zero" marker on the timeline figure. Hardware resolves it deterministically (usually the reset wins, or the reload is atomic), but you must never rely on the answer: always keep a real margin below so the race never happens in the first place.
What if asynchronous interrupt jitter or ISR latency delays your feed?
This is the subtle timing edge case. Your loop may intend to feed at 70 ms, but if a burst of interrupts (or one long ISR) steals CPU time, the feed instruction is postponed. Two things can go wrong: with a plain watchdog the delayed feed may slip past and cause a false reset; with a window watchdog, jitter can push the feed out either side of . The fix is to size the window against worst-case interrupt latency, not the nominal timing. Related: Interrupt Service Routines and Real-Time Operating Systems.
What if the write to the watchdog register itself fails — a bus error or an ECC-corrected fault stalls the store?
Then a "valid" feed silently never lands: the code ran, called the refresh, but the counter was not actually reloaded, so the watchdog times out and resets even though the software was alive. This is a real failure mode on complex SoCs. Defences: read back the counter to confirm the reload, or treat an unexpected watchdog reset (via the reset-source register) as a signal that the register path itself may be faulty. Ties to Fault Tolerance and Hardware Timer Peripherals.
What if you set the timeout to the maximum possible value, effectively "off"?
The watchdog technically still runs but is so slow it provides almost no timely protection — a hung system stays frozen for minutes. Functionally this is a disabled watchdog dressed as an enabled one, defeating the purpose.
How does a watchdog interact with a system that legitimately spends long periods in sleep / low-power mode?
You must either use a watchdog that keeps counting in that sleep mode (and feed via a wake source) or one that pauses in deep sleep. A mismatch causes either a false reset during valid sleep or lost protection during sleep. Related: Real-Time Operating Systems and Hardware Timer Peripherals.
What if the watchdog's own oscillator drifts with temperature?
The real timeout drifts too, so a "500 ms" watchdog might fire at 400 ms or 650 ms across temperature. Size your feed margin against the worst-case timeout, not the nominal one.
Can a watchdog reset coincide with a brown-out event, and does it matter?
Yes — a sagging supply can both corrupt software (triggering the watchdog) and trip brown-out detection. The reset-source register flags help you tell which fired first, so recovery code doesn't misattribute a power fault to a software hang.
Recall Self-test: which watchdog for which fault?
Match the fault to the strongest defence. Program counter corrupted so software disables the WDT ::: Hardware-only (locked) watchdog — software cannot switch it off. Interrupt storm feeding far too fast ::: Window watchdog — the lower bound catches early feeds. Main clock dies, CPU frozen ::: Any watchdog on a separate clock source — it keeps counting. Need to disable protection during a firmware update ::: Software-controlled watchdog — but design the re-enable carefully.