When you work from home there are some perks of the job. You can make your own meals, slot in some laundry over lunch, and drink all the tea you want. I use a stove-top kettle to boil water for my tea, so when I get in the writing zone, I rely on its high pitched whistle to tell me when it’s done.
Except sometimes when I’m careless, I don’t fit the lid on properly. As a result, the kettle remains silent despite the fact that the liquid water inside of it is rapidly becoming a gas. My careless behavior in this scenario only means that I’ll be drinking less tea, in embedded systems, the consequences are much higher if you don’t know how to operate a Watchdog Timer (WDT). When your WDT fails to operate, a stalled microcontroller will remain stalled and cause your embedded system remains down. Let’s look at how you can get them to function correctly on the first try so that you can avoid this scenario.
Why Embedded Systems Failed To Recover Despite Having A WDT
The WDT is a simple fail-safe feature in electronics that helps to reboot a microcontroller in the event of a hardware or software crash. The WDT is available as a separate integrated circuit (IC) or as a built-in feature within the microcontroller itself. Not using a WDT In embedded systems design is often an unpardonable sin.
The way a WDT operates is simple. It is programmed to countdown over a set time interval. Under normal operation, the microcontroller periodically refreshes the countdown timer of the WDT to prevent it from expiring. If the microcontroller is unresponsive then it will not refresh the WDT. As a result, the when WDT expires, it will trigger a pulse or signal to reset the microcontroller. This simple feature compensates for design errors or environmental factors that may cause a microcontroller to crash.
Yet, if your WDT fails, then it is unlikely that your embedded system will recover from its erroneous state. This is why it is important to pinpoint the cause of why a WDT might fail to reset the microcontroller. The most obvious answer is that the WDT is faulty. However, if you repeatedly have embedded systems in multiple units failing to recover, then there could be something up with your designs.
Actually, in my many years of designing and deploying hundreds of microcontroller-based devices, I’ve never encountered a single case of a failed WDT. The root cause is often simply human error.
What you see when a WDT Fails to revive a stalled microcontroller
Why a WDT Might Not Operate Properly
For embedded systems using an internal WDT, runaways code can deactivate the WDT if the configuration bits are unintentionally overwritten. External WDTs suffer from entirely different problems. In this case, it is common to have a jumper pin that can disconnect the reset signal from the external WDT when firmware engineers are developing and debugging a program. Often these jumper pins need to be manually connected before the units are deployed on site. If they’re not, then the WDT reset signals will remain disconnected fail to reset the microcontroller.
A more common reason why WDTs fail to function is because of coding errors. If the functions that refresh the WDT timers are placed in the wrong part of the program, they won’t operate when they’re supposed to. Firmware for microcontrollers gets complicated when there are multiple tasks with different priorities in a Real Time Operating System (RTOS). Higher priority tasks may continue to execute even when lower priority tasks are in an abnormal infinite loop. If refreshing the WDT timer the highest priority task, then the microcontroller will not be refreshed when it is not functioning correctly.
It is good practice to ensure that WDTs are refreshed correctly
How To Ensure The WDT Is Functioning Reliably
Ensuring that the WDT does its job involves the firmware developer, system installer, and the hardware designer. Firmware developers should apply the best practices in programming to avoid code overruns that switch off internal WDT. Firmware developers must have a good understanding of the memory architecture of the microcontroller and how to correctly use memory pointers and allocation in the code.
Besides that, the structure of the program should be drafted out so that the WDT is refreshed at appropriate locations in the program. This means that the program will trigger a reset if an infinite loop develops at any point in the program. You can also develop a test utility to check the functionality of the WDT on-site. This also eliminates the risk of missing any disconnected jumper pins between an external WDT and the microcontroller.
Last but not least, proper PCB design is required to ensure that the WDT behaves reliably. When designing with external WDT, you’ll want to ensure the refresh signal is kept away from other high-speed signals. This is to prevent cross-coupled electrical interference from refreshing the WDT. You can set up precise clearance rule using PCB design software like Altium’s CircuitStudio to ensure the signal integrity of the WDT.
Having doubts about your WDT design? Talk to an expert at Altium.