You copied the Doc URL to your clipboard.

RTOS design requirements

Several areas of RTOS design requirements require particular attention. For example, to prevent Secure stack overflow, stacks for Secure software must be protected with stack limit registers.

To reduce stack size requirements, Process stack pointers (PSP) must be used for threads. The thread only needs to allocate stack for the thread and the first level of the exception stack frame, which avoids having to reserve stack for exceptions and interrupt handlers.

Since Secure software can force Secure exceptions to have higher priority than Non-secure exceptions using AIRCR.PRIS, the Secure PendSV exception handler might be able to preempt a Non-secure interrupt. Therefore, the Secure RTOS scheduler might have to check EXC_RETURN bit[3], or then ICSR.RETTOBASE (Return to base) status bit in handling context switching.

RTOS running in the Secure world

The RTOS kernel can access both Secure and Non-secure stack and stack pointers when the RTOS is running in the Secure world. The Task Control Blocks (TCBs) might contain Secure information, including register contents in Secure state and the PSP_S values.

It is easier to place all TCBs in Secure memory as it can hold the register content of a thread, even if the thread is in a Non-secure state.

Assuming that the RTOS design uses PSP for thread stack management, the list of registers that must be saved in the TCB include:

  • Callee saved registers (R4 to R11) in integer register banks.

Note

Caller saved registers R0-R3, R12 are on the stack frame already.

  • If CONTROL.FPCA is 1 and EXC_RETURN bit [4] is 0, then floating-point registers S16 to S31. (S0 to S15, and the floating-point Status and Control register (FPSCR) are saved in the stack frame with lazy stacking.)
  • PSP_S and PSP_NS, PSPLIM_S and PSPLIM_NS (if using ARMv8-M architecture with Main Extension).
  • CONTROL_S (Secure), CONTROL_NS(Non-secure) and EXC_RETURN values. These registers hold the state information, which can be privileged or unprivileged, and Secure or Non-secure.
  • MPU region configurations (optional).

If EXC_RETURN.SPSel is 0b0, an exception handler other than PendSV is active. Here context switching cannot be performed and the RTOS must schedule context switch operations in the next tick.

If EXC_RETURN.FType is 0b0, floating-point context is active and context switching can be implemented in Secure PendSV at lowest Secure priority level, as follows:

  1. Store callee saved registers (R4 to R11) in TCB.
  2. Save FPU S16-S31 to the TCB. S0-S15 and FPSCR would be saved automatically with lazy stacking.
  3. Save PSP_S, PSP_NS, PSPLIM_S, PSPLIM_NS, EXC_RETURN, CONTROL_S, and CONTROL_NS in the TCB.
  4. Set PSPLIM_S and PSPLIM_NS to 0 to disable the limit check.
  5. Load PSP_S, PSP_NS, then PSPLIM_S and PSPLIM_NS for new thread.
  6. Load callee save registers and FPU registers from the new TCB.
  7. Load EXC_RETURN and CONTROL from the new TCB.

At the end of this sequence, the exception returns to the new thread.

RTOS running in the Non-secure world.

When the RTOS is running in the Non-secure world, the RTOS kernel can only access the Non-secure stacks and stack pointers, and must use the CMSIS-RTOS v2 Security Extension API to handle context switching. In this arrangement, there is no other active exception running when the Non-secure PendSV handler executes, and this avoids the need for checking for running exception handlers before starting context switch.

Note

The detail is based on the CMSIS-RTOS API v2 and the APIs has not been finalized.

When the RTOS design uses PSP for thread stack management the list of registers to be saved in the TCB include:

  • Callee saved registers (R4 to R11) in integer register banks.

Note

Caller saved registers R0-R3, and R12 are on the stack frame already.

  • If FPCA is 1 and EXC_RETURN bit [4] is 0, then the floating-point registers S16 to S31, S0 to S15, and FPSCR are saved in the stack frame with lazy stacking.
  • PSP_NS and PSPLIM_NS (if using ARMv8-M architecture with Main Extension).
  • CONTROL_NS and EXC_RETURN values. These hold the state information, privileged or unprivileged.
  • MPU region configurations (optional).

The RTOS can also add additional information in the TCB, if necessary.

Depending on the value of EXC_RETURN.S, the thread is running a Secure API (0b1) or a Non-secure API (0b0).

If running a Secure API, call TZ_Store_Context_S() to save the Secure contexts. Otherwise, it is common practice to implement context switching in Non-secure PendSV at the lowest Secure priority level, as follows:

  1. Store callee saved registers (R4 to R11) in the TCB.

Note

Caller saved registers R0-R3, and R12 are on the stack frame already.

  1. If EXC_RETURN.FType is 0, the floating-point context is active. Save FPU S16-S31 to the TCB. S0-S15 and FPSCR are saved automatically with lazy stacking.
  2. Save PSP_NS, PSPLIM_NS, EXC_RETURN and CONTROL_NS in the TCB.
  3. Set PSPLIM_NS to 0 to disable the limit check.
  4. Load PSP_NS, then PSPLIM_NS for new thread.
  5. If EXC_RETURN.S of the new thread is 1, call TZ_Load_Context_S() to update PSP_S and PSPLIM_S. Otherwise, load the following register from TCB:
    1. Load callee save registers.
    2. FPU registers S16-S31 if the EXC_RETURN bit 4 of the new thread is 0.
  6. Load EXC_RETURN and CONTROL_NS from new TCB.

At the end of this sequence, the exception returns to the new thread.

The impact of the AIRCR.PRIS bit

In the ARMv8-M architecture Secure software can use the programmable Prioritize Secure Exceptions(PRIS) bit in the Application Interrupt and Reset Control Register (AIRCR) to shift the Non-secure exception priority by 1 bit so that the Non-secure exceptions are mapped to lower half of priority levels.

As a result of the PRIS bit, the Non-secure exceptions can have lower priority than the lowest priority Secure exceptions. For example, if Secure PendSV is set to lowest priority, the priority level is 0xC0. For Non-secure exceptions, the lowest priority level is 0xE0. As a result, if Secure PendSV is used for context switching, for example triggered by Secure SysTick exception, the following sequence can occur:

  • Non-secure IRQ is running at lowest priority level.
  • Secure SysTick is triggered and executed.
  • Secure SysTick handler set Secure PendSV pending status.
  • Secure SysTick handler exit, tail chained into Secure PendSV.

In this situation, the Secure PendSV must not execute context switching because a Non-secure interrupt handler is still running.

To solve this issue, there are several possible solutions:

  • Option 1: Make sure that AIRCR.PRIS is not used.
  • Option 2: Check EXC_RETURN and ICSR.RETTOBASE before context switches.
  • Option 3: Use Non-secure PendSV at lowest priority level to call a Secure API to handle context switching.

RTOS running in Non-secure state do not have the same issue.

Supporting multiple Secure software libraries.

Secure RTOS designers must also consider cases where the Secure MPU is used for supporting multiple Secure software libraries. Here the Secure MemManage fault is used to control context switching between different libraries. A Secure RTOS must be aware of such MPU context changes

Was this page helpful? Yes No