Multiple porting solutions for μC/OS-II on LPC213X

μC/OS-II is portable and suitable for real-time multi-tasking embedded systems with strict security requirements. It is easy to learn and is very popular in engineering applications and embedded system teaching. LPC213X is a 32-bit RISC microprocessor based on the ARM7TDMI-S core launched by Philips, which is also suitable for ARM learning and development platforms and engineering applications.

1 Main features related to the μC/OS-II porting work
The ARM architecture is divided into 7 operating modes, and there are two working states: ARM and Thumb. The programming model of LPC213X is the standard ARM7 architecture; at the same time, LPC213X also has ARM's standard exception modes IRQ and FIQ. The VIC vector interrupt controller is slightly more distinctive. IRQ, FIQ, non-vector interrupts and software interrupts are classified separately, and a programmable allocation mechanism for 32 interrupt inputs is provided. This is crucial for the porting of μC/OS-II.

The RTC real-time clock inside the chip can be provided by an independent 32 MHz crystal oscillator or a programmable pre-scaling based on the VPB clock as the clock beat source of the real-time system.

2 Main Work of μC/OS-II Porting
The porting work is divided into two parts: compiler-related and processor-related. The former mainly involves data type definition, code format, header file organization, conditional compilation options and mixed programming, etc.; the latter mainly involves switch interrupts, stack direction, task stack structure initialization, task scheduling, interrupt control and response, clock beat processing and high priority task execution, etc. It

mainly involves writing three files: OS_CPU.H, OS_CPU_C.C and OS_CPU_A.S. Among them, l mainly contains the following important functions: OSTaskStkInit(), OSStartHighRdy(), OSCtxSw(), OS-IntCtxSw() and OSTickISR(), etc. In addition, configuration files, boot and initialization codes and debugging must be written.

3 Two feasible porting solutions
For the 7 different operating modes of ARM, the processor mode solutions used when porting the μC/OS-II system are diverse. For example, the system can be run in SVC management mode, SWI soft interrupts also use SVC mode, and others are exception modes; μC/OS-II can also be run in SYS system mode; μC/OS-Il can also be run in user mode, and when the task or interrupt is switched, it will be switched from SVC mode or IRQ, FlQ mode to SYS mode to process the stack. The following two schemes are formed here, and a brief analysis is given in combination with the transplantation process.

Scheme 1: The system runs in SVC management mode, and the exception runs in exception mode.
① Switch interrupt. Set OS_CRITICAL_METHOD to 3 in this scheme, then the interruption process is to save the CPSR register value to RO first, and disable FIQ and IRQ by setting CPSR6 and CPSR7. When the interrupt is turned off, the CPSR saved in R0 when the interrupt is turned on is restored.
② Task switching. Because non-exceptional tasks all run in SVC mode, the task switch only needs to save the register state of the old task to the stack and restore the stack state of the new task to the register. The relevant function is OSCtxSw(). It should be noted that there is no need to be responsible for SPSR in the context switch here, because SPSR is a backup CPSR register and only takes effect when the mode switch exits from FIQ or IRQ mode. In other words, SPSR always takes effect when interrupts are disabled.
③ Interrupt-level task switching and corresponding interrupt mechanism. Interrupt exceptions are divided into FIQ and IRQ exceptions. The interrupt-level task switching process of IRQ OS_CPU_IRQ_ISR() is shown in Figure 1. [page]

As shown in Figure 1, this function, as the interrupt dispatching function of the μC/OS-II system, immediately returns to the SVC mode to save the original task status after entering the interrupt IRQ mode; then returns to the IRQ to execute the user-level interrupt processing code OS_CPU_IRQ_ISR_Handler(); after completion, returns to the SVC mode to run the highest priority task.

LPC213X has a VIC vector interrupt controller, which divides all interrupts into FIQ, vector interrupts and non-vector interrupts. FIQ starts the processing program from the interrupt vector table and directly calls the interrupt processing program in the user interrupt processing code OS_CPU_FTQ_ISR_Handler(); and the vector interrupt IRQ will appear in the VICVectAddr (0xFFFFF030) register when responding. Therefore, the user interrupt processing code of the IRQ of μC/OS-II must be processed as follows:

④Interrupt vector table. In the interrupt vector table of this solution, the FIQ and IRQ interrupt vectors are filled with program jump instructions. Among them, FIQ jumps to OS_CPU_FIQ_ISR(), and IRQ jumps to OS_CPU_IRQ_ISR().
⑤Generation of clock beats. The μC/OS-II clock beat requires an accurate interval of 10 to 100 ms. LPC213X uses an 11 MHz external crystal oscillator, the frequency division ratio of the peripheral clock to the system clock is set to 1, and the RTC sets the peripheral clock as the clock source, then uses Timer0 as the vector interrupt IRQ, and writes a clock interrupt handler to implement the clock beat.

Solution 2: The system runs in SYS system mode, the exception service program is processed in SYS system mode, and the soft interrupt is processed in management mode.
① Switch interrupt. In this solution, OS_CRITICAL_METHOD is 2. The specific process is not directly implemented from the assembly code, but is implemented through the software interrupt SWI system service. The switch interrupt is performed in SVC management mode because ARM determines that CPSR can be accessed in any mode.
② Task switching. Task switching includes task-level scheduling switching and interrupt handler scheduling switching. Task-level switching is implemented using the soft interrupt SWI method. It should be noted that the SWI interrupt handler does not return at this time, so the stack address space of the SVC management mode is reinitialized at the beginning of each SWI interrupt, otherwise it will cause memory leaks or overflows. The process is shown in Figure 2.

In Figure 2, the first step is the general processing of software interrupts, which is the code that must be run for each software interrupt; and the following steps are the codes required for task scheduling. The specific scheduling is implemented by OSCtxSw to implement context switching. The overall implementation is implemented using the macro OS_TASK_SW(), which is defined as a soft interrupt in OS_CPU.H and assigned interrupt number 0.
③ Interrupt-level task switching. According to the VIC control characteristics of the LPC213X processor, the traditional processing method of the foreground and background systems is used to call the interrupt handler, but each interrupt handler is added with the same task context switching related code, which is implemented using the macro assembly method. The specific process is shown in Figure 3. As can be seen from the figure, both the context saving and the ready recovery tasks are performed in IRQ mode, while the user-level handler is performed in SYS mode, which is exactly the opposite of the previous solution. However, the design of interrupt scheduling and the implementation using macro assembly increase the amount of repeated code when there are more system interrupt processing calls.
④ Interrupt vector table. In the interrupt vector table of this solution, interrupt vectors such as FIQ and IRQ are filled with the names of the interrupt processing service programs corresponding to the macro assembly function, and no special processing is performed.
⑤ Generation of clock beats. The clock beat of this scheme is generated in the same way as the previous scheme. [page]

4 System startup and boot process
In addition to the above porting codes, there is still a lot of work to do for system startup, and the process is shown in Figure 4.

The configuration of the interrupt vector table in Figure 4 should be done according to the above two schemes, while the initialization mode stack is a task that must be completed in different modes. User-level initialization code can be written in the initialization of peripheral devices.

5 Debugging process of transplanted code
Sometimes, debugging of transplanted code of multi-task system cannot be done in single step. The introduction of clock beat makes the system much more complicated than the foreground and background system, so a good debugging method is required. The following debugging steps can be adopted:
① Turn off the clock beat, that is, turn off the clock interrupt single step debugging to see if the system will enter the Taskldle task;
② Turn off the clock beat and debug the FIQ and IRQ interrupt codes separately at the same time;
③ Turn on the clock beat and debug the clock interrupt ISR separately;
④ Write a simple multi-task program (1 or 2), and call the OSTimaDly(1) function in each task at the same time to check the specific process scheduling process. (For transplant codes of various schemes, please see the website of this magazine www.mesnet.com.cn - Editor's note)

6 Conclusion
The most common problem in the transplantation process of various systems is memory leak, which often causes code prefetching or data abort exceptions on the chip. For the application system, corresponding prompts should be given for this type of abort exception.

μC/OS-II transplantation is highly comprehensive. Before transplantation, you must understand the principle of multi-task switching and the system kernel structure, be familiar with ARM assembly language and programming model, understand the content of startup code, compiler and chip interrupt system, etc. This work seems simple but is actually rich in content and requires comprehensive software and hardware knowledge.

The two transplantation solutions given in this article are feasible and efficient. They can also be applied to other ARM7TDMI core chips after minor changes; at the same time, they are also of great reference value for the transplantation of other embedded systems on processors without MMU memory management modules. Please contact wlazhenqian@hotmail.com to provide the relevant code of this article free of charge.