Articles

Watchdog Supervision: Prove That Required Tasks Make Progress

Sawsan Sayad
By Sawsan SayadLinkedIn

Sawsan is a robotics and AI enthusiast with an interest in researching and writing about emerging technology.

8 min read

A watchdog should be refreshed because the required work is progressing, not merely because a timer interrupt still runs. Before accepting an embedded prototype, define which functions must demonstrate progress, how long each may take, and what the product will do when that evidence stops. Then deliberately stall those functions in a controlled test.

A blinking status LED can coexist with a blocked measurement task or an unresponsive command handler. For a founder commissioning custom electronics, “the watchdog is enabled” is therefore an incomplete answer. Ask what failure it detects and which test proves that detection.

Define the work that counts as progress

Start with a short supervision contract. For each required function, record its completion condition, maximum permitted interval between completions, operating modes and failure response. A function waiting correctly for an external event is different from one that has stopped executing. The contract must describe both.

For example, an acquisition task might report progress after it has completed a measurement attempt and classified the result as valid or unavailable. It should not report successful measurement merely because its loop started. Conversely, a disconnected sensor need not force endless whole-device resets if the specified response is to report a fault while the rest of the product remains usable.

Separate execution health from data quality. A watchdog can detect that a task has stopped reaching an agreed checkpoint. It cannot establish that a calibration value is correct or that a sensor is measuring the intended physical quantity.

MakersGround’s historical Gomicron engineering project includes custom electronics and firmware/control alongside mechanical design. That is the relevant context for reviewing supervision across hardware and software. The project record does not identify a watchdog implementation, operating system or measured recovery performance. The approach here is general engineering guidance, not a description of Gomicron’s firmware.

Do not let one healthy task speak for every task

Consider a design in which a periodic interrupt refreshes the hardware watchdog unconditionally. If an application task blocks but interrupts continue, that refresh path may continue too. The watchdog then observes the interrupt, not the work the product needs.

One design option is a supervisor that receives separate evidence from each required function and refreshes the hardware watchdog only when the applicable conditions are met. Define how evidence expires: a permanent “healthy” flag set once during startup is not a continuing progress check. Use a reviewed scheme that distinguishes new completion evidence from an old report and handles concurrent access correctly.

As a concrete software example, Zephyr’s task-watchdog subsystem provides multiple supervision channels and can use a hardware watchdog as a fallback if the supervisor or scheduler malfunctions. Its demonstration sample includes a control thread getting stuck while the main thread remains alive. These are examples of the distinction to test, not a recommendation that every product adopt Zephyr.

Choose a timeout from two boundaries

The deadline must allow legitimate work to finish, including the relevant scheduling delays and operating conditions. It must also detect a stalled function soon enough for the product’s required response. If those boundaries leave no workable interval, increasing the timeout does not resolve the design conflict. Split the operation, revise its scheduling or reconsider the supervision architecture.

Keep the entire response budget visible. Detection, any diagnostic handling, reset and application reinitialization take time. A nominal watchdog interval alone is not a guarantee of restored service within that interval. Record which clock establishes each deadline and how its tolerance affects the earliest and latest timeout.

Zephyr’s task-watchdog configuration, for example, explicitly provides additional hardware-fallback delay for corrective actions and differences between clock sources. Check the actual device and software revision rather than copying its default values into another product.

Windowed supervision adds an early boundary

A conventional timeout watchdog checks whether refresh arrives before expiry. A window watchdog also rejects a refresh that arrives too early. TI’s window-watchdog explanation describes both boundaries. This can expose an incorrectly fast refresh sequence, but it does not independently prove that useful application work was completed.

Do not treat “independent” and “windowed” as interchangeable descriptions. Clock independence and an allowed refresh window answer different questions. In the STM32C5 DS14928 watchdog description, the independent watchdog has its own clock, while the system window watchdog uses a clock derived from APB. Those details are specific to that device family; verify the selected part’s clock, reset and low-power behavior.

A hypothetical prototype supervision review

Imagine a non-safety bench instrument with an acquisition function and a local command handler. This is a hypothetical example, not a MakersGround deployment. Its supervision contract requires each function to finish its own bounded unit of work and report a fresh completion. An idle command handler reports completion of its specified service cycle, not the arrival of a new user command.

The supervisor checks both reports against their separate deadlines. If acquisition stalls while the command handler continues, the latter cannot clear the acquisition failure. The defined response records the fault where feasible and withholds the watchdog refresh. The hardware response must be configured and verified, rather than assumed to reset automatically.

After reset, the instrument establishes its required state before reporting readiness. If the fault recurs, the team needs a bounded recovery policy and a visible diagnostic condition rather than an unexplained restart loop. The deadlines and permitted restart behavior must come from the actual application requirements; this illustration deliberately supplies no universal timing value.

Two function progress reports feed a supervisor. Both current permits watchdog refresh; a missing or overdue report withholds refresh and leads to the configured timeout response.
Hypothetical bench instrument. Each required function supplies fresh progress evidence. The supervisor permits watchdog refresh only when both functions meet their own deadlines. A running command handler must not conceal stalled acquisition. This is a conceptual supervision map, not a circuit diagram or a safety architecture.

Test the fault paths with the release configuration

Run fault injection on a dedicated development setup with potentially hazardous outputs isolated. This checklist is not a machine-safety design or certification method. A processor reset is not evidence that motors, heaters or other outputs reach a safe condition.

  • Stall one supervised function. Keep another function running. Verify that the healthy function cannot mask the stalled one, and measure the time from the last valid progress report to the specified response.
  • Stall the supervisor. Where the architecture permits a controlled test, verify that the hardware fallback still operates when software supervision no longer executes.
  • Exercise legitimate long operations. Include startup, storage maintenance, communications delays and the busiest supported workload. Establish whether they finish within their contract rather than adding unconditional refreshes to suppress failures.
  • Check operating-mode transitions. Document when supervision starts, pauses or changes during sleep, wake and update operations. Verify the actual hardware behavior in each supported mode.
  • Exercise the early boundary if present. Confirm that an out-of-window refresh causes the configured response. A successful late-timeout test does not cover this case.
  • Repeat without the debugger’s assistance. Use the intended release configuration and verify that a debug setting has not silently paused or disabled supervision.

That last check matters in real vendor tooling. The ESP-IDF ESP32 watchdog guide describes OpenOCD disabling watchdog hardware at breakpoints without re-enabling it afterward. It also distinguishes a task-watchdog warning from a configured panic/reset response. These are ESP-IDF-specific behaviors, but they illustrate why a test record must name the configuration and observed action, not just the presence of a watchdog API call.

Retain enough evidence to explain a restart

Where the hardware supports it, capture reset-cause information early in startup and preserve it according to the device documentation. Decide which small diagnostic record can be retained without depending on the task that just failed. Do not rely on a final log message from stalled code, or let an unlimited logging operation delay the intended response.

Keep supervision coverage separate from recovery coverage. The former asks whether the fault was detected and acted upon; the latter asks whether stored state, peripherals and application readiness are trustworthy afterward. Our embedded recovery checklist covers related restart questions, although a watchdog reset and a loss of power need not reset the same parts of a system.

For the next prototype review, request a supervision map, a timing budget and fault-test evidence tied to the exact hardware and firmware revision. Record known gaps as well as passes. Within an electronics and firmware development scope, this is a concrete way to define what “the device recovers” must mean before accepting it.

Sources and checking date

Technical and company sources opened on 23 October 2026. Rolling documentation and repository branches may change; check the selected product and release before implementation. The vendor examples do not establish MakersGround’s historical technology stack.