IO4: Reliable firmware: interrupts, RTOS tasks, watchdogs and safe state
Watchdogs and recovering by yourself
🎯You'll be able to
Use a watchdog timer so a hung device restarts by itself, and design firmware that recovers cleanly after a reset.
🏠The everyday picture
A night guard must press a button every hour. If they don't, an alarm calls the manager, who checks on them. The button proves someone is still awake and working.
📘What it really is
-
A watchdog is a hardware timer that restarts the chip unless the firmware "feeds" it regularly. If the firmware hangs, it stops feeding, and the watchdog resets the chip.
-
Feed it in the right place: only where the firmware is genuinely making progress, not in a timer interrupt that keeps running while the main work is stuck.
-
Know why you restarted: read the reset cause (
power_on,deepsleep,watchdog) at start-up and count unexpected resets. - Recover cleanly: after a watchdog reset, load saved state, check it's valid, and carry on. Report the reset in the next status.
- Don't hide crashes: catching every exception and carrying on can leave the device in a bad state. Handle expected errors; let unexpected ones reset the device and be reported.
📝A worked example
Input: the kit's harness treats a crash as a watchdog reset: RTC memory is kept, the firmware starts again.
Steps:
- Make a sensor fault a handled error (
SensorError), so the wake still completes and sleeps. - Let truly unexpected errors reset the device; on the next wake,
reset_cause()iswatchdog. - Count watchdog resets in the state and report them in the status message.
Expected output: a device that keeps working with a dead sensor and tells the server something is wrong.
🌍Where it's used
- Every unattended device should have one.
- Routers and modems restart themselves after hangs.
- Cars use watchdogs on safety-related controllers.
📝Case scenario
A device fed its watchdog from a timer interrupt. When the main loop hung waiting for a modem, the timer kept feeding, and the device stayed frozen for days. Feeding only after each completed step let the watchdog do its job.
🖱️Try it
In the starter, find where an I2C error would crash a wake. Write what should happen instead, and what should be reported. Success: a handled error, a completed wake, and a counter in the state.
⚠️Common mistakes
- Feeding the watchdog from a timer. Sign: hung devices that never reset. Fix: feed after real progress.
- Catching everything. Sign: a device running in a broken state. Fix: handle expected errors only.
- Not recording resets. Sign: nobody knows devices are restarting. Fix: count and report them.
🛠️For your project
Project 1's test 3 checks that a dead sensor doesn't crash the device; every wake still ends in deep sleep.
✅Quick check
What does a watchdog timer do?
Show the answer
It restarts the chip if the firmware stops feeding it, which happens when the firmware hangs.
Why shouldn't a timer interrupt feed the watchdog?
Show the answer
It can keep feeding while the main work is stuck.