You copied the Doc URL to your clipboard.

RTOS design for the ARMv8-M architecture

Several processor features have been extended in the ARMv8-M architecture. This can affect RTOS designs in several ways. Usually, the RTOS code must be updated to run on ARMv8-M architecture.

Some of the changes that are required are generic to RTOS designs:

  • The change of Memory Protection Unit (MPU) programmers’ model to Protected Memory System Architecture (PMSA) v8 means that an RTOS with MPU support must update MPU support code.
  • The extension of the EXC_RETURN (Exception Return) value definition means that if the OS creates a thread by exception return with an artificially created stack frame, the value of EXC_RETURN used is likely to change.

Additional changes are required to take advantage of the new capabilities in the ARMv8-M architecture. For example:

  • Stack limit features are available for both Secure and Non-secure states in the ARMv8-M architecture with Main Extension, and are available in Secure state for the ARMv8-M architecture. The stack limit feature enables stack overflow scenarios to be detected. Stack overflows are one of the most common sources of software errors in embedded systems.
  • Depending on the configuration of the system, an RTOS can support both Secure and Non-secure threads. For such cases, you must update the RTOS to support extra stacks.
  • For RTOS previous written for the ARMv6-M architecture, moving to the ARMv8-M architecture enables the OS to use exclusive access instructions for semaphore variable updates. This architecture enhancement also enables the ARMv8-M architecture with Main Extension and the ARMv8-M architecture versions of the OS to share semaphore code.
  • If the RTOS is delivered in compiled library form, recompilation of the RTOS code enables the software to be optimized for ARMv8-M processors.

Depending on the system-level design around the ARMv8-M processor, the Secure software and associated resources might be locked down. This means that software developers can only update the Non-secure program address space and access to Non-secure hardware resources. Secure resources can only be accessed using APIs in the Secure firmware. Such restrictions affect RTOS designs and the Secure firmware. Multiple design configurations are possible.

There are several different possible systems and RTOS configurations. RTOS vendors might need to implement different configurations of their RTOS to address different product requirements.

To assist RTOS operations in devices with locked down Secure memories, CMSIS-RTOS has been extended with additional APIs. These APIs enable RTOS running in Non-secure domain to handle context switching.

Was this page helpful? Yes No