Budgeting the Service Window of an External Watchdog

A window watchdog can reject a service event that arrives too early as well as one that arrives too late. A periodic GPIO toggle therefore needs a timing budget and a meaningful connection to software progress. Review the hardware window and firmware execution conditions together before deciding that a stable blink proves correct supervision.

Define the allowed service interval

The Texas Instruments TPS3430-Q1 data sheet defines lower and upper watchdog window boundaries and the triggering input edge. Its configuration and timing tolerances determine the usable interval. Another watchdog may use a different edge, startup interval, or disable behavior.

Record the complete device variant, timing components, configuration pins, reset output behavior, and relevant minimum and maximum timing limits. Compare the latest possible lower boundary with the earliest possible upper boundary when establishing a service interval that works across tolerances.

Budget software variation

• Measure the shortest and longest normal interval between valid service events.
• Include interrupt latency, scheduling, communication, and storage operations.
• Check clock accuracy and changes between operating modes.
• Define startup, firmware update, debug, and low-power behavior.
• Verify that the service mechanism depends on the required software progress.

For example, a timer interrupt that continues toggling the watchdog input while the main application is stuck may satisfy the hardware window without demonstrating healthy application behavior. The system’s diagnostic objective should determine what permits a service event.

Exercise early, late, and recovery cases

Capture the watchdog input and output with the processor’s relevant reset signal. Deliberately test missing and incorrectly timed service events using a controlled development configuration. Confirm the resulting reset duration and the product’s recovery behavior, including repeated fault conditions.

Startup deserves its own capture. The first service event may have different rules from later events, and firmware initialization can take longer than normal operation. Use the actual device’s startup behavior rather than adding an unexplained delay until one prototype stops resetting.

Keep test conditions and timing distributions with the firmware and hardware revisions. A change to clock rate, scheduler, bootloader, or timing capacitor can alter the margin even when the watchdog circuit looks unchanged.

Release an explicit service window with a tested fault response and a justified software service policy. The result should demonstrate that expected execution remains within the window and relevant failures lead to the intended recovery, without claiming that a watchdog alone establishes the reliability or safety of the entire product.

Keep the reset-cause record available after recovery so a watchdog event can be distinguished from an unrelated supply reset.