Getting started with STM32 MPU devices

1. Extending the STM32 MCU family to the MPU world

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 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. These markets require more processing power and more flexibility, which can easily be leveraged thanks to the open source components ported on theArm^® Cortex^®-A.

The figure above shows the hardware components that are typically embedded in a MPU, compared to the ones to be found in a MCU. Note that if some of the MPU components are optional, one Arm^® Cortex^®-A is always present.

The STM32MP13x lines extend the STM32MP1 series with a lighter MPU that only embeds a single Cortex-A7 and target applications that have the strongest requirements on security and low power perspectives.

The STM32MP25x lines (industrial-grade 64-bit MPUs) are the first of the STM32MP2 series, and target secure industry 4.0 and advanced edge computing applications that require high-end multimedia capabilities. They are built around single or dual Arm^® Cortex^®-A35 cores and a single Arm^® Cortex^®-M33.

2. Multiple-core architecture concepts

1. Boot chain

---

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

Each core can run in a non-secure and, possibly, a secure (Arm Trustzone^TM) modes.
An hardware execution context is composed of a core and a security mode.

The two hardware execution contexts available on STM32MP13 devices are:

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

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 five hardware execution contexts available on STM32MP15 devices are:

•  Arm Cortex-A secure  (Trustzone)
•  Arm Cortex-A non-secure 
•  Arm Cortex-M non-secure 
•  Arm Cortex-M secure  (Trustzone)
•  Arm Cortex-M0+ non-secure 

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

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

A firmware is the executable binary that is the build result of an embedded software component (e.g., Linux). Thus, a firmware is executed on a context: through misuse of language, an embedded software component (instead of its firmware) is sometimes said as executed on a context.

2.2. Firmwares executed in the boot time contexts

Each boot time context executes given firmware's:

•  Arm Cortex-A secure  (Trustzone), executes the ROM code and TF-A BL2
•  Arm Cortex-A non-secure , executes U-Boot

The ROM code is embedded inside the microprocessor device and it is the first code executed by the Arm^® Cortex^®-A core(s) after reset.
TF-A BL2 and U-Boot are STM32MPU Embedded Software components.

2.3. Firmwares executed in the runtime contexts

Each runtime context executes given firmware's:

•  Arm Cortex-A secure  (Trustzone), executes OP-TEE and/or TF-A BL31'
•  Arm Cortex-A non-secure , executes Linux
•  Arm Cortex-M non-secure , executes STM32Cube
•  Arm Cortex-M secure  (Trustzone), executes TF-M
•  Arm Cortex-M0+ non-secure , executes STM32Cube

OP-TEE, TF-A BL31, Linux, STM32Cube and TF-M are STM32MPU Embedded Software components.

2.4. Peripheral assignment to the boot time and runtime contexts

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

The assignment capabilities for each XXX peripheral (e.g., GPIO) are described in the "XXX internal peripheral" article (e.g., "GPIO internal peripheral"), and any article named "STM32MPxx peripherals overview" (e.g., "STM32MP15 peripherals overview) summarizes the assignment capabilities for all peripherals of the STM32MPxx microprocessor device (e.g., STM32MP15), with tables similar to the examples below:

Click on to expand or collapse the legend...

Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:

• ⬚ means that the peripheral can be assigned to the given boot time context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
• ☐ means that the peripheral can be assigned to the given boot time context.
• ☑ means that the peripheral is assigned by default to the given boot time context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
• ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities might be described in STM32 MPU reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A7 secure (ROM code)	Cortex-A7 secure (TF-A BL2)	Cortex-A7 non-secure (U-Boot)
XXX	YYY	YYY1		☐	☐	YYY1 can be assigned (single choice) to whether Cortex-A secure (TF-A BL2) or Cortex-A non-secure
		YYY2			☐	YYY2 can only be assigned to Cortex-A non-secure
		YYY3	✓	✓	✓	YYY3 is shared accross all contexts

Click on to expand or collapse the legend...

STM32MP15 internal peripherals

Check boxes illustrate the possible peripheral allocations supported by STM32 MPU Embedded Software:

• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
• ☐ means that the peripheral can be assigned to the given runtime context.
• ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
• ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possiblities might be described in STM32MP15 reference manuals.

Domain	Peripheral	Runtime allocation				Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)	Cortex-M4 (STM32Cube)
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

Refer to How to assign an internal peripheral to an execution context for detailed instructions.

3. STM32 MPUs

What are the main features of an STM32 microprocessor device?
How to program STM32 microprocessor device-internal peripherals?
How to configure internal peripherals for new boards?
Click on the links in the frame below and be guided!

		STM32MP13x lines	STM32MP15x lines
		STM32MP25x lines

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

Microprocessor unit

Memory management unit. (A hardware device or circuit that supports virtual memory and paging by translating virtual addresses into physical addresses.)

Arm^® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Cortex^®

Real time operating system

Random access memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Flash memories combine high density and cost effectiveness of EPROMs with the electrical erasability of EEPROMs. For this reason, the Flash memory market is one of the most exciting areas of the semiconductor industry today and new applications requiring in system reprogramming, such as cellular telephones, automotive engine management systems, hard disk drives, PC BIOS software for Plug & Play, digital TV, set top boxes, fax and other modems, PC cards and multimedia CD-ROMs, offer the prospect of very high volume demand.

Operating system

Linux^® is a registered trademark of Linus Torvalds.

Non volatile memory, like a flash memory

Graphics processing units

Read only memory

Trusted firmware for Arm^® Cortex^®-A

Boot loader stage 2

Das U-Boot -- the universal boot loader (see U-Boot)

Open portable trusted execution environment

General-purpose input/output (A realization of open ended transmission between devices on an embedded level. These pins available on a processor can be programmed to be used to either accept input or provide output to external devices depending on user desires and applications requirements.)