Table of Contents
A watchdog that repeatedly resets a board without restoring operation has not completed its job. Selecting the timer therefore starts with a recovery requirement: what failure must be detected, how long detection may take, and what hardware and software must return to a known state?
For ordinary embedded and industrial designs, a useful procurement specification includes timeout behavior and the reset path. It should not stop at a part number, package, and nominal timeout.
Detection and timeout requirements
A standard watchdog typically detects the absence of an expected service event. A window watchdog also checks whether service occurs too early. Neither can infer that every critical task is correct merely because one GPIO is toggling.
Define the conditions under which software may service the watchdog. For example, the decision may depend on completion of several critical tasks, valid communication state, and the absence of a detected control fault. This is an architectural choice that should be documented by the design team.
TI’s TPS3431 information, checked on September 15, 2026, identifies it as a standard programmable watchdog with enable. That is a useful reminder to verify the exact watchdog type. Do not assign window-monitoring behavior to a standard timer based on a similar product name.
Timing margins for legitimate operations
Begin with the worst legitimate interval between service events. Include startup, firmware update, flash operations, low-power transitions, and the longest expected scheduling delay. Compare that interval with the watchdog’s minimum timeout across relevant tolerances and conditions.
For an illustrative application, suppose the longest legitimate service gap is 180 ms and the shortest watchdog timeout is 220 ms. The apparent margin is 40 ms. A later bootloader operation taking 300 ms invalidates that assumption unless the startup or enable behavior is intentionally handled.
The maximum timeout matters for failure detection. A timer with ample minimum margin can still react too slowly for the product’s permitted recovery time. Include output assertion and reset duration in the complete timing budget.
States before, during, and after reset
| State | Question to resolve | Acceptance evidence |
|---|---|---|
| Initial power-up | When does monitoring become active? | Startup waveform and first valid service event |
| Normal operation | Which application conditions permit service? | Task-health logic and timing margin |
| Sleep or update | Does the timer continue, pause, or use another mode? | Documented state transition |
| Watchdog fault | Which signal is asserted and for how long? | Output polarity, electrical levels, and pulse duration |
| Recovery | Which peripherals and rails return to known states? | Successful restart under the original fault conditions |
An open-drain output requires an appropriate pull-up and compatible voltage domain. A reset output that reaches the MCU may leave an external peripheral in a locked state. Confirm the system’s recovery dependencies rather than assuming an MCU reboot resets the entire board.
A GPIO expander’s startup state can matter if its outputs control enable pins or peripheral resets.
Fault injection and recovery evidence
A proposed verification sequence should exercise failures the design claims to detect: stop servicing, service too rapidly for a window device, stall a critical task while an unrelated timer continues, and hold an external peripheral in a nonresponsive state.
Observe the fault signal, MCU reset, peripheral reset, and the application reaching its operational state. Preserve the fault cause across reset where the architecture permits, so repetitive failures can be distinguished from ordinary startup.
Also test legitimate long operations and debug behavior. A watchdog disabled during development may never have exercised the production recovery path. Conversely, a debugger halt can trigger an intended reset unless the design explicitly handles it.
These tests demonstrate particular recovery behaviors; they do not establish a general safety certification or eliminate every software failure.
Preserve the approved behavior across sourcing changes
A proposed replacement should match more than the nominal timeout. Check the minimum and maximum timing, input recognition, power-up default, enable polarity, output type, supply range, package pins, and programming components.
For industrial electronics, retain the complete timing and state table with the approved BOM. Use the alternative-component review when any behavior differs.
The release decision should state which failures are detected, how the board recovers, and which failures remain outside coverage. That makes the watchdog a defined part of system behavior rather than an unexplained reset generator.
Frequently Asked Questions (FAQ)
Does an external watchdog replace a voltage supervisor?
Not necessarily. A watchdog monitors a defined activity signal or protocol; a supervisor monitors supply conditions. Some devices combine functions, so check the exact part rather than inferring either feature.
Can a timer interrupt safely service the watchdog?
Only if the service decision represents the required application health. An interrupt can keep toggling while the main application is stuck, so a heartbeat alone may fail to detect the condition of interest.
Is adding a watchdog sufficient for functional safety compliance?
No. A watchdog is one possible diagnostic mechanism. System-level safety claims require the applicable engineering analysis, architecture, validation, and evidence.
