In order to enhance the reliability and security of a microcomputer system within an embedded environment, a commonly used technique is the implementation of a "watchdog." A watchdog can be categorized into two types: hardware and software. The hardware watchdog utilizes a dedicated "watchdog" circuit, which employs a timer to regulate the execution time of the microcontroller's tasks. This mechanism ensures that each task completes its operation within a predefined maximum time frame; otherwise, the system will automatically restart. On the other hand, a software watchdog uses the internal timer of the processor to impose a time limit on the task's execution. If the task exceeds this time limit, it is forcibly terminated.
These traditional watchdog mechanisms are based on a single-task sequential approach, making them relatively straightforward to implement. However, in a multitasking system, the situation becomes more complex. If each task operates independently and regularly "feeds the dog," the watchdog timer will not trigger. Only when all tasks fail will the timer overflow. Research by Mr. Ye Bangli from Chongqing Normal University addressed this issue in the Windows environment [1], while others have explored similar concepts in embedded systems [2], though without detailed implementation methods.
This paper describes the porting of the uC/OS-II operating system to the LPC2132 microcontroller from PHILIPS. Based on the system’s message mechanism and priority management, a high-priority task is designated as a monitor to oversee all running tasks. As long as one task fails, the monitoring task delays feeding the watchdog, causing the timer to overflow and triggering a system reset. This ensures that the microcomputer and all tasks remain in a stable state over extended periods.
### 1 System Overview
#### 1.1 Introduction to Hardware and Development Environment
The uC/OS-II operating system was successfully ported to the LPC2132 development board. The LPC2132 is a 32-bit ARM7TDMI-S microprocessor that supports real-time emulation and tracking. It features 64KB of high-speed FLASH memory, four communication interfaces, two 32-bit timers, one 10-bit 8-channel ADC, and two hardware interfaces. With 47 GPIOs and up to nine edge or level-triggered external interrupts, it provides sufficient flexibility for general applications and expansion.
uC/OS-II is a preemptive, multi-tasking real-time operating system with open-source code and high portability. It is easy to use, develop, and widely adopted. It can manage up to 64 tasks, typically implemented as infinite loops. In the current version, the priority levels 0, 1, 2, 3, OS_LOWEST_PRIO-3, OS_LOWEST_PRIO-2, OS_LOWEST_PRIO-1, and OS_LOWEST_PRIO are reserved, allowing users to run up to 56 tasks simultaneously, which meets most design requirements.
#### 1.2 System Implemented Functions
In a multitasking system, it is often desirable to restart only the problematic task rather than the entire system, to avoid disrupting other critical processes. However, if a task fails multiple times, the system should be restarted. Additionally, if the operating system itself or the hardware encounters an error, the watchdog should trigger a system reset. Based on this analysis, the watchdog primarily implements the following functions:
1. When a task encounters an exception, the software watchdog restarts the task.
2. If a specific task fails to restart multiple times, the system is rebooted.
3. If the operating system or hardware malfunctions, either the software or hardware watchdog initiates a system restart.
### 2 Multi-task Watchdog Monitoring Principle
By combining the built-in hardware watchdog of the LPC2132 with the uC/OS-II operating system, a high-priority task is assigned as a monitor to ensure the proper functioning of all application tasks. This task is referred to as the software watchdog. It sets a timer for each monitored task, and the task must clear the corresponding timer within the set time—known as “feeding the soft dog.†When the monitored tasks are running normally, the software watchdog periodically resets the built-in hardware watchdog, also known as “feeding the dog.â€
If a monitored task fails, the software watchdog cannot clear the timer within the specified time, leading to an overflow. The system kernel then directs the task’s stack address to its starting point, restarting the task. If the task continues to fail after a set number of attempts, the watchdog timer overflows, and the system is restarted. Additionally, if the monitor task itself fails, the hardware watchdog will not be cleared in time, resulting in a system reboot.
### 3 Software Implementation
#### 3.1 Communication Between Application Tasks and Software Watchdogs
When multiple tasks communicate with the software watchdog, each application task sends its status to the monitor. The monitor also sends messages back to the tasks. Using mailboxes for communication may lead to inefficiencies and increased complexity, especially when there are many tasks. To address this, message queues are used in the monitor task to facilitate efficient communication with each application task.
Each application task has two mailboxes: one for sending status messages to the monitor and another for receiving commands from the monitor. When an error occurs, the task uses the OSQPost() function to send a message to the monitor. The monitor reads the message using OSQPend(), then sends a response via OSMboxPost() to the task’s mailbox. The task reads the message using OSMboxPend() and performs the appropriate action.
#### 3.2 Implementation of the Multitasking Software Watchdog
The multitasking watchdog monitors each task by checking whether it “feeds the soft dog†within a defined time window. Using the microcontroller’s timer interrupt mechanism, each task is assigned a timing unit and a run flag. The timer interrupt is triggered based on the task’s status. When a task is idle, it periodically feeds the dog at intervals shorter than the set time. When the task is active, it is expected to take the longest possible time, so the monitor’s timer is set slightly longer than the maximum expected interval.
During normal execution, the task sends a signal to feed the dog, resetting the timer. If the task fails, the watchdog timer overflows, and the monitor task issues a command to reset the task’s stack pointer to its starting address, effectively restarting it. If the task fails repeatedly, the watchdog triggers a full system restart.
Flat Wire Common Mode Inductors
Flat Wire Common Mode Inductors,Vertical Low Profile Common Mode Inductors,Horizontal Flat Wire High Current Inductor,Flat Copper Wire Common Mode Inductors
Shenzhen Sichuangge Magneto-electric Co. , Ltd , https://www.scginductor.com