Zephyr OS Task Watchdog Channels: Feed the Worker That Actually Made Progress
A device can keep servicing a timer while its useful work is stuck. If one healthy thread feeds every task-watchdog channel, the monitoring code may report continued health without observing the stalled worker at all.
In Zephyr OS, define the meaning of each feed before selecting timeout values. This review uses the v4.4.0 task-watchdog implementation and API. It proposes fault tests rather than claiming any hardware watchdog or recovery sequence has been validated.
Assign a channel to an observable obligation
The tagged task-watchdog API provides initialization, channel registration and per-channel feeding. Hardware fallback is optional; initialization takes a watchdog device or NULL. Initialization must precede adding or feeding channels, and its failure must be handled.
A useful application policy associates a channel with a concrete obligation: the acquisition worker completed its bounded cycle, the control worker processed its input, or a communications worker completed an allowed idle or service interval. These are suggested policies, not behaviors the API infers automatically.
Do not make “thread exists” equivalent to “task completed.” A worker can repeatedly run an error loop without delivering its required result. Conversely, a worker waiting for optional traffic may legitimately have nothing to process. Its health definition should include the expected idle state rather than require imaginary incoming packets.
Understand what a feed actually refreshes
In the v4.4.0 implementation, feeding updates the selected channel's absolute deadline and reschedules the shared timer around the earliest relevant deadline. The function receives a channel ID, not proof that its associated application task progressed. Channel IDs therefore need an ownership policy outside the API.
Registration uses a finite channel array and can fail when no entry is available. A newly registered channel is fed during registration. Treat allocation failure as a monitoring-coverage failure, rather than continuing with a worker that silently lacks its intended channel.
For a hypothetical two-worker product, let the acquisition and processing workers report independently. Stop the processor while allowing acquisition to continue. The processor's deadline should still expire. Then stop acquisition instead. This two-direction test is more informative than observing one successful reboot after stopping the whole system.
Keep the timeout action small and deliberate
The source invokes a supplied timeout callback, or cold-reboots when no callback is supplied. Its timer path runs in interrupt context. A callback design must therefore respect that context; a timeout is not a safe opportunity for blocking filesystem uploads or a long diagnostic conversation.
Decide what minimal evidence can be captured without depending on the failed subsystem. A channel identifier and a small preallocated status record may be more useful than an ambitious recovery routine that waits on the same stalled worker. The appropriate persistence mechanism remains board- and product-specific.
Also decide whether a callback merely reports the failure or initiates a bounded recovery. Returning from an application callback should not be interpreted as evidence that normal monitoring and application progress have been restored. Verify the resulting timer and recovery behavior explicitly.
Separate task stalls from loss of timer execution
With hardware fallback enabled, the implementation can feed the hardware watchdog through a background channel when ordinary task deadlines are longer. Hardware fallback therefore serves a different layer from the individual application obligations. Continuing hardware feeds do not mean every worker is healthy; task-level deadlines still matter.
Plan two distinct fault experiments. One leaves scheduling and timer execution available while stopping one worker's feed. The other exercises the intended hardware fallback under a controlled condition where software monitoring cannot execute. The second test must follow the board's safe test procedure and watchdog-driver constraints.
Finally, review suspend and resume policy. The tagged implementation refreshes enabled channel deadlines on resume. A resumed deadline is a grace period, not a retrospective certificate that useful work occurred during sleep. Include the first real post-resume obligation in the worker's health definition. Reliable monitoring comes from these explicit meanings, not from choosing the shortest possible timeout.
