Follow+Public Account Star, don’t miss wonderful content
Author | strongerHuang
WeChat Public Account | Embedded Column
This is an old article, someone in the technical group was discussing this issue, so I am here to share it today.
We all know the purpose of the hardware watchdog:it is used to monitor the system, prevent system crashes, and reset the system in case of a crash.
In an RTOS operating system, if there are many tasks (threads) and a high-priority task occupies CPU resources for a long time, while low-priority tasks cannot be executed for a long time, then our system has a “Bug”.
As described above, if our thread is not crashing but just not being executed for a long time. In this abnormal situation, we do not want the system to reset, we only want to execute specific code, how can we avoid this problem?
Hardware Watchdog: It uses a timer counting circuit, whose timing output is connected to the reset terminal of the circuit, and the program feeds the watchdog within a certain time frame.
Therefore, when the program is working normally, the timer should not overflow, and thus cannot produce a reset signal. If the program fails and does not feed the watchdog within the timing cycle, the watchdog timer will overflow, producing a reset signal and restarting the system.
In STM32, there are two watchdogs: Independent Watchdog and Window Watchdog. The principles and functions are similar, but the application scenarios are different.
Software Watchdog: The software watchdog works similarly to the hardware watchdog, both requiring periodic feeding (within the time overflow). However, the software feeding is achieved through a self-designed count.
Principle of Monitoring Multitasking with Hardware and Software Watchdog
1. Use a monitoring thread (itself) to monitor other multiple threads;
2. Use the hardware watchdog to monitor itself.
If I have multiple application threads in my system (as shown in the figure), I will use a monitoring thread (itself) to monitor other multiple application threads.
At the same time, to prevent the monitoring thread from malfunctioning, a hardware watchdog is used to monitor itself. This achieves dual monitoring.
Combining Software to Explain the Principles
The principles mentioned above may be abstract for some people. In this section, let’s look at the code:
Monitoring Thread (itself):
In simple terms: within the monitoring thread (itself), it is necessary to feed the hardware watchdog. The role of the software watchdog: here is to align the count, check for overflow, and I encapsulate it into a browsing function. The specific feeding of the watchdog occurs in the other monitored threads.
Now, let’s look at the code for the software watchdog feeding one of the application threads:
This is just a simple example of feeding the watchdog within a main thread. It means: once my thread starts, it needs to feed the watchdog regularly. If it does not feed the watchdog for a long time, then the monitoring thread (itself) will notice that you have not fed the watchdog.
Simple Implementation Method
By now, I believe everyone understands the principle. There are many ways to implement it, and you can add corresponding interfaces based on your actual project needs. Here are a few examples.
This is an example of implementing the most basic things, such as counters, maximum timeout values, etc.
Register interface functions:
Monitoring browsing function interface:
The above is just to teach you the method, the specific implementation can be customized according to your own habits and project requirements.
Reply in the background with『STM32』『FreeRTOS』『Embedded Software Design and Development』 to read more related articles.
Welcome to follow my public account, reply “Join Group” to join the technical group according to the rules, reply “1024” to see more content.
Welcome to follow my video account:
Click “Read the Original” to see more shares, and feel free to share, bookmark, like, and view.
