Watchdog Reset Loop

A watchdog reset loop is a repeated reboot or restart cycle in which a watchdog or supervisor resets a system, but the original fault remains and triggers the watchdog again after restart. The system appears to recover briefly, then returns to the same failure.

This pattern appears in embedded controllers, industrial gateways, medical devices, aircraft equipment, power electronics, network appliances and supervised firmware. It is a recovery design failure, not only a watchdog setting problem. A reset that repeats the same unsafe state can reduce availability, erase evidence, stress hardware and hide the true fault from operators.

Loop Timing

Let the watchdog timeout be:

reset handling time be:

boot and startup time be:

and time from startup to fault recurrence be:

The reset-loop period is:

The approximate reset rate is:

This period matters because it controls operator visibility, diagnostic retention, output cycling and stress on power stages, relays, storage and communication links.

Persistent Fault Condition

A reset loop exists when the reset action does not remove the fault condition:

and the same supervision rule trips again:

Common causes include unavailable dependencies, corrupted configuration, full storage, failed sensors, unsafe boot defaults, firmware rollback failure, repeated deadline misses, power instability, blocked communication, memory exhaustion or a startup routine that re-enables the failing output before diagnosis is complete.

Escape Policy

A robust design has an escape policy. After:

resets inside a time window:

the system may enter degraded mode, latch a fault, keep outputs safe, require operator action, disable a feature, roll back firmware or stop retrying the same startup path.

The time to escape is:

For requirement:

the reset counter, retained state and boot logic must all survive the reset mechanism that is being used.

Diagnostic Retention

If each reset overwrites volatile evidence, the loop can become impossible to diagnose. Persistent diagnostic capacity should cover at least:

events: the first fault, each reset, and the final escape action. Useful records include reset cause, firmware version, boot mode, fault flags, last health counters, task progress, queue age, voltage state, temperature state and output-safe verification.

Storing diagnostics can itself create timing risk if flash writes block real-time work. The design should separate emergency retention from slow logging.

Worked Example

A controller has:

reset handling:

boot time:

and the same dependency fault recurs after:

The loop period is:

If the firmware enters degraded safe mode after:

consecutive watchdog resets, then:

For an allowed escape time:

the timing screen passes:

If the reset counter is stored only in RAM and is cleared by the watchdog reset, then the escape policy is not real. The system will keep repeating the first-reset behavior.

Safe-State Behavior

The safest reset loop is the one that cannot energize unsafe outputs during reboot. Outputs should have defined hardware defaults, interlocks, pull states or external supervisors that do not depend on normal firmware being alive. Boot code should not re-enable actuators, drives, valves or therapy outputs until fault state, configuration and operator command are valid.

Recovery should distinguish clean boot, watchdog reset, brown-out reset, failed update rollback and repeated reset. Treating every boot as normal startup is a common reason reset loops become hazardous.

Validation Evidence

Validation should force the persistent condition, not only a single watchdog timeout. Useful evidence includes retained reset cause, reset counter, boot trace, output state during reset, safe-state latch, degraded-mode entry, diagnostic record integrity, dependency-unavailable test, storage-full test, failed-update test, brown-out test and operator alarm timing.

The release test should prove both recovery and escape. A system that resets correctly once but loops forever under the same fault has not passed fault recovery.

Relationship To Neighbor Terms

A watchdog timer is the supervision mechanism. A watchdog reset loop is a failure pattern involving that mechanism. A retry storm repeats requests; a reset loop repeats restart behavior. Livelock is active no-progress behavior without necessarily rebooting. Deadline misses, task starvation, deadlock, interrupt lockout or corrupted state can trigger the watchdog that starts the loop.

Safe state and degraded mode are the usual escape destinations. Reliability evidence should state whether repeated resets count as successful recovery, degraded availability or failure.

Common Mistakes

The most common mistake is treating a watchdog reset as proof of recovery. Another is clearing the reset counter on every boot. A third is losing diagnostics before they are written. A fourth is re-enabling outputs before knowing why the previous boot failed. A fifth is setting a shorter watchdog timeout when the real issue is a persistent dependency or unsafe startup sequence.

A strong watchdog-reset-loop review states the loop period, trigger, retained reset count, diagnostic evidence, safe-state behavior, escape policy and validation test that proves the loop stops under the persistent fault.