STM32 MPU microprocessor devices

Applicable for

1. Extending the STM32 MCU family to the MPU world[edit source]

Microcontroller units (MCUs) are built around MMU-less cores such as the Arm Cortex-M, which are very efficient for deterministic operations in a bare metal or real time operating system (RTOS) context. STMicroelectronics STM32 MCUs embed enough SRAM (static RAM) and Flash memory for many applications, and this can be completed with external memories.

Microprocessor units (MPUs) rely on cores such as the Arm Cortex-A, with memory management unit (MMU) to manage virtual memory spaces, opening the door to efficient support of a rich operating system (OS) such as Linux. A fast interconnect makes the bridge between the processing unit, high-bandwidth peripherals, external memories (RAM and NVM) and, usually, a graphical Processing Unit (GPU).

STMicroelectronics has a strong presence in MCU markets with STM32 family ^[1] and entered the MPU market with a first platform referenced as STM32MP15. This platform aims to address multiple market segments such as industrial, consumer, healthcare, home and building automation. Those markets require more processing power and more flexibility, which can easily be leveraged thanks to the open source components ported on the Arm Cortex-A.

The figure above shows the hardware components that are typically embedded in a MPU, compare to a MCU. Notice that some of the MPU components are optional but, at least, one Arm Cortex-A is always there.

The STM32MP13 extends the STM32MP1 microprocessor series with a lighter MPU that only embeds a single Cortex-A7 and targets applications that have strongest requirements on security and low power perspectives.

2. Multiple-core architecture concepts[edit source]

Runtime context initialization at boot time

As seen above, the MPU is a multiple-core architecture that can interact with a wide number of peripherals. Some new concepts need to be introduced for a good understanding of the system: these concepts are explained below and are illustrated in the figure on the right.

2.1. Hardware execution contexts[edit source]

Each core can run in a non-secure and - eventually - a secure (Arm Trustzone^[2]) mode.
A hardware execution context corresponds to a core and security mode.

The three hardware execution contexts available on STM32MP15 devices are:

Arm Cortex-A secure (Trustzone)
Arm Cortex-A non secure
Arm Cortex-M (non-secure)

The two hardware execution contexts available on STM32MP13 devices are:

Arm Cortex-A secure (Trustzone)
Arm Cortex-A non secure

Each hardware execution context can host different firmware, depending on the platform state. The following contexts can be distinguished:

the boot time context, corresponding to a transitory firmware execution, when the device is booting up
the runtime context, corresponding to an established firmware execution, when the device is up-and-running

2.2. Firmwares executed in the runtime contexts[edit source]

Each runtime context executes a given piece of firmware:

Arm Cortex-A secure (Trustzone), executes OP-TEE^[3]
Arm Cortex-A non secure , executes Linux^[3]
Arm Cortex-M (non-secure), executes STM32Cube^[3]

OP-TEE, Linux and STM32Cube are STM32MPU Embedded Software^[3] components.

2.3. Peripheral assignment to the runtime contexts[edit source]

The term peripheral assignment is used to identify the action to assign a set of peripherals to a runtime context. This is a user choice that can be realized via STM32CubeMX^[4] or manually, in order to properly configure the boot chain^[5] and the several pieces of firmware that run on the platform.

Each microprocessor peripheral-overview article shows the assignment capabilities for each peripheral, with a table similar to the example below:

Domain	Peripheral	Runtime allocation				Comment
Domain	Peripheral	Instance	Cortex-A S (OP-TEE)	Cortex-A NS (Linux)	Cortex-M (STM32Cube)	Comment
XXX	YYY	YYY1		☐	☐	YYY1 can be assigned (single choice) to whether Cortex-A non-secure or Cortex-M
		YYY2	☐			YYY2 can only be assigned to Cortex-A secure
		YYY3	✓	✓	✓	YYY3 is shared accross all contexts: this is typically the case for system peripherals