ARM Cortex-M0 PendSV Context Switch Failure with Bootloader

ARM Cortex-M0 PendSV Context Switch Failure with Bootloader

The issue at hand involves a failure in the context switching mechanism of a FreeRTOS application running on an ARM Cortex-M0 processor when a bootloader is present. Specifically, the PendSV exception handler, which is responsible for context switching, behaves incorrectly when the application is launched from a bootloader. Without the bootloader, the application runs as expected. The primary symptom is an incorrect Link Register (LR) value upon exiting the PendSV handler, leading to improper execution flow. This issue is critical because context switching is fundamental to the operation of any real-time operating system (RTOS), and its failure can result in system crashes, data corruption, or undefined behavior.

The Cortex-M0 processor, being a member of the ARMv6-M architecture, has a simplified exception handling model compared to its more advanced counterparts like the Cortex-M3 or Cortex-M4. One of the key limitations of the Cortex-M0 is its lack of support for vector table relocation, which is a feature available in higher-end Cortex-M processors. This limitation becomes particularly relevant when a bootloader is involved, as the bootloader and application may have different expectations about the location of the vector table.

The PendSV exception is a critical component of the FreeRTOS context switching mechanism. It is used to defer context switching to a safe point in time, ensuring that interrupts are not disabled for extended periods. When the PendSV handler is invoked, it saves the current task’s context, switches to the next task, and restores the new task’s context. The LR register plays a crucial role in this process, as it holds the exception return value, which determines the stack pointer (PSP or MSP) and execution mode (Thread or Handler) to be used upon exception return.

In this scenario, the presence of a bootloader introduces additional complexity. The bootloader may modify the vector table or other system configurations, leading to inconsistencies between the bootloader and application environments. The incorrect LR value observed upon exiting the PendSV handler suggests that the exception return mechanism is not functioning as intended, likely due to misconfigured or conflicting vector table settings.

Vector Table Misconfiguration and LR Corruption

The root cause of the issue lies in the interaction between the bootloader, the application, and the Cortex-M0’s exception handling mechanism. The Cortex-M0 does not support vector table relocation, meaning that the vector table must reside at a fixed address in memory (typically 0x00000000). When a bootloader is present, it is common practice for the bootloader to occupy the initial portion of the flash memory, including the vector table. The application, therefore, must either share the same vector table or use a mechanism to transfer control to its own vector table after the bootloader has completed its execution.

In this case, the bootloader appears to be attempting to remap the vector table, which is not supported by the Cortex-M0. This results in the application’s PendSV handler being invoked with incorrect settings, leading to the observed LR corruption. The LR register, which should contain the exception return value, is instead corrupted, causing the processor to return to an incorrect address or mode upon exiting the PendSV handler.

The bootloader code provided in the discussion includes a PendSV_Handler function that attempts to save and restore the LR register manually. However, this approach is flawed because it does not account for the Cortex-M0’s exception handling model. The Cortex-M0 automatically saves and restores certain registers, including the LR, during exception entry and exit. Manual manipulation of the LR register within the handler can interfere with this process, leading to unpredictable behavior.

Additionally, the application’s PendSV handler includes instructions to save and restore the LR register, which is unnecessary and potentially harmful. The Cortex-M0’s exception handling mechanism already handles the preservation of the LR register, and manual intervention can disrupt this process. The presence of these instructions suggests a misunderstanding of the Cortex-M0’s exception handling model and its interaction with the FreeRTOS context switching mechanism.

Correcting Vector Table Configuration and Exception Handling

To resolve the issue, several steps must be taken to ensure proper vector table configuration and exception handling. The first step is to modify the bootloader to avoid attempting to remap the vector table. Since the Cortex-M0 does not support vector table relocation, the bootloader must either share the same vector table as the application or transfer control to the application’s vector table in a manner that is compatible with the Cortex-M0’s architecture.

One approach is to have the bootloader and application share the same vector table. This can be achieved by placing the bootloader’s vector table at the beginning of the flash memory and ensuring that the application’s vector table is located immediately after the bootloader’s code. The bootloader can then transfer control to the application by jumping to the application’s entry point, which should be located at a fixed offset from the start of the flash memory. This approach ensures that the vector table remains at the correct address and that the application’s exception handlers are invoked correctly.

Another approach is to have the bootloader copy the application’s vector table to the correct location in memory before transferring control to the application. This requires the bootloader to be aware of the application’s vector table location and to copy it to the appropriate address before jumping to the application’s entry point. This approach is more complex but allows the bootloader and application to have separate vector tables, which may be necessary in some cases.

Once the vector table configuration has been corrected, the next step is to ensure that the PendSV handler is implemented correctly. The PendSV handler should not manually save or restore the LR register, as this is handled automatically by the Cortex-M0’s exception handling mechanism. Instead, the handler should focus on saving and restoring the task context, including the general-purpose registers and the stack pointer.

The provided application code includes several unnecessary and potentially harmful instructions related to the LR register. These instructions should be removed to ensure that the Cortex-M0’s exception handling mechanism functions correctly. The corrected PendSV handler should focus on saving the current task’s context, switching to the next task, and restoring the new task’s context. The following is an example of a corrected PendSV handler for the Cortex-M0:

PendSV_Handler:
    CPSID I                  ; Prevent interruption during context switch
    MRS R0, PSP              ; PSP is process stack pointer
    CMP R0, #0
    BEQ OS_CPU_PendSVHandler_nosave  ; Skip saving if PSP is null

    SUBS R0, R0, #0x10       ; Adjust stack pointer to where memory needs to be stored
    STM R0!, {R4-R7}         ; Save R4-R7
    SUBS R0, R0, #0x10       ; Adjust stack pointer back

    LDR R1, =OSTCBCur        ; OSTCBCur->OSTCBStkPtr = SP;
    LDR R1, [R1]
    STR R0, [R1]             ; Save SP of process being switched out

OS_CPU_PendSVHandler_nosave:
    LDR R0, =OSTaskSwHook    ; OSTaskSwHook();
    BLX R0

    LDR R0, =OSPrioCur       ; OSPrioCur = OSPrioHighRdy;
    LDR R1, =OSPrioHighRdy
    LDRB R2, [R1]
    STRB R2, [R0]

    LDR R0, =OSTCBCur        ; OSTCBCur = OSTCBHighRdy;
    LDR R1, =OSTCBHighRdy
    LDR R2, [R1]
    STR R2, [R0]

    LDR R0, [R2]             ; R0 is new process SP; SP = OSTCBHighRdy->OSTCBStkPtr;
    LDM R0!, {R4-R7}         ; Restore R4-R7 from new process stack
    MSR PSP, R0              ; Load PSP with new process SP

    CPSIE I                  ; Re-enable interrupts
    BX LR                    ; Exception return will restore remaining context

In this corrected version of the PendSV handler, the unnecessary instructions related to the LR register have been removed. The handler now focuses on saving and restoring the task context, ensuring that the Cortex-M0’s exception handling mechanism functions correctly. The CPSID I and CPSIE I instructions are used to disable and enable interrupts, respectively, to prevent interruptions during the context switch. The MRS and MSR instructions are used to access the Process Stack Pointer (PSP), and the STM and LDM instructions are used to save and restore the general-purpose registers.

Finally, it is important to verify that the bootloader and application are correctly configured to work together. This includes ensuring that the bootloader transfers control to the application’s entry point correctly and that the application’s vector table is located at the correct address. The following table summarizes the key steps required to resolve the issue:

By following these steps, the issue of incorrect context switching in the presence of a bootloader can be resolved, ensuring that the FreeRTOS application runs correctly on the ARM Cortex-M0 processor.