Arm Cortex-M4

Applicable for

STM32MP15x lines

---

1. Article purpose

The purpose of this article is to:

• briefly introduce the Arm^® Cortex^®-M4 core and its main features,
• indicate the peripheral management at boot time and at runtime (including whether it can be managed by the secure contexts),
• list the software frameworks and drivers managing the peripheral,

2. Peripheral overview

The Arm Cortex-M4 is seen as a coprocessor on STM32MP15, where the Arm Cortex-A7 is the main processor that controls it. The Cortex-M4 is present across all the STM32MP15x lines.

The Cortex-M4 is a Armv7E-M 32-bit processor. The Armv7E-M architecture corresponds to the Armv7-M architecture, with DSP extension. Among a wide range of features, it includes a memory protection unit (MPU) and a single-precision floating point unit (FPU).

The Cortex-M4 does not support secure mode: it only supports a non-secure mode that defines the Cortex-M4 non-secure hardware execution context.

Refer to the STM32MP15 reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

3. Peripheral usage

3.1. Boot time assignment

The Cortex-M4 can be startup at boot time by U-Boot SSBL (see boot chain) , as explained in the How to start the coprocessor from the bootloader article.

Thanks to a specific OP-TEE trusted application (TA) running on the Arm^® TrustZone and to the ETZPC peripheral, it is possible to authenticate the Cortex^®-M4 firmware and install it on isolated MCU RAM to ensure its integrity during the execution. For details, please refer to How_to_protect_the_coprocessor_firmware article.

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)
Core/Processors	Cortex-M4	Cortex-M4			☐	How to start the coprocessor from the bootloader How_to_protect_the_coprocessor_firmware

3.2. Runtime assignment

The Cortex-M4 can be started and stopped at runtime by the Linux remoteproc framework.

Thanks to a specific OP-TEE trusted application (TA) running on the Arm^® TrustZone and to the ETZPC peripheral, it is possible to authenticate the Cortex-M4 firmware and to install it on isolated MCU RAM to ensure its integrity during the execution. For details, please refer to How_to_protect_the_coprocessor_firmware article.

Once started, the Cortex-M4 executes the STM32CubeMP1 firmware, which controls the Cortex-M4 internal resources (MPU, WFI,...)

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)
Core/Processors	Cortex-M4	Cortex-M4	☐	☐	✓	Controlled by LInux or OP-TEE. Running the STM32CubeMP1 firmware.

4. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the Cortex-M4 for the embedded software components listed in the above tables.

• The Cortex-M4 runs applications developed using to the STM32CubeMP1 distribution package.
• The Cortex-M4 can be startup at boot time or at runtime, with or without firmware authentication, using the remoteproc frameworks available in different components of the OpenSTLinux distribution:

• Linux^®: Linux remoteproc framework
• U-Boot: drivers/remoteproc
• OP-TEE: OP-TEE remoteproc source code

• The Cortex-M4 operates as a coprocessor, either autonomously as any external microcontroller, or communicating with the main processor (Cortex-A7) via the RPMsg communication pipe.

5. How to assign and configure the peripheral

Two steps to configure the Cortex-M4 and the peripherals assigned to it:

1. As the main processor of the system, the Cortex-A7 (running OpenSTLinux distribution) first takes care of the initialization of all system resources: supplies, clock tree, and so on.
2. The STM32CubeMP1 package then takes care of all the Cortex-M4 local configuration (NVIC, MPU, and so on). It can rely on the resource manager to modify system resources without interfering with the Cortex-A7.

6. How to go further

Refer to the Arm website for more detailed information on this core.