[Introduction] Writing so many microcontroller programs, you see the watchdog every day, are you raising your dog correctly? Just keep feeding the dog as long as it doesn’t bark, right? Is it really that simple? In fact, it may not be as simple as you think…..

What Is a Watchdog?

A watchdog, also known as a watchdog timer, is essentially a timing circuit or software timer mechanism.

Working Principle:

The hardware basis of the watchdog is a counter that is set to a certain initial timing value and then decrements to zero. The software is responsible for frequently resetting the counter to its initial timing value to ensure that the count never reaches zero. If it does reach zero, it indicates that some failure has occurred, and corresponding measures should be taken to respond, either by rebooting or entering a fail-safe state, depending on the system design.

During normal operation, the microcontroller, processor, or thread periodically resets the watchdog timer’s timing value, while the timer continuously counts in the background. If the timing period expires without feeding the dog again, the dog barks, indicating that something unusual has happened! At this point, the dog sends out instructions externally to perform corresponding actions. What exactly these actions are depends on the actual system design. Common watchdog chips will send a reset signal to the microcontroller or processor, while for software timers, the specific actions can vary flexibly, depending on the safety strategy adopted.

In simple terms, this is also called feeding the dog; the timing value is equivalent to dog food. The dog consumes the food in its stomach, and if it doesn’t get fed before consuming it all, it will bark for food. Conversely, a system that is always functioning normally has its watchdog well-fed and won’t bark out of hunger.

Note: I’ve seen articles refer to resetting the watchdog timer as “kicking the dog.” This is not very nice; we should treat the dog better, so let’s call it feeding instead~~

The watchdog mechanism plays a crucial role in electronic systems. For example, if the Mars rover’s program hangs, it would be equivalent to losing contact without a watchdog circuit. Imagine the scene: no communication, no wake-up, and it quickly becomes space junk~~

What Errors Can It Monitor?

• Stack or heap overflow, causing the program to crash
• A certain segment of the program cannot return or enters an infinite loop
• Strong electromagnetic interference damaging data, leading to system anomalies. This might be hard to understand, but think of many electronic systems in military or aerospace fields that often operate in environments with strong electromagnetic interference.
• System crashes caused by bugs
• Deadlock in multitasking systems
• ……

There are countless reasons, but don’t panic! You have a good dog helping you; let the watchdog clean up the mess. In a complex embedded system, it’s impossible to guarantee there are no bugs, but by using a watchdog, you can ensure that no bug will hang the system indefinitely.

What to Do After the Dog Barks?

What are the common handling strategies?

• System Reset: Most people have experienced this; when the system hangs, what to do? Restart. It reminds me of Liu Huan’s “Starting Over”; how nice would it be if life could be restarted, but it can’t! If you’re interested, give it a listen~~
• Fail-Safe: Often referred to as fail-safe mode by foreigners. This means that even if the device experiences a fatal failure, it should not cause a safety incident. To put it bluntly, even if it crashes, it shouldn’t affect others. This might be hard to understand; for example, if an elevator is descending and the watchdog detects a program anomaly, the safe action is to stop the motor immediately; otherwise, it could fall freely and end badly. This is reflected in standards like IEC61508 for functional safety, as well as in medical and automotive safety standards.
• Here’s a recommended practice: After the chip resets, use the chip’s reset status register value to count watchdog reset events. If this happens three times consecutively, a conservative approach is to switch the system to a safe state or display an error message to avoid infinite restarts. How to do this? For example, in IAR, you can define a variable to prevent the system from automatically initializing (called __no_init in IAR) to implement counting; after a reset, its value remains preserved unless power is lost.
  __no_init int wdtResetCounter;
• …. depends on specific design strategies

If we want the system to recover quickly, we should adopt a strategy where the watchdog reset initialization is shorter than the normal power-on initialization. This means skipping some self-checks of the device. However, in some systems, it’s better to perform a full self-check, as the root cause of the watchdog timeout may be due to such hardware anomalies.

How to Feed the Dog Specifically?

For bare-metal programs, I recommend the following two feeding strategies: fault detection feeding and enhanced fault detection feeding.

Fault Detection Feeding

For a bare-metal microcontroller program, you can check some key runtime states while feeding the dog, such as stack depth, buffer, and hardware of critical function chains (like sensors, actuators, etc.). If these states are abnormal, record the error state and put the device in a functional safety state.

Enhanced Fault Detection Feeding

What is sequence detection feeding? There is a paradigm called sequence check in IEC-61508; it might sound a bit strange, but you’ll understand immediately after looking at the diagram.

It involves setting a sequence marker for the main function’s critical functional blocks. If the sequence goes wrong, safety fault handling is performed; if correct, the next block is executed. While feeding the dog, check if the sequence is correct; if correct, feed; otherwise, perform error handling or simply let the dog bark as a form of response.

For multitasking real-time systems, there are some different requirements:

• Detect whether the operating system is running correctly
• Detect if there are infinite loops in all tasks
• Detect deadlocks involving two or more tasks
• Detect if some low-priority tasks cannot run due to CPU occupation by high-priority tasks
• ….

Mother Dog with Puppies Feeding Method

This name sounds a bit tacky, haha. To make it easier to understand, let’s call it this way; let’s look at a diagram first:

Implementation Strategy Description:

The watchdogTask can be seen as the doghouse, housing a group of dogs, where the hardware watchdog is the mother dog, and the sub-task software watchdogs are the puppies. Each sub-task needs to feed the dog once in every loop cycle (of course, in actual implementation, fault detection feeding can also be included). In each loop of the watchdogTask, all software watchdogs are decremented; if overflow occurs, the soft dog barks, requiring abnormal handling (reset or enter fail-safe mode). If none of the software dogs overflow, then feed the hardware watchdog (which may be an internal or external chip of the microcontroller).

In actual implementation, attention must be paid to:

• The watchdogTask should be selected with the highest priority
• Each loop should call os_delay for a certain time to yield CPU time for other tasks to run. The suspended time should be less than the maximum hardware watchdog timeout.
• Tasks’ priorities should be arranged reasonably
• It is strictly forbidden to feed the dog privately in interrupt handlers or other functions.

How Often Should the Dog Bark?

Too Short Pain

If the watchdog timer’s timing is set too short, the system is prone to misjudgment, which may lead to frequent resets or entering fail-safe mode. The effectiveness of any safety chain depends on its weakest link; if a timeout interval is chosen too short, the firmware’s cycle time is dynamic, especially when there are many external asynchronous events or nested interrupts, resulting in significant fluctuations. Therefore, it is essential to consider the worst-case scenario of how long it takes for the system to cycle once.

Too Long Harm

One method is to choose a timeout interval of several seconds. When you only want to reset a genuinely hung system without wanting to study the system’s timing in detail, this strategy can be employed. It’s a robust method. However, some systems require quick recovery, which can lead to slow fault diagnosis, especially in highly safety-critical situations, such as nuclear power systems, automotive electronic systems, and medical devices.

Therefore, in actual design, it is necessary to consider the worst-case scenario and strive to choose a relatively short timeout duration, finding a balance between the two.

In Summary

For microcontroller programming, the watchdog strategy has extensive applications even in embedded Linux and databases. How to use the watchdog reasonably is a very important topic for designing a robust electronic system.

1.UX600 released, the Xinlai RISC-V processor starts the Linux chapter

2. The second session of the “Embedded and IoT Development Technology” lecture replay course is now online!

3.Why is Linux popular? What is the difference between it and ordinary RTOS?

4.Talking about C variables—why are static variables commonly used in embedded projects?

5.IAR enters Linux, supporting the establishment of a compilation environment in Linux~

6. After a long time, you will thank yourself for writing the exception handling code~

Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are copyright issues, please contact us, and we will confirm the copyright based on the materials you provide and pay the remuneration or delete the content.