In order to enhance the reliability and security of a microcomputer system within an embedded environment, a common approach is to implement a "watchdog." A watchdog can be categorized into two types: hardware and software. The hardware watchdog employs a dedicated circuit that uses a timer to constrain the execution time of the microcontroller's tasks. These tasks must complete their operations within a predefined maximum time frame; otherwise, the system will automatically restart. On the other hand, the software watchdog utilizes the internal timer of the processor to impose a theoretical upper limit on the task's running time. If a task exceeds this time limit, it is forcibly terminated. These traditional watchdog mechanisms rely on a single-task sequential structure, which is relatively straightforward to implement. However, in a multitasking environment, the situation becomes more complex. If each task behaves like a standalone system, only when all tasks fail will the watchdog trigger a reset. This issue was previously addressed by Mr. Ye Bangli from Chongqing Normal University in the Windows system [1], and some researchers have discussed similar concepts in embedded systems [2], but no concrete implementation details were provided.
This paper presents the porting of the uC/OS-II operating system onto 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 the execution of all other tasks. As long as one task is functioning properly and regularly "feeding the dog," the watchdog timer remains active. However, if any task fails, the monitoring task delays the feeding process, leading to a timer overflow and subsequent system reset. This ensures the microcomputer and all its tasks remain stable 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 microcontroller featuring real-time emulation and tracking capabilities, along with 64KB of high-speed Flash memory, four communication interfaces, two 32-bit timers, one 10-bit 8-channel ADC, and two hardware interfaces. It also includes 47 GPIOs and up to nine edge or level-triggered external interrupts, making it suitable for a wide range of applications and expansion needs.
uC/OS-II is a preemptive, real-time, multi-tasking operating system with open-source code, known for its portability, ease of use, and widespread adoption. It can manage up to 64 tasks, typically implemented as infinite loops. In the current version, tasks with priority levels ranging from 0 to OS_LOWEST_PRIO are available, allowing users to run up to 56 tasks simultaneously, which is sufficient for most application 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 repeatedly fails to restart, the system should be rebooted. Additionally, if the operating system itself or the hardware encounters an error, the watchdog should trigger a system restart. Based on these considerations, 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 restarted.
3. In cases where the operating system or hardware malfunctions, either the software or hardware watchdog initiates a system reset.
**2 Multi-task Watchdog Monitoring Principle**
By integrating the LPC2132’s built-in hardware watchdog with the uC/OS-II operating system, a high-priority monitoring task is assigned to track the operation of all application tasks. This monitoring task is referred to as the software watchdog. Each monitored task is associated with a timer, and the task must clear the corresponding timer within the set time interval, a process known as “feeding the soft dog.†Under normal conditions, the software watchdog periodically resets the hardware watchdog timer, effectively “feeding the dog.†If a monitored task fails, the software watchdog cannot clear the timer in time, causing it to overflow. The system kernel then directs the task’s stack address back to its starting point, restarting the task. If repeated attempts fail, the watchdog timer eventually overflows, triggering a full system restart. Furthermore, if the monitoring task itself fails, the hardware watchdog will also initiate a system reset.
**3 Software Implementation**
**3.1 Communication Between Application Tasks and Software Watchdogs**
When information is exchanged between the multitasking software watchdog and individual application tasks, each task sends its status to the monitor. In turn, the monitor sends messages to the tasks. Using mailboxes for communication can lead to inefficiencies and complexity, especially when there are many tasks involved. To address this, message queues are used instead. Each application task has two mailboxes: one for sending messages to the monitor and another for receiving messages from it. When an application task encounters an error, it calls the OSQPost() function to send a message to the monitor’s queue. The monitor reads the message using OSQPend(), then uses OSMboxPost() to send a response to the task’s mailbox. The task then reads the message via OSMboxPend() and performs the necessary action based on the received signal.
**3.2 Implementation of the Multitasking Software Watchdog**
The multitasking watchdog monitors the operational status of each task by checking whether they “feed the soft dog†within a specified time frame. Using the microprocessor’s timer interrupt mechanism, each task is assigned a timing unit and a running flag. The timer is independently updated based on the task’s status. When a task is idle, it periodically “feeds the soft dog†at intervals shorter than the configured time. When the task is active, the maximum expected execution time is considered, and the timer is set slightly longer. During periodic interrupts, the timer in the monitor task counts down. If the task runs normally, it sends a signal to “feed the soft dog,†clearing the timer and resetting the task. If the task fails, the watchdog timer overflows, prompting the monitor to reset the task and increment the restart counter. If the task continues to fail, the system is eventually restarted to ensure overall stability.
**4 Conclusion**
By combining the LPC2132’s built-in hardware watchdog with the uC/OS-II operating system, a multitasking-capable software watchdog was designed. This watchdog not only effectively monitors various application tasks but also minimizes disruption to other processes. When a task operates normally, it is restarted until multiple failures occur, at which point the system is rebooted. This ensures that application tasks remain independent while maintaining system stability. Moreover, the watchdog can automatically restart the system in the event of main program or hardware issues, ensuring long-term reliable operation.
Magnetic Ring Inductors,High Current Manganese Zinc Toroidal Inductors,Manganese Zinc Magnetic Ring Inductor Power,Toroidal Plug-In Inductors
Shenzhen Sichuangge Magneto-electric Co. , Ltd , https://www.scginductor.com