Most internal watchdog timers found on microcontrollers contain mechanisms to prevent an inadvertent feed, usually requiring the write of a specific key-value to the feed register, although some watchdog timers may require a more specific sequence (of multiple key-values written in order to the same address, or writes to multiple addresses).

However, not all applications can use an internal watchdog, for reasons that are detailed well here, and thus use an external watchdog instead. However, these external watchdog timers are fed by toggling a single pin on the IC. Simply hooking this up to a port pin is a solution I perceive as mishap-prone, where a write to other pins on the GPIO port could inadvertently feed the watchdog. While a windowed-watchdog provides some defense against premature feeding, relying on it as a sole defense against such is unwise from a defense-in-depth standpoint.

What strategies can be used to prevent inadvertent feeding of an external WDT, given that currently available external watchdog ICs use a single pin for their feed input, instead of a serial or parallel bus input? Hardware strategies are preferable, although software defenses against inadvertent feeds can be useful in a defense-in-depth strategy as well.

  • \$\begingroup\$ I believe I've seen one that requires petting via pulses that are within some acceptable window of high-time and period. Too frequent, too short or too long and the WDT would ignore or reset. \$\endgroup\$ Commented Nov 23, 2018 at 17:19
  • \$\begingroup\$ @pericynthion -- as in the WDT requires a pulse of specific shape as its food to begin with, with any windowing in the watchdog's timeout being atop that pulse-feed feature? \$\endgroup\$ Commented Nov 23, 2018 at 17:22
  • \$\begingroup\$ You could use a microcontroller with custom firmware to serve the purpose... \$\endgroup\$
    – vicatcu
    Commented Nov 23, 2018 at 18:27
  • \$\begingroup\$ @vicatcu -- that's an awful lot of complexity for what's supposed to be a protective function \$\endgroup\$ Commented Nov 23, 2018 at 18:35

1 Answer 1


One way to improve the robustness and reliability of the Watchdog triggering process is to leave the triggering GPIO pin in a HiZ state (configured as an input) by default. When you wish to "pet the dog", briefly configure the pin as an output, drive the pulse, then return the pin to the HiZ state.

Think about this in terms of probabilities. While the probability of runaway code attempting to pulse the GPIO driver is pretty low, the probability of runaway code first configuring the trigger as an output and then pulsing it is vanishingly small.

Don't forget to use a pullup or pulldown to hold the trigger pin at the benign/inactive trigger voltge level when the GPIO is HiZ!


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.