Multi-task watchdog design for uC/OS-II system

In embedded systems, a common method to improve the reliability and security of microcomputer systems is to use a "watchdog". Watchdogs are divided into hardware watchdogs and software watchdogs. Hardware watchdogs use a "watchdog" circuit to constrain the running time of microcomputer tasks, i.e., "feeding the dog", through a timer. The task must be completed within the maximum specified time range, otherwise the system will be restarted. Software watchdogs use the processor's internal timer and use the theoretical maximum running time of the task as a time constraint. If the task exceeds this time span, the task is forced to exit. The above watchdog uses a single-task sequential mechanism and is easy to implement. In a multi-task system, the situation is slightly more complicated. If each task is like a single-task system, as long as one task works normally and "feeds the dog" regularly, the watchdog timer will not overflow. Only when all tasks have problems will the timer overflow. Professor Ye Bangli of Chongqing Normal University has discussed and solved this problem in Windows systems [1]. Some people have also talked about it in embedded systems [2], but there is no description of the specific implementation method.

In this paper, the uC/OS-II operating system is transplanted to the LPC2132 kernel produced by PHILIPS. Based on the system's message mechanism and priority permissions, a task with the highest priority is set as a monitor to monitor all tasks running on the microcomputer. As long as a task fails, the monitoring task will delay feeding the dog, causing the timer to overflow and restart the system to ensure that the microcomputer and all tasks are in a long-term stable operating state.

1 System Overview

1.1 Introduction to hardware and development environment

The uC/OS-II operating system was ported to the LPC2132 development board. LPC2132 is a 32-bit ARM7TDMI-STM core microprocessor that supports real-time simulation and tracing, with 64kB high-speed FLASH memory, 4 communication interfaces, 2 32-bit timers, 1 10-bit 8-channel ADC, 2 hardware interfaces, 47 GPIOs and up to 9 edge or level-triggered external interrupts, which can fully meet the needs of general applications and expansion.

uC/OS-II is a preemptive multi-tasking real-time operating system. Its source code is open and highly portable. It is easy to use, easy to develop and popular. uC/OS-Ⅱ can manage up to 64 tasks, which are usually functions of an infinite loop. In the current version, tasks with priorities of 0, 1, 2, 3, OS_LOWEST_PRIO-3, OS_LOWEST_PRIO-2, OS_LOWEST_PRIO-1, and OS_LOWEST_PRIO are reserved, so users can have 5 to 6 tasks at the same time, which is enough to meet the various requirements of user design.

1.2 Functions implemented by the system

In a multi-task system, it is often hoped that when a task has a problem, the task will be restarted instead of the entire system, so as not to affect the operation of other critical tasks. When multiple restarts of the task are ineffective, the system will be restarted. The system will be restarted when an error occurs in the main program of the system or a problem occurs in the system hardware. The watchdog designed based on the above analysis mainly realizes the following functions.

(1) When a task fails, the software watchdog restarts the task.

(2) When multiple attempts to restart a task fail, restart the system.

(3) When an abnormality occurs in the operating system itself or in the system hardware, the microprocessor is restarted by the software watchdog or the hardware watchdog.

2 Multi-task watchdog monitoring principle

Combining the built-in hardware watchdog of LPC2132 and the uC/OS-Ⅱ operating system, a task with the highest priority is set as a monitor to monitor whether each application task is running normally. This monitor is called a software watchdog. This task sets a timer for each monitored task. The monitored task clears the corresponding timer regularly within the set time, which is called "feeding the soft dog". When the monitored tasks are all working normally, the software watchdog periodically clears the built-in hardware watchdog timer, which is called "feeding the dog". If a task in the monitored task group fails, the software watchdog cannot be "fed" within the set time, and the corresponding timer overflows. The system kernel sends an instruction to point the stack address of the task to its starting address and reset the task. If the task cannot be effectively started within the set number of times, the "feeding the dog" is delayed, the hardware watchdog counter overflows, and the system is restarted. In addition, when the monitor task itself fails, the hardware watchdog timer cannot be cleared in time to restart the system.

3 Software Implementation

3.1 Communication between application tasks and software watchdog

When information is transmitted between the multi-task software watchdog and each application task, each application task will send a running status message to the monitor, and the monitor task will also send a message to each task. In the case of a large number of application tasks, if mailboxes are used for communication, a large number of invalid operations will be caused, and programming will become cumbersome. Therefore, a message queue is used in the monitor task to realize message transmission with each application task, and two mailboxes are set in each application task, one for sending messages to the monitor message queue and the other for receiving messages sent by the monitor task message queue. When an application task fails in execution, the OSQPost() function is called to send a message to the monitor task message queue. The monitor task reads the message from the message queue by calling the OSQPend() function, and then calls the OSMboxPost() function to send messages representing different meanings to the message receiving mailbox of the application task. The task calls the OSMboxPend() function to read the message from the mailbox and then performs the corresponding operation.

3.2 Implementation of multi-task software watchdog

The multi-task watchdog monitors the running status of each task by checking whether each application task "feeds the soft dog" within the specified time. With the help of the timer interrupt mechanism of the microprocessor, a timing unit and a running flag are assigned to each task, and the timing interrupt performs independent timing according to the running flag status. When a task in the system is idle, it is periodically "fed" with a time interval less than the "feed the soft dog" setting as a period; when the task is executed, the longest execution time required is estimated, and the timer parameters in the monitor are set with a time interval slightly greater than the maximum time, and the periodic "feed the soft dog" module is interrupted at the same time, and the timer countdown in the monitor task is started. When the task is executed normally, the signal "feed the watchdog" is sent to clear the timer, reset the task, and restore the periodic "feed the watchdog" module; when the task execution is abnormal, the software watchdog cannot be cleared within the set time interval, causing the corresponding timer in the monitor to overflow. The monitor task sends instructions through the kernel service to point the stack address of the task to its starting address, restart the task, and accumulate the number of resets to clear the timer of the task.

4 Conclusion

Combining the built-in hardware watchdog of LPC2132 and the uC/OS-Ⅱ operating system, a software watchdog capable of multi-task management is designed. The watchdog can not only effectively monitor each application task, but also restart the task without affecting the normal operation of other tasks. The system will not be restarted until multiple restarts are invalid, thus achieving the goal of not overly restraining independent application tasks. In addition, the watchdog can also automatically restart when the main program and hardware have problems, ensuring long-term stable operation of the system.