An embedded device running for months depends on more than the main loop working correctly under normal conditions. A communication deadlock, brief supply dip or corrupt record can put software into an unexpected state. Watchdog and brown-out mechanisms help recovery, but an ill-considered reset can conceal a fault or change outputs unintentionally.
01Which failure should the watchdog monitor?
A watchdog generates a defined response if it is not refreshed within a specified period. A fundamental mistake is feeding it continuously from a timer interrupt without checking whether the main tasks are actually progressing. If the interrupt continues running, the device may still appear healthy even when a communication task is deadlocked.
A more meaningful approach monitors the progress of critical tasks. Measurement, logging and communication tasks update their own health indicators, and a supervisor checks that they advance within the expected time window. As task periods differ, one arbitrary timeout should not be applied to the entire system.
02Interrupt, task and hardware supervision differ
In ESP-IDF, for example, interrupt and task watchdogs target different problems. Interrupts being blocked for too long and a task looping without yielding the processor are different failures. Verify the behaviour of the selected microcontroller and software version in manufacturer documentation; defaults from one platform do not transfer automatically to another.
Watchdog behaviour may change while a debugger is connected. Breakpoint-based bench testing alone is therefore insufficient. Verify production-like builds and actual timing without a debugger as well. A test that passes with the watchdog disabled does not validate the recovery design.
03Brown-out is not a software hang
Correct code execution cannot be assumed when supply voltage falls below the processor's reliable operating range. Brown-out detection triggers a reset or another safe response at a suitable threshold. Select that threshold by considering the processor, external memory and connected peripherals together.
Investigate why the supply dipped: possible causes include an undersized regulator, transient radio current, long connections, poor decoupling or an external load. Disabling brown-out detection does not solve a power problem; it may only change its symptoms. Include supply supervision and power sequencing in the hardware design where necessary.
04What happens to outputs after a reset?
A processor restarting does not automatically guarantee that connected relays or drives enter a safe state. Consider reset-time pin states, external pull resistors, output drivers and actuator behaviour after loss of power together. Functions requiring safety must not depend on an ordinary software reset.
| Event | Question to answer in the design |
|---|---|
| Task deadlock | Is the task that stopped progressing recorded? |
| Supply dip | Does the reset threshold suit every important component? |
| Repeated resets | Is there a controlled mode instead of endless restarting? |
| Incomplete record write | Can the previous valid configuration be restored? |
| Connection unavailable | Can measurement and local functions continue? |
05Address data integrity independently of resets
A power interruption can leave a flash or file write incomplete. Configuration can be verified using version numbers, length, integrity checks and a previous valid copy. CRC helps detect accidental corruption; it does not provide authentication or protection against attack.
In an example configuration update, prepare and verify the new contents before marking the valid version. If interrupted, the device must not choose production parameters based on arbitrary assumptions. If defaults are restored, define how the operator is notified and which outputs are restricted.
06Verify through fault injection
Planned testing can delay a communication response, deliberately halt a task or introduce a controlled undervoltage condition. Observe the expected reset cause, startup time, record integrity and output behaviour. Perform these tests in a suitable laboratory setup, not through uncontrolled power experiments on an operating machine.
Recording the reset cause and last healthy execution step makes subsequent diagnosis easier. Logging itself must not deadlock the system or cause unnecessary memory wear, however. A good recovery architecture does more than restart the device: it helps explain why it stopped and return it safely to service.
07Example verification scenario
Suppose a communication task waits indefinitely for a response. During testing, observe whether the measurement task continues, how quickly health monitoring detects the fault and whether the reset cause is recorded. Then inject the same fault repeatedly. The device should exhibit defined, controlled behaviour rather than enter an endless reset loop. Compare configuration and output states at each startup to verify that recovery does not cause data loss or unintended movement.
Technical references and further reading
For product- and version-specific values, the relevant manufacturer's current documentation should be taken as the reference. The calculations and scenarios above are engineering examples for illustrative purposes.
