SBC Hardware Watchdogs for Android and Linux: Design and Test

The display is frozen, the network still answers, and the watchdog never fires. This is a plausible design failure even when every timer register is configured correctly: the thread feeding the watchdog is alive, but the useful work has stopped.

An SBC hardware watchdog is a timer that can trigger a recovery action when expected servicing stops. Its value depends on what permits that servicing, what the timeout actually resets, and whether the system can recover afterwards. A GPIO toggling once per second proves very little on its own.

For Android and Linux products, design the health policy first and select the timer second. The examples below describe engineering patterns, not a safety-certified architecture or results from a particular board test.

1. Define the Failure You Need to Recover From

Separate an application failure from an operating-system failure, and both from a peripheral that remains stuck through a processor reset. Each may need a different action.

An application supervisor can detect missing progress and restart a process while the OS still functions. A hardware timer provides another recovery path when software can no longer service it. An external timer can reduce dependence on the SoC, but its actual independence depends on its clock, power, enable controls, and reset wiring.

Do not reset merely because an external server is unreachable. Rebooting will not repair the Internet, and repeated restarts can prevent local operation that would otherwise remain useful. Distinguish missing external input from a failure to process input that is already available.

For machinery or other hazardous equipment, safe behavior must be defined independently by the responsible safety design. A general-purpose SBC watchdog is not, by itself, a functional-safety solution. The application may need to make outputs safe before reboot, while separate hardware must handle cases where software cannot do so.

2. Feed on Progress, Not on a Free-Running Thread

A useful health report identifies completed work: a control-interface transaction processed, a fresh display state rendered, a database operation completed, or a queue advancing within its required deadline. Choose signals tied to the product’s function.

Assign each required subsystem an explicit health condition and age limit. The watchdog owner services the timer only when the required conditions are satisfied. A monotonic clock avoids wall-clock changes invalidating those age checks.

Be careful with asynchronous pipelines. A camera thread may keep incrementing a counter while the consumer is blocked and the displayed image remains stale. Check the boundary that matters, such as the latest frame successfully consumed, not simply the number captured.

Also define inactivity correctly. An idle user interface should not fail a test that expects touch events. A disconnected sensor should report a known degraded state rather than pretend to have new measurements. Health means the software is handling its current state correctly, not that every input is continuously active.

A staged response often makes sense: mark the function degraded, attempt a bounded service restart, and escalate if recovery fails. Each stage needs a deadline. An infinite sequence of “try again” operations can keep a broken product alive indefinitely while the hardware watchdog is dutifully fed.

Memory pressure is another reason to use meaningful checks. A communications service killed under Android memory pressure can disappear while an unrelated feeding process continues to run. The watchdog policy should know whether that service is required for the current operating mode.

3. Know Who Owns the Linux Watchdog Device

Linux commonly exposes watchdog devices through /dev/watchdog or numbered device nodes. Opening a device can arm it. The Linux watchdog API documentation describes keepalives, timeout operations, and close behavior, including optional magic-close support and nowayout configurations. Do not assume closing a file descriptor safely disables every timer.

Inventory first. On a Linux development board, reading existing sysfs attributes does not require opening the watchdog device:

ls /sys/class/watchdog/
cat /sys/class/watchdog/watchdog0/identity
cat /sys/class/watchdog/watchdog0/timeout
cat /sys/class/watchdog/watchdog0/nowayout

These files may be absent or restricted on a particular BSP. Their absence is not proof that the hardware lacks a watchdog. Ask the supplier which driver and device-tree configuration are in use. On Android, access also depends on service design and SELinux policy; do not weaken production permissions to make a test script work.

There should be one deliberate owner of each hardware timer. Check whether init, a system manager, a vendor daemon, or your own service already owns it. Adding another feeder can hide the failure your application intends to report.

The kernel watchdog-core documentation also explains that core behavior can include hardware keepalives under specific driver conditions. Timeout resolution and supported operations vary; read back the accepted configuration rather than assuming the requested value became the exact hardware period. Pretimeout support is optional.

Those details are reasons to verify the actual kernel and driver, not to disable the watchdog. Keep the configured owner, effective timeout, and stop behavior in the product’s software baseline.

4. Check the Reset Tree and the External Circuit

An external watchdog’s output must reach something capable of recovering the failed system. Trace it from the timer through reset logic or the power-management circuit. Identify which rails and peripherals remain powered.

A processor reset may leave a USB peripheral, display bridge, or modem unchanged. If a required peripheral can remain wedged in that state, test a targeted reset or power-control path. Avoid assuming that a signal named RESET resets everything on the board.

As a concrete component example, TI’s TPS3431 provides a programmable watchdog timeout, an active-low open-drain output, and enable controls. Those features require board-level decisions about pull-ups, voltage compatibility, reset pulse requirements, and who may disable the timer. The component is an example, not a complete circuit recommendation or a voltage-monitoring guarantee.

Include tolerances when choosing timing components. A nominal timeout is not an exact deadline across temperature and manufacturing variation. The minimum timeout must tolerate valid servicing delays; the maximum timeout must still meet the product’s recovery requirement.

Review the watchdog supply itself. If the timer loses power whenever the monitored system misbehaves, the supposed independence may not exist. Similarly, an unprotected software-controlled disable pin can undermine the intended recovery path.

5. Boot, Updates, and Shutdown Need Explicit Handoffs

A runtime timeout selected for a responsive application may be too short for early boot or a supported maintenance operation. That does not justify leaving the product unprotected indefinitely. Define separate states and bounded transitions.

Document when the bootloader starts servicing, how the kernel takes over, when the userspace owner becomes responsible, and what happens if any stage never completes. Test those boundaries; a gap in ownership can produce resets that seem random during startup.

Use measured worst-case durations for valid work, with an explained margin. Do not derive the timeout from average boot time on a warm, clean development unit. Storage recovery, cold conditions, or a full database can change the sequence.

Updates deserve a distinct policy. If the normal application is intentionally stopped, the maintenance service should supervise the operation according to its own progress criteria. A blanket “disable watchdog during updates” flag that can remain set after a crash creates an unattended failure mode.

The reboot path must tolerate interrupted writes. Embedded storage recovery and watchdog behavior belong in the same test plan, because a successful reset is not useful if the next boot cannot recover its data.

Define repeated-reset behavior too. After a bounded number of failed starts, a device may enter a documented recovery mode instead of rebooting forever. Decide what diagnostics it preserves and what outputs it holds. The correct policy depends on the installation, but it should not emerge accidentally from a boot script.

6. Prove Coverage with Controlled Fault Injection

Perform disruptive tests only on designated laboratory units, disconnected from hazardous loads, with recoverable data and a known recovery path. Verify the setup before deliberately withholding watchdog servicing.

Stopping a userspace process does not prove coverage of every kernel lockup. Kernel-fault testing needs a separate, controlled method appropriate to the BSP and laboratory. Likewise, an external timer expiring once does not prove that all peripherals recover.

Record the reset cause where hardware and firmware support it, plus the last known health state. Preserve diagnostics at a sensible rate so the logging does not become an endurance problem. A pretimeout may help gather evidence on supported hardware, but cannot guarantee logging when the relevant execution path is already stuck.

Include this evidence in industrial SBC validation. The release criterion is not “watchdog enabled.” It is that specified failures lead to the specified recovery, within the allowed time, without leaving corrupted state or unsafe outputs. That is the difference between an active timer and a useful reliability mechanism.