Emre Ceylan
What is a watchdog timer? In short, it is a safety timer that automatically resets a microcontroller or system when software fails to send an “I’m alive” signal within the expected window. On industrial embedded boards it lets a device recover by itself after an infinite loop, memory corruption or a communication lock-up in the field.
In Revan Technology embedded projects, the watchdog is not optional polish; it is a core part of reliability design.
What is a watchdog timer?
A watchdog timer (WDT) is a timer that generates a hardware or software reset if it is not refreshed (kicked) by software within a set period. The goal is to return the device to a known start state when control is lost.
It can be internal (inside the MCU) or external (a dedicated WDT IC). In critical applications an external watchdog is preferred because it can still assert reset even if the MCU core itself is locked.
Why does it matter?
- It lets a locked field device recover without on-site or remote intervention.
- It prevents software faults from leaving the product permanently “dead”.
- It shortens downtime in automation, IoT and industrial panels that need continuity.
- It adds a traceable safety layer in CE and functional-safety discussions.
How does it work?
1. At startup the watchdog is enabled and the timeout is configured.
2. The main loop or critical tasks refresh the watchdog before the timeout expires.
3. If no refresh arrives, the watchdog asserts reset and the device reboots.
4. After boot, the reset cause (power-on, pin, watchdog) is read and logged.
With a window watchdog, refreshing too late or too early both count as faults; that also catches “fake alive” loops.
Typical use cases
- Industrial control boards and PLC-like embedded units
- Wireless IoT nodes such as GSM / LoRa
- Machines with motor drives and safety interlocks
- Field panels that run for long periods without maintenance
- Recovery scenarios after OTA updates
Common mistakes
- Refreshing the watchdog only in the idle loop so a stuck critical task never triggers reset.
- Setting the timeout too long so faults run for minutes unnoticed.
- Not logging the reset cause, which makes field analysis impossible.
- Bypassing an external WDT with a wrong supply or disable-pin wiring.
- Disabling the WDT for debug and forgetting to enable it in production.
Selection / design checklist
- Is an internal or external WDT required?
- Does the timeout match the longest busy job plus margin?
- Do refresh points cover critical task paths?
- Is a window watchdog needed?
- Is the reset-cause register read and stored?
- Is WDT policy defined for OTA and bootloader stages?
FAQ
What is a watchdog timer in one sentence?
It is a safety timer that automatically resets the system if software does not report in within a set time.
Is an internal watchdog enough?
Often yes; but if the MCU core or clock source fails, an external WDT provides a more reliable layer.
How often should I refresh the watchdog?
Often enough to beat the timeout, but with a period longer than the longest blocked job; constant kicking can hide real lock-ups.
What should I do after a reset?
Read the reset cause, increment a counter, and enter a safe mode if needed instead of blindly repeating the same fault path.
Conclusion
A watchdog timer is a quiet but critical assurance layer in embedded systems. With the right timeout, refresh points and post-reset monitoring, the risk of field lock-up drops significantly. If reliability is a goal for industrial boards, placing the watchdog at the start of the design reduces costly later field interventions.
🔗 Get in touch with us:
Phone/WhatsApp: +41 76 212 8248
📧 E-Mail: info@revantechnology.ch
For detailed information about our services in electronics development & PCB design:
Revan Technology – Your partner for professional electronics and PCB development
