THE BASIC WATCHDOG
A watchdog asks one question: did software check in before the deadline?
A hardware watchdog timer normally runs independently enough from the main program that ordinary code must periodically service, clear, kick, feed, or refresh it. If the program fails to do so before timeout, the watchdog generates a reset or another fault action.
This can recover from some deadlocks, runaway loops, scheduler failures, corrupted control flow, blocked tasks, or transient faults. It is useful precisely because the failing software does not have to decide to reset itself.
But the watchdog sees very little. A system can be producing dangerously wrong outputs while still refreshing the timer. A communications stack can be alive while the control loop is dead. A main loop can service the watchdog while one critical task is permanently stalled.
“The watchdog did not fire” therefore does not establish health.
BAD FEEDING
If every code path can pet the dog, the dog learns nothing.
The easiest watchdog implementation is often the weakest: refresh it from a timer interrupt or unconditional main-loop path.
If the timer interrupt remains alive while the application is deadlocked, the watchdog never expires. If the main loop spins rapidly through a broken state and continues to kick the timer, the machine can remain functionally dead forever while the watchdog reports success by silence.
A stronger pattern ties watchdog service to meaningful progress. Critical tasks publish evidence that they completed required work within a defined interval. A supervisory task refreshes the hardware watchdog only when the required progress set is satisfied.
The definition of “progress” is application-specific. It may mean a control loop advanced, communications were serviced, storage state remained healthy, sensor data is fresh, an actuator supervisor is responding, and a scheduler heartbeat changed. The point is to monitor useful work rather than CPU motion.
WINDOWED WATCHDOGS
Too fast can be wrong too.
A conventional watchdog detects late or missing refresh. A windowed watchdog also rejects refreshes that arrive too early.
This matters because some failures cause code to execute the watchdog service path repeatedly or out of sequence. If a broken loop refreshes the timer thousands of times per second, a normal watchdog may remain perfectly satisfied. A windowed watchdog can detect that the program reached the service point sooner than legitimate execution permits.
Window mode therefore constrains both sides of the timing contract: not too late, not implausibly early.
It still does not prove the entire application is correct. It simply makes the liveness monitor harder to fool accidentally.
INDEPENDENCE
A watchdog should not depend on the thing it is watching more than necessary.
If the watchdog uses the same clock, power domain, scheduler, interrupt path, and software state as the subsystem being monitored, a common failure can disable both monitor and victim.
Many microcontrollers therefore provide watchdogs with an independent or separately derived clock source. Some safety architectures add an external supervisor or second processor so the recovery mechanism retains authority when the primary MCU is compromised.
Independence is not absolute. External supervisors still share power, board environment, reset wiring, and system assumptions. The engineering question is whether one plausible fault can disable both the protected function and the monitor intended to detect it.
TIMEOUT
The timeout is an operational contract.
A timeout that is too short creates nuisance resets during legitimate worst-case work. A timeout that is too long allows a failed system to remain uncontrolled or unavailable for too long.
Choosing the interval requires worst-case execution timing, task periods, scheduler behavior, startup conditions, flash operations, communications delays, sleep modes, interrupt storms, overload behavior, and the hazard created while the system remains stuck.
Average execution time is not enough. If garbage collection, logging, filesystem maintenance, thermal throttling, or a rare communication path can delay progress legitimately, the watchdog design must know whether that work belongs inside the monitored window or outside it.
A watchdog timeout is therefore another latency budget.
RESET IS NOT RECOVERY
The CPU can reboot while the machine stays broken.
An embedded product is usually more than one processor.
External peripherals may remain powered. A motor driver may retain a latched fault. A modem may still have an open network session. A sensor may remain wedged on a bus. A co-processor may think the previous transaction continues. A power latch may keep a load energized. A storage device may have been interrupted mid-write.
If the watchdog resets only the MCU, startup code must reconcile the rest of the system. In some designs the correct recovery action is broader: reset selected peripherals, cycle a power domain, reinitialize a bus, disable outputs, assert a hardware safe state, or escalate to full system power cycling.
The reset scope must match the failure scope.
SAFE OUTPUTS
Reset pins have electrical behavior before firmware gets a vote.
During reset, GPIO may become high impedance, inputs, or device-specific default states. Pull-ups, pull-downs, gate resistors, relay drivers, enable pins, motor controllers, and power switches decide what the external hardware does while the CPU is unavailable.
If a safe state depends on firmware executing three milliseconds after reset, then the machine has a three-millisecond interval where safety depends on assumptions about hardware defaults and boot timing.
Critical outputs should therefore have hardware biasing and interlocks that produce an acceptable state during reset, brownout, programming, bootloader operation, and CPU absence.
EVIDENCE
A reboot that erases the failure is an expensive magic trick.
Watchdog recovery can make an intermittent system appear reliable by turning visible hangs into invisible reboots. That may improve availability while simultaneously making the root cause harder to find.
Capture reset cause as early as possible. Preserve bounded fault context when feasible: task heartbeat states, last successful operation, scheduler counters, stack watermark, fault registers, bus errors, exception information, power state, and a compact event history.
Persistent fault records must themselves tolerate interrupted power and repeated resets. The recording path should be simple enough that a damaged system does not require a miniature database transaction just to admit it crashed.
The best watchdog event is one that both recovers service and leaves enough evidence to eliminate the underlying defect later.
RESET LOOPS
Repeated recovery attempts are evidence that recovery failed.
If a device reboots every ten seconds forever, the watchdog is not maintaining availability. It is maintaining a ritual.
Systems should track repeated reset frequency and escalate behavior. After a defined number of watchdog resets in a time window, the machine may enter a reduced-function safe mode, disable a suspect subsystem, roll back configuration, choose an alternate firmware image, stop retrying a destructive operation, expose a diagnostic interface, or require operator intervention.
Backoff is often important. Hammering a failed peripheral or network endpoint immediately after every reset can reproduce the same overload condition indefinitely.
A recovery architecture has levels. Reset is one level.
STARTUP
Startup should assume the previous execution died anywhere.
A watchdog can interrupt code at an arbitrary instruction. That means reboot begins after a potentially incomplete transaction.
Robust initialization is idempotent where practical: running it after a clean boot or an interrupted prior execution leads to the same defined state. Persistent structures are validated before use. Temporary files or partial records are recognized. Peripherals are reset or queried. stale commands are discarded. Outputs remain safe until dependencies are ready.
If startup assumes shutdown completed cleanly, watchdog recovery eventually finds the one state transition that makes that assumption expensive.
MULTITASKING
One system watchdog needs a policy for many tasks.
In an RTOS, multiple tasks can fail independently. Letting each task refresh the hardware watchdog creates an obvious problem: one healthy task can hide another dead task.
A common pattern gives each critical task a heartbeat or deadline. A supervisor verifies them all and refreshes the hardware watchdog only if the required set made progress. Less critical tasks may have local restart mechanisms without forcing a full reset.
Priority inversion, starvation, deadlock, and scheduler overload complicate the picture. A heartbeat can change even if the task's output is useless. Supervisors therefore need semantics beyond “counter incremented” for the most important functions.
SOFTWARE WATCHDOGS
A software timer can monitor detail, but it cannot outrank its own runtime.
Software watchdogs are useful for task-level supervision, request timeouts, state-machine deadlines, and subsystem recovery. They can identify which component is late and attempt targeted remediation.
But a software watchdog scheduled by the same kernel and CPU cannot respond if the entire scheduler, interrupt system, clock, or processor is wedged. That is why hardware and software monitoring complement each other.
Software can provide diagnosis and selective recovery. Hardware can retain final authority to force progress when software no longer executes reliably.
TESTING
Test the watchdog by creating the failures it claims to detect.
A watchdog that has never been allowed to expire in a controlled test is a belief, not a verified mechanism.
Deliberately stop refreshing it and confirm reset occurs. Refresh too early in window mode and confirm violation detection. Deadlock a critical task while leaving the scheduler alive. Disable interrupts. Hang a peripheral call. Saturate CPU load. Test during flash operations and low-power modes. Confirm reset cause survives. Confirm outputs are safe during the reset interval. Confirm startup recovers external devices.
Then create repeated failures and verify escalation. The machine should not reboot forever without eventually admitting it has a persistent fault.
FIELD METHOD
Questions for a watchdog design review.
What exact failure is the watchdog intended to detect?
What evidence of useful progress gates refresh?
Can a runaway loop refresh it accidentally?
Is the watchdog independent enough from the protected code?
Does the timeout cover real worst-case timing without masking dangerous stalls?
What hardware remains unchanged when the MCU resets?
What state do outputs take during reset?
How is reset cause preserved?
What happens after the third watchdog reset in one minute?
Can the startup path safely recover from interruption at any previous state transition?
BOTTOM LINE
The watchdog notices silence. Recovery decides what silence means.
A good watchdog is simple, independent, hard to fool, tied to meaningful progress, and tested under real failure injection.
Detection is not diagnosis. Reset is not recovery. Repeated reset is not success.
Use the watchdog as the final timer in a layered resilience system, not as the entire resilience system wearing one register.
SOURCE TRAIL
Technical starting points.
Microchip — Windowed Watchdog Timer introduction and operation
Microchip — Windowed Watchdog Timer reset behavior
Microchip — Windowed watchdog diagnostic startup test