A prototype that works beside its developer can still be awkward to test anywhere else. If it stops responding, someone has to notice, find the power connection and restart it. A watchdog can help with a stalled program, but the useful product question is what the device does after the restart: does it reconnect, show a truthful status and return to a sensible state?
On our bench we isolated the reset mechanism first, on a WIZnet Ethernet board running MicroPython. The test fed a four-second hardware watchdog repeatedly, then deliberately stopped feeding it and recorded the reset. That is a compact foundation for planning unattended recovery. It is not a test of a complete connected product.
Understand what the timer is waiting for
A hardware watchdog expects the application to report progress before a deadline. In MicroPython that report is a call to feed(). If the deadline passes, the watchdog resets the system. The countdown starts when the watchdog is created and restarts on every feed, so a timeout is measured from the last feed. The MicroPython WDT documentation recommends feeding only after checking that the application is working correctly.
That last condition matters. A background routine that feeds forever can keep a stalled application alive. For a connected prototype, decide what "working" means locally: the main loop is progressing, important tasks are completing and failures are being handled. An unreachable remote server does not mean the local processor has frozen, and it should not trigger a reset on its own.
Reproduce the deliberate timeout before adding recovery logic
Our test waited three seconds at startup, created the watchdog with a 4000 ms timeout, then fed it after each three-second pause for ten iterations. After that it stopped feeding and the watchdog expired.
from machine import WDT
import time
time.sleep(3)
wdt = WDT(timeout=4000)
for i in range(10):
print("Feed iteration:", i)
time.sleep(3)
wdt.feed()
print("Feeding stopped; waiting for watchdog reset")
while True:
time.sleep(1)
The three-second startup delay is not decoration. This program resets the board on purpose, so keep a reliable way to interrupt it or replace the startup file during development; once a watchdog program runs at boot, a short window before the watchdog starts is what lets you get back in. The four-second timeout suits this demonstration, not every application. Our first version of the loop also printed the counter as "seconds," which it is not: it counts feed iterations, each about three seconds apart.
The terminal showed the expected stages: the ten feed iterations, the message that feeding had stopped, the MicroPython restart banner, and then a serial error on the host as the USB connection dropped during the reset. Those observations fit a watchdog reset. A disconnected development terminal is not evidence that the application resumed its intended task.
Make recovery an observable product behavior
Once the reset itself is understood, add the device's real startup behavior back into the picture. Which settings are available at boot? What does the display show while a network connection is pending? If an output controls a physical load, what state should that output take before initialization completes?
These questions are the integration work after the reset test. They should produce explicit behavior, not just a longer watchdog timeout. A restart that silently restores an old "connected" indication leaves the user with the same misleading experience as a freeze.
Software timers and watchdogs implemented in a second thread are different tools. They do not offer the same independence from stalled application code as the hardware mechanism, and should not be assumed equivalent.
Test a failure you can name
For a follow-up trial, first create a controlled program stall and confirm that the board resets. Separately, disconnect the network and check whether the application stays responsive, reports the loss and retries sensibly. Then restore the network and look at the result. We have not run these follow-up tests; our captures cover the deliberate timeout only.
An older MicroPython forum discussion about Ethernet adapters includes a builder considering a watchdog for a sensor device that posts data. It shows the practical link between networked prototypes and recovery planning, though it offers no reliability figures for this board or firmware.
Before making several test units, define what the next person should see during failure and recovery, and record the firmware version you used. That turns a later report such as "the display froze after unplugging the cable" into something an engineering team can reproduce and investigate. A clear startup sequence and one reproducible failure are more useful inputs than a request to "add a watchdog" without saying what it should protect.