Memory Protection Unit (MPU) is available on many Cortex-M devices and allows to execute code with restricted access to memory regions and peripherals. Detailed information about the MPU can be found in Cortex-M Reference Manuals.

CMSIS-RTOS2 provides a concept of MPU Protected Zones as a simple and flexible mechanism for using MPUs with RTOS threads. MPU Protected Zones are defined by a user as a set of memory regions and peripherals with specified access rights, and each RTOS threads gets assigned to a specific MPU Protected Zone that it is allowed to use.

The figure below illustrates the concept for MPU Protected Zones for isolating threads.

System partitioning with MPU Protected Zones

Sections below explain in details how to define and use MPU Protected Zones:

Function references

Following functions implement and use MPU Protected Zone functionality:

osThreadNew : Create a thread and add it to Active Threads.
osThreadZone : MPU zone value in attribute bit field format.
osThreadGetZone : Get MPU protected zone of a thread.
osThreadTerminateZone : Terminate execution of threads assigned to a specified MPU protected zone.
osZoneSetup_Callback : Setup MPU protected zone (called when zone changes).

Define MPU Protected Zones

In the architectural design phase an application is logically split into functionalities with the same integrity level (same safety requirements). They can safely operate within the same MPU Protected Zone and hence access same memory areas and peripherals.

MPU protected zones are defined in an MPU table where each row describes an individual MPU zone and each cell in the row specifies an MPU region within that zone. For details see section MPU Functions in CMSIS-Core(M) documentation.

‍Note

Interrupt handlers bypass the MPU protection. For this reason, it is required that potential impact of all interrupt handlers is strictly analyzed to exclude unintended memory accesses.

Zone Identifier (Zone ID) is used to refer to a specific MPU protected zone. Zone ID value equals to the row index (starting from 0) in the MPU table that describes corresponding MPU Protected Zone.

An MPU Protected Zone is assigned to one or more RTOS threads. This is done by providing the Zone ID value in thread attributes osThreadAttr_t when creating the thread with the osThreadNew function.

Example:

/* ThreadA thread attributes */
const osThreadAttr_t thread_A_attr = {
  .name       = "ThreadA",       // human readable thread name
  .attr_bits  = osThreadZone(3U) // assign thread to MPU protected zone with Zone Id 3
};
osThreadNew(ThreadA, NULL, &thread_A_attr);

CMSIS-Zone provides a utility that allows graphic configuration of MPU protected zones and generates MPU table in the CMSIS format.

Load MPU Protected Zone

When switching threads the RTOS kernel compares Zone IDs of the currently running thread and the next thread to be executed. If the Zone Ids are different then a callback function osZoneSetup_Callback is called. This callback function shall be implemented in the user application code to actually switch to the new MPU Protected Zone. In the function the user should load the MPU Protected Zone according to the Zone Id provided in the argument.

Example:

/* Update MPU settings for newly activating Zone */
void osZoneSetup_Callback (uint32_t zone) {
 
  if (zone >= ZONES_NUM) {
    // Here issue an error for incorrect zone value
  }
 
  ARM_MPU_Load(mpu_table[zone], MPU_REGIONS);
}

RTOS Objects and MPU Protection

To access RTOS objects from the application RTOS APIs rely on a numeric xxx_id parameter associated with the object as explained in Lifecycle of RTOS Objects. For example as evt_flags in this code:

osEventFlagsId_t evt_flags;
evt_flags = osEventFlagsNew(NULL);
osEventFlagsSet(evt_flags, 1);

The allocation of an RTOS object to the memory in a specific MPU Protected Zone does not provide access restriction. The access restriction can be bypassed if another thread calls the CMSIS-RTOS2 API with the object ID of the RTOS object as argument. The CMSIS-RTOS2 function is executed in handler mode and therefore can access and modify the RTOS object without raising a Memory Fault.

To enable access control for RTOS objects the Safety Classes concept is introduced in CMSIS-RTOS2.

Handle Memory Access Faults

A memory access fault is triggered when a thread tries to access memory or peripherals outside of the MPU Protected Zone loaded while the thread is running. In such case Memory Management Interrupt MemoryManagement_IRQn is triggered by the processor and its handling function is executed according to the exception vector table specified in the device startup file (by default MemManage_Handler(void) ).

The MemManage_Handler() interrupt handler is application specific and needs to be implemented by the user. In the handler it is possible to identify the thread that caused the memory access fault, the corresponding zone id and the safety class. This information can be used to define actions for entering a safe state. Fault Handling provides more details on the available system recovery possibilities.