{"id":4773,"date":"2026-10-23T12:50:49","date_gmt":"2026-10-23T09:50:49","guid":{"rendered":"https:\/\/makersground.com\/?p=4773"},"modified":"2026-10-23T12:50:49","modified_gmt":"2026-10-23T09:50:49","slug":"watchdog-supervision-stalled-work","status":"publish","type":"post","link":"https:\/\/makersground.com\/ar\/watchdog-supervision-stalled-work\/","title":{"rendered":"Watchdog Supervision: Prove That Required Tasks Make Progress"},"content":{"rendered":"

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.<\/p>\n

A blinking status LED can coexist with a blocked measurement task or an unresponsive command handler. For a founder commissioning custom electronics, \u201cthe watchdog is enabled\u201d is therefore an incomplete answer. Ask what failure it detects and which test proves that detection.<\/p>\n

Define the work that counts as progress<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u062e\u062f\u0645\u0627\u062a MakersGround \u0641\u064a historical Gomicron engineering project<\/a> 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.<\/p>\n

Do not let one healthy task speak for every task<\/h2>\n

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.<\/p>\n

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 \u201chealthy\u201d 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.<\/p>\n

As a concrete software example, Zephyr’s task-watchdog subsystem<\/a> provides multiple supervision channels and can use a hardware watchdog as a fallback if the supervisor or scheduler malfunctions. Its demonstration sample<\/a> 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.<\/p>\n

Choose a timeout from two boundaries<\/h2>\n

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.<\/p>\n

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.<\/p>\n

Zephyr’s task-watchdog configuration<\/a>, 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.<\/p>\n

Windowed supervision adds an early boundary<\/h3>\n

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<\/a> describes both boundaries. This can expose an incorrectly fast refresh sequence, but it does not independently prove that useful application work was completed.<\/p>\n

Do not treat \u201cindependent\u201d and \u201cwindowed\u201d as interchangeable descriptions. Clock independence and an allowed refresh window answer different questions. In the STM32C5 DS14928 watchdog description<\/a>, 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.<\/p>\n

A hypothetical prototype supervision review<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"Two
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.<\/figcaption><\/figure>\n

Test the fault paths with the release configuration<\/h2>\n

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.<\/p>\n