STM32MP15 peripherals overview

Applicable for

STM32MP15x lines

---

This article lists all internal peripherals embedded in STM32MP15 device and shows the assignment possibilities to the runtime contexts for each one of them.
Via this article, you can also access to individual peripheral articles in which information related to the overview and configuration can be found.

1. Internal peripherals overview

The figure below shows all peripherals embedded in STM32MP15 device, grouped per functional domains that are reused in many places of this wiki to structure the articles.

Several runtime contexts exist on STM32MP15 device, corresponding to the different Arm cores and associated security modes:

•  Arm dual core Cortex-A7 secure  (Trustzone), running a Secure Monitor or Secure OS like OP-TEE
•  Arm dual core Cortex-A7 non secure , running Linux
•  Arm Cortex-M4  (non-secure), running STM32Cube

Some peripherals can be strictly assigned to one runtime context: this is the case for most of the peripherals, like USART or I2C.
Other ones can be shared between several runtime contexts: this is the case for system peripherals, like PWR or RCC.
The legend below shows how assigned and shared peripherals are identified in the assignment diagram that follows:

Both the diagram below and the following summary table (in Internal peripherals assignment chapter below) are clickable in order to jump to each peripheral overview articles and get more detailed information (like software frameworks used to control them). They list STMicroelectronics recommendations. The STM32MP15 reference manual may expose more possibilities than what is shown here.

STM32MP1 internal peripherals overview

2. Internal peripherals assignment

Click on the right to expand 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
• ✓ is used for system peripherals that cannot be unchecked because they are statically 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.

3. Article purpose

The purpose of this article is to:

• briefly introduce the ADC peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

4. Peripheral overview

The ADC peripheral is a successive approximation analog-to-digital converter.

The STM32MP15 has one ADC block with two physical ADCs:

• Configurable resolution: 8, 10, 12, 14, 16 bits.
• Each ADC has up to 20 multiplexed channels (including 6 internal channels connected only to ADC2).
• The conversions can be performed in single, continuous, scan or discontinuous mode.
• The result can be read in a left- or right-aligned 32-bit data register by using CPU or DMA.
• The analog watchdog feature allows the application to detect if the input voltage goes beyond the user-defined, high or low thresholds.
• A common input clock for the two ADCs, which can be selected between 2 different clock sources (Synchronous or Asynchronous clock).
• The common reference voltage can be provided by either VREFBUF or any other external regulator wired to VREF+ pin.

Each ADC supports two contexts to manage conversions:

• Regular conversions can be done in sequence, running in background
• Injected conversions have higher priority, and so have the ability to interrupt the regular sequence (either triggered in SW or HW). The regular sequence is resumed, in case it has been interrupted.
• Each context has its own configurable sequence and trigger: software, TIM, LPTIM and EXTI.

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.

5. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

5.1. Boot time assignment

5.1.1. On STM32MP15x lines 

The ADC is usually not used at boot time. But it may be used by the SSBL (see Boot chain overview), to check for power supplies for example.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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	Runtime allocation				Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)	Cortex-M4 (STM32Cube)

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A7 secure (ROM code)	Cortex-A7 secure (TF-A BL2)	Cortex-A7 non-secure (U-Boot)
Analog	ADC	ADC			☐

5.2. Runtime assignment

5.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Analog	ADC	ADC		☐	☐	Assignment (single choice)

6. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the ADC peripheral for the embedded software components listed in the above tables.

• Linux^®: IIO framework
• STM32Cube: HAL ADC driver
• U-Boot: U-Boot ADC driver

7. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

For the Linux kernel and U-boot configuration, please refer to ADC device tree configuration article.

8. How to go further

See application notes:

• How to get the best ADC accuracy in STM32.
• Getting started with STM32MP15 series hardware development (AN5031).
  It deals with analog domain power supply and reference voltage.

10. Article purpose

The purpose of this article is to:

• briefly introduce the DAC peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

11. Peripheral overview

The DAC peripheral is a voltage output digital-to-analog converter:

• It may be configured in 8- or 12-bit mode (data could be left- or right-aligned)
• It has two output channels, each with its own converter
• The dual DAC channel mode could be done independently or simultaneously
• It has built-in noise and triangle waveform generator and supports triggers for conversions, using: TIM, LPTIM or EXTI
• The DAC output buffer allows a high drive output current
• It can operate under Normal mode or low-power Sample and Hold mode (uses LSI clock, from RCC).
• It may be used in conjunction with the DMA controller (with underrun error detection)
• The common reference voltage, can be provided by either VREFBUF or any other external regulator wired to VREF+ pin.

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.

12. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

12.1. Boot time assignment

The DAC peripheral is not used at boot time.

12.2. Runtime assignment

12.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Analog	DAC	DAC		☐	☐	Assignment (single choice)

13. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the DAC peripheral for the embedded software components listed in the above tables.

• Linux^®: IIO framework
• STM32Cube: HAL DAC driver

14. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

For the Linux kernel configuration, please refer to DAC device tree configuration and DAC Linux driver articles.

16. Article purpose

The purpose of this article is to:

• briefly introduce the VREFBUF peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

17. Peripheral overview

The VREFBUF peripheral is an internal voltage regulator.

The VREFBUF is supplied via the VDDA pin. When enabled, it can provide a reference voltage in the range of: 1,5V, 1,8V, 2,048V or 2,5V.

The VREFBUF can be used to provide an analog voltage reference for:

• ADC internal peripheral
• DAC internal peripheral
• External components through the dedicated VREF+ pin.

The VREFBUF can be left unused. In this case, an external voltage regulator can provide reference voltage to VREF+ pin.

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.

18. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

18.1. Boot time assignment

18.1.1. On STM32MP15x lines 

The VREFBUF is not used at boot time.

18.2. Runtime assignment

18.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Analog	VREFBUF	VREFBUF		☐	☐	Assignment (single choice)

19. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the VREFBUF peripheral for the embedded software components listed in the above tables.

• Linux^®: regulator framework

Information

The VREFBUF is a system resource which needs to be also controlled by the resource manager in case its consumers (e.g. ADC, DAC or an external device connected to VREF+ pin) are spread across: the Arm® Cortex®-A7 non-secure context the Arm® Cortex®-M4 context For this reason, the direct control of VREFBUF from the Arm® Cortex®-M4 is not recommended in STM32Cube by default. It's recommended to implement it in STM32Cube only if all consumers and the VDDA supply pin are controlled in the Arm® Cortex®-M4 context.

20. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

• For the Linux kernel configuration, please refer to device internal regulator. An example can be found also in ADC DT configuration examples
• In case the control of VREFBUF consumers are spread across the various cores, see also Resource manager for coprocessing

22. Article purpose

The purpose of this article is to:

• briefly introduce the IPCC peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

23. Peripheral overview

The IPCC (inter-processor communication controller) peripheral is used to exchange data between two processors. It provides a non blocking signaling mechanism to post and retrieve information in an atomic way. Note that shared memory buffers are allocated in the MCU SRAM, which is not part of the IPCC block.

The IPCC peripheral provides a hardware support to manage inter-processor communication between two processor instances. Each processor owns specific register bank and interrupts.

The IPCC provides the signaling for six bidirectional channels.
Each channel is divided into two subchannels that offer a unidirectional signaling from the "sender" processor to the "receiver" processor:

• P1_TO_P2 subchannel
• P2_TO_P1 subchannel

A subchannel consists in:

• One flag that toggles between occupied and free: the flag is set to occupied by the "sender" processor and cleared by the "receiver" processor.
• Two associated interrupts (shared with the other channels):
  • RXO: RX channel occupied, connected to the "receiver" processor.
  • TXF: TX channel free, connected to the "sender" processor.
• Two associated interrupt masks multiplexing channel IRQs.

The IPCC supports the following channel operating modes:

• Simplex communication mode:
  • Only one subchannel is used.
  • Unidirectional messages: once the "sender" processor has posted the communication data in the memory, it sets the channel status flag to occupied. The "receiver" processor clears the flag when the message is treated.
• Half-duplex communication mode:
  • Only one subchannel is used.
  • Bidirectional messages: once the "sender" processor has posted the communication data in the memory, it sets the channel status flag to occupied. The "receiver" processor clears the flag when the message is treated and the response is available in shared memory.
• Full-duplex communication mode:
  • The subchannels are used in Asynchronous mode.
  • Any processor can post asynchronously a message by setting the subchannel status flag to occupied. The "receiver" processor clears the flag when the message is treated. This mode can be considered as a combination of two simplex modes on a given channel.

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

24. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

24.1. Processor interface assignment

24.1.1. On STM32MP15x lines 

STMicroelectronics distribution uses the IPCC peripheral for inter-processor communication with the following configuration:

• The IPCC processor 1 interface (PROC1)is assigned to the Arm^® Cortex^®-A7, non-secure context.
• The IPCC processor 2 interface (PROC2) is assigned to the Arm^® Cortex^®-M4 context.

24.1.2. On STM32MP25x lines 

• The IPCC1 peripheral is dedicated for the communication between the Arm^® Cortex^®-A35 and the Arm^® Cortex^®-M33. The interfaces are assigned in hardware to the Cortexes :
  • The processor 1 interface (PROC1) is assigned by hardware to the Arm^® Cortex^®-A35, secure and non-secure context.
  • The processor 2 interface (PROC2) is assigned by hardware to the Arm^® Cortex^®-M33, secure and non-secure context.

• The IPCC2 peripheral is dedicated for the communication between the Arm^® Cortex^®-A35 or the Arm^® Cortex^®-M33 and the Arm^® Cortex^®-M0+.
  • The processor 1 interface (PROC1) is assigned by hardware to the Arm^® Cortex^®-M0+.
  • The processor 2 interface (PROC2) is assignable to the Arm^® Cortex^®-A35 or the Arm^® Cortex^®-M33, secure and non-secure context.

24.2. Boot time assignment

24.2.1. On STM32MP15x lines 

The IPCC peripheral is not used at boot time.

24.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

• ☐ 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.
• ⬚ 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.
• ✓ 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 STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Coprocessor	IPCC	IPCC1		⬚	⬚	Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature
		IPCC2		⬚	⬚	Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature

The below table shows the possible boot time allocations for the features of the IPCC1 instance.

Feature	Boot time allocation			Comment
	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
PROC1 channel 1		⬚	⬚
PROC1 channel 2		⬚	⬚
PROC1 channel 3		⬚	⬚
PROC1 channel 4		⬚	⬚
PROC1 channel 5		⬚	⬚
PROC1 channel 6		⬚	⬚
PROC1 channel 7		⬚	⬚
PROC1 channel 8		⬚	⬚
PROC1 channel 9		⬚	⬚
PROC1 channel 10		⬚	⬚
PROC1 channel 11		⬚	⬚
PROC1 channel 12		⬚	⬚
PROC1 channel 13		⬚	⬚
PROC1 channel 14		⬚	⬚
PROC1 channel 15		⬚	⬚
PROC1 channel 16		⬚	⬚
PROC2 channel 1
PROC2 channel 2
PROC2 channel 3
PROC2 channel 4
PROC2 channel 5
PROC2 channel 6
PROC2 channel 7
PROC2 channel 8
PROC2 channel 9
PROC2 channel 10
PROC2 channel 11
PROC2 channel 12
PROC2 channel 13
PROC2 channel 14
PROC2 channel 15
PROC2 channel 16

The below table shows the possible boot time allocations for the features of the IPCC2 instance.

Feature	Boot time allocation			Comment
	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
PROC1 channel 1
PROC1 channel 2
PROC1 channel 3
PROC1 channel 4
PROC2 channel 1		⬚	⬚
PROC2 channel 2		⬚	⬚
PROC2 channel 3		⬚	⬚
PROC2 channel 4		⬚	⬚

24.3. Runtime assignment

It does not make sense to allocate the IPCC to a single runtime execution context. It is consequently enabled by default for both cores in the STM32CubeMX.

24.3.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Coprocessor	IPCC	IPCC		☑	☑	Shared (none or both)

Processor interface	Context		Comment
	Cortex-A7 non-secure (Linux)	Cortex-M4 (STM32Cube)
PROC1 channel 1	☑		RPMsg transfer from Cortex-M to Cortex-A Full-duplex communication: The Cortex-M core uses this channel to indicate that a message is available The Cortex-A core uses this channel to indicate that the message is treated
PROC1 channel 2	☑		RPMsg transfer from Cortex-A to Cortex-M Full-duplex communication: The Cortex-A core uses this channel to indicate that a message is available The Cortex-M core uses this channel to indicate that the message is treated
PROC1 channel 3	☑		Simplex communication used by the remote framework to request the Cortex-M4 to shutdown.
PROC1 channel 4	☐
PROC1 channel 5	☐
PROC1 channel 6	☐
PROC2 channel 1		☑	RPMsg transfer from Cortex-M to Cortex-A Full-duplex communication: The Cortex-M core uses this channel to indicate that a message is available The Cortex-A core uses this channel to indicate that the message is treated
PROC2 channel 2		☑	RPMsg transfer from Cortex-A to Cortex-M Full-duplex communication: The Cortex-A core uses this channel to indicate that a message is available The Cortex-M core uses this channel to indicate that the message is treated
PROC2 channel 3		☑	Simplex communication used by the remote framework to request the Cortex-M4 to shutdown.
PROC2 channel 4		☐
PROC2 channel 5		☐
PROC2 channel 6		☐

24.3.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Coprocessor	IPCC	IPCC1	☐OP-TEE	☐	☐	☐		Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature
		IPCC2	☐OP-TEE	☐	☐	☐	☐	Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature

The below table shows the possible runtime allocations for the features of the IPCC1 instance.

Feature	Runtime allocation					Comment
	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
PROC1 channel 1	☐OP-TEE	☑				RPMsg transfer from Cortex-M to Cortex-A Full-duplex communication: The Cortex-M core uses this channel to indicate that a message is available The Cortex-A core uses this channel to indicate that the message is treated
PROC1 channel 2	☐OP-TEE	☑				RPMsg transfer from Cortex-A to Cortex-M Full-duplex communication: The Cortex-A core uses this channel to indicate that a message is available The Cortex-M core uses this channel to indicate that the message is treated
PROC1 channel 3	☐OP-TEE	☑				Simplex communication used by the remoteproc framework to request the Cortex-M33 to shutdown.
PROC1 channel 4	☐OP-TEE	☐
PROC1 channel 5	☐OP-TEE	☐
PROC1 channel 6	☐OP-TEE	☐
PROC1 channel 7	☐OP-TEE	☐
PROC1 channel 8	☐OP-TEE	☐
PROC1 channel 9	☐OP-TEE	☐
PROC1 channel 10	☐OP-TEE	☐
PROC1 channel 11	☐OP-TEE	☐
PROC1 channel 12	☐OP-TEE	☐
PROC1 channel 13	☐OP-TEE	☐				Allocated to secure world but not used.
PROC1 channel 14	☐OP-TEE	☐				Allocated to secure world but not used.
PROC1 channel 15	☐OP-TEE	☐				Allocated to secure world but not used.
PROC1 channel 16	☐OP-TEE	☐				Allocated to secure world but not used.
PROC2 channel 1			☐	☑		RPMsg transfer from Cortex-M to Cortex-A Full-duplex communication: The Cortex-M core uses this channel to indicate that a message is available The Cortex-A core uses this channel to indicate that the message is treated
PROC2 channel 2			☐	☑		RPMsg transfer from Cortex-A to Cortex-M Full-duplex communication: The Cortex-A core uses this channel to indicate that a message is available The Cortex-M core uses this channel to indicate that the message is treated
PROC2 channel 3			☐	☑		Simplex communication used by the remoteproc framework to request the Cortex-M33 to shutdown.
PROC2 channel 4			☐	☐
PROC2 channel 5			☐	☐
PROC2 channel 6			☐	☐
PROC2 channel 7			☐	☐
PROC2 channel 8			☐	☐
PROC2 channel 9			☐	☐
PROC2 channel 10			☐	☐
PROC2 channel 11			☐	☐
PROC2 channel 12			☐	☐
PROC2 channel 13			☐	☐
PROC2 channel 14			☐	☐
PROC2 channel 15			☐	☐
PROC2 channel 16			☐	☐

The below table shows the possible runtime allocations for the features of the IPCC2 instance.

Feature	Runtime allocation					Comment
	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
PROC1 channel 1					☐
PROC1 channel 2					☐
PROC1 channel 3					☐
PROC1 channel 4					☐
PROC2 channel 1	☐OP-TEE	☐	☐	☐
PROC2 channel 2	☐OP-TEE	☐	☐	☐
PROC2 channel 3	☐OP-TEE	☐	☐	☐
PROC2 channel 4	☐OP-TEE	☐	☐	☐

25. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the IPCC peripheral for the embedded software components listed in the above tables.

• Linux^®: mailbox framework
• STM32Cube: IPCC HAL driver and header file of IPCC HAL module

26. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.The IPCC peripheral is shared between the Arm Cortex-A and Cortex-M contexts. A particular attention must therefore be paid to have a complementary configuration on both contexts.

Applicable for

STM32MP15x lines

---

27. Article purpose

The purpose of this article is to:

• briefly introduce the HSEM peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

28. Peripheral overview

The HSEM (hardware spinlock) peripheral is used to provide synchronization and mutual exclusion between heterogeneous processors.

• 32 hardware semaphores are available on the platform.
• semaphores could be accessed by the Arm^® Cortex^®-A7 core and the Arm^® Cortex^®-M4

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.

29. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

29.1. Boot time assignment

29.1.1. On STM32MP15x lines 

The hardware semaphore is used at boot time for GPIO access protection between the Arm^® Cortex^®-A7 and Cortex^®-M4 cores. See Protecting GPIO and EXTI system resources by hardware semaphores for details.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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)
Coprocessor	HSEM	HSEM			☐

29.2. Runtime assignment

29.2.1. On STM32MP15x lines 

It does not make sense to allocate HSEM to a single runtime execution context, that is why it is enabled by default for both cores in the STM32CubeMX.

The hardware semaphore is used at runtime for GPIO and EXTI access protection between the Arm^® Cortex^®-A7 and Cortex^®-M4 cores. See Protecting GPIO and EXTI system resources by hardware semaphores for details.

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Coprocessor	HSEM	HSEM	⬚	☑	☑

30. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the HSEM peripheral for the embedded software components listed in the above tables.

• Linux^®: hardware spinlock framework
• STM32Cube: HSEM HAL driver and header file of HSEM HAL module

31. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

The HSEM peripheral is shared between the Cortex-A and Cortex-M contexts, so a particular attention must be paid to have a complementary configuration on both contexts.

STM32MP15 RTC internal peripheral

STM32MP15 SYSCFG internal peripheral

Warning

Concerning the STM32MP25x lines , only the boot time assignment table and the runtime assignment table have been updated. The other chapters have not been updated yet.

32. Article purpose

The purpose of this article is to:

• briefly introduce the NVIC peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

33. Peripheral overview

The NVIC peripheral is the Arm^® Cortex^®-M4 and Arm^® Cortex^®-M33 interrupt controller. As a result, it cannot be accessed by the Arm Cortex-A7 core or Arm Cortex-A35 core.

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

34. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

34.1. Boot time assignment

The NVIC peripheral is not used at boot time.

34.2. Runtime assignment

34.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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/Interrupts	NVIC	NVIC			✓

34.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Core/Interrupts	NVIC	NVIC CM33			✓	✓
		NVIC CM0+					✓

35. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the NVIC peripheral for the embedded software components listed in the above tables.

• STM32Cube: CORTEX HAL driver and header file of CORTEX HAL module for STM32MP15x lines 

36. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

37. Article purpose

The purpose of this article is to:

• briefly introduce the MCU SRAM internal memory peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

38. Peripheral overview

The MCU SRAM peripheral is 384-Kbyte wide and physically near to the Cortex^®-M4 for optimized performances from this core. It is split into four separate banks:

• MCU SRAM1 (128 Kbytes)
• MCU SRAM2 (128 Kbytes)
• MCU SRAM3 (64 Kbytes)
• MCU SRAM4 (64 Kbytes)

Those banks have individual security control (see security support in the runtime assignment table below) and automatic clock gating (for power management optimization), but they are not supplied when the system goes to Standby low power mode, so their content is lost in that case.

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.

39. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

39.1. Boot time assignment

39.1.1. On STM32MP15x lines 

The ROM code uses the MCU SRAM1 to store the USB context during a boot on USB for Flash programming (with STM32CubeProgrammer).

Linux remoteproc framework (running on the Cortex^®-A7) loads the Cortex^®-M4 firmware code into the MCU SRAM, except the exception table that must be loaded in the RETRAM since the Cortex^®-M4 is looking for its reset entry point at address 0x00000000. The overall memory mapping is shown in the platform memory mapping section.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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/RAM	MCU SRAM	Any instance	✓	☑	☐

39.2. Runtime assignment

39.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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/RAM	MCU SRAM	SRAM1	☐	☐	☐	Assignment (between A7 S and A7 NS / M4) Shareable (between A7 NS and M4)
		SRAM2	☐	☐	☐	Assignment (between A7 S and A7 NS / M4) Shareable (between A7 NS and M4)
		SRAM3	☐	☐	☐	Assignment (between A7 S and A7 NS / M4) Shareable (between A7 NS and M4)
		SRAM4	☐	☐	☐	Assignment (between A7 S and A7 NS / M4) Shareable (between A7 NS and M4)

40. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the XXX peripheral for the embedded software components listed in the above tables.

• Linux^®: reserved memory, that is used by the dmaengine (for DMA buffers management) or RPMsg for interprocess communication with the coprocessor
• OP-TEE: OP-TEE
• STM32Cube: STM32Cube

Notice the and/or allocation between Cortex^®-A7 non-secure and Cortex^®-M4, meaning that it is possible to share banks between those cores, typically to realize inter process communication between RPMsg on Linux side and OpenAMP on STM32Cube side.

The default assignement set in STMicroelectronics distribution is in line with the platform memory mapping, that can be adapted by the platform user.

41. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

The several SRAM banks are accessible via different address ranges in order to benefit from the Cortex-M4 multiple ports.

42. Article purpose

The purpose of this article is to:

• briefly introduce the RETRAM internal memory peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

43. Peripheral overview

The RETRAM internal memory is located in the VSW power domain, allowing it to be supplied during Standby low power mode, and to retain retention firmware or data in Standby mode.

43.1. STM32MP15x lines 

On STM32MP15x lines , the RETRAM internal memory is 64 Kbytes wide and is physically near to the Arm^® Cortex^®-M4 for optimized performance from the core and to execute very quickly by the Cortex-M4 on wake up from Standby mode.

The Cortex-M4 firmware has to be loaded to the RETRAM , starting at address 0x00000000. At least, it must load the part of the firmware containing the vector table, since the Arm^® Cortex^®-M4 reset entry point is address 0x00000004. The rest of the firmware code is loaded into the MCU SRAM. The overall memory mapping is shown in the platform memory mapping section.

While going to Standby low power mode, the RETRAM can remain supplied, so it can preserve a (small) Arm^® Cortex^®-M4 piece of retention firmware that is executed on wake up when the ROM code (running on Arm^® Cortex^®-A7) restarts the Arm^® Cortex^®-M4.

43.2. STM32MP2 series

On STM32MP2 series, the RETRAM internal memory is 128 Kbytes wide and mainly dedicated to the Arm^® Cortex^®-M33 for autonomous wakeup from low power Standby mode.
The Cortex-M33 firmware with low power functions has to be loaded to the "RETRAM" with associated reference CRC by the main processor (TDCID) following the procedure described in the SRAM configuration controller (RAMCFG) chapter of STM32MP25 reference manuals.
On Standby exit, in case of wake up event assigned to Arm^® Cortex^®-M33, the SoC will verify the RETRAM integrity thanks to associated HW ECC and then the Cortex-M33 firmware integrity by checking CRC. In case of success, the SoC will start Cortex-M33 at start address of the RETRAM. Else an error will be generated and sent to main processor or a system reset generated according to system configuration.
Moreover RETRAM is protected by a RISAB memory firewall which allows to define some memory regions with different access rights with a 4kB granularity. Each region can be assigned to the different execution contexts of the plateform.

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

44. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

44.1. Boot time assignment

44.1.1. On STM32MP15x lines 

At boot time, The RETRAM internal memory can contain the Arm^® Cortex^®-M4 firmware, but could also be dedicated to some other usages.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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/RAM	RETRAM	RETRAM			☐

44.1.2. On STM32MP2 series

At boot time, The RETRAM internal memory can contain the Arm^® Cortex^®-M33 firmware, but could also be dedicated to some other usages. Arm^® Cortex^®-A35 FSBL (TF-A BL2) uses the end of RETRAM to store DDR parameters to be restored on low power mode exit.

Click on to expand or collapse the legend...

• ☐ 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.
• ⬚ 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.
• ✓ 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 STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Core/RAM	RETRAM	RETRAM		☑		DDR parameters are stored in RETRAM by TF-A BL2.

44.2. Runtime assignment

44.2.1. On STM32MP15x lines 

At runtime the RETRAM can be allocated to:

• the Arm^® Cortex^®-M4 (default) for use with the STM32Cube MPU Package, either for runtime firmware that can be mapped in both RETRAM and MCU SRAM, or for retention firmware that only fits into the RETRAM ,

or

• the Arm^® Cortex^®-A7 secure to be used under OP-TEE,

or

• the Arm^® Cortex^®-A7 non-secure to be used under Linux as reserved memory.

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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/RAM	RETRAM	RETRAM	⬚	⬚	☑	Assignment to the Arm® Cortex®-M4 if used

44.2.2. On STM32MP25x lines 

At runtime the RETRAM can be allocated to different contexts thanks to RISAB5 memory firewall:

• the Arm Arm^® Cortex^®-M33 secure for use with TF-M for mainly low power functions that allows Arm^® Cortex^®-M33 to exit from low power Standby mode by itself.
• the Arm^® Cortex^®-M33 non-secure for use with the STM32Cube MPU Package. Could be used in combination with other memories like SRAM or DDR
• the Arm^® Cortex^®-A35 secure to be used under OP-TEE,
• the Arm^® Cortex^®-A35 secure to be used under TF-A BL31
• the Arm^® Cortex^®-A35 non-secure to be used under Linux as reserved memory,

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Core/RAM	RETRAM	RETRAM	☐OP-TEE ☐TF-A BL31	⬚	☑	☐

45. Software frameworks and drivers

The RETRAM is the minimum (and default) memory for the Arm^® Cortex^®-M4 firmware.The software frameworks and component managing the RETRAM device to host the Arm^® Cortex^®-M4 firmware are listed below.

• Linux^®: Linux reserved memory and Linux remoteproc framework
• OP-TEE: OP-TEE remoteproc source code
• STM32Cube: STM32CubeMP15 Package and STM32CubeMP2 Package
• TF-M:TF-M overview

46. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

47. Article purpose

The purpose of this article is to:

• briefly introduce the WWDG peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

48. Peripheral overview

The WWDG peripheral is a watchdog unit that can be used to protect the Cortex^®-M based coprocessor firmware from endless loops or to monitor some real-time activities. This peripheral is clocked by the bus on which it is connected, thus it is frozen as soon as the system goes to Stop or Standby low power mode (except if the Stop emulation mode is enabled via DBGSTOP bit in DBGMCU_CR register). This block has an early interrupt feature that allows to get an interrupt (on GIC or NVIC) one cycle before reaching the final reset: this can allow to trigger a recovery mechanism on Cortex^®-M or on Cortex^®-A.
On WWDG expiration, a MCU reset is generated, reseting Cortex^®-M sub-system and the WWDG itself. This MCU reset also generates an interrupt on GIC thanks to EXTI. This allows Cortex^®-A to detect Cortex^®-M crashed and to recover it by stopping associated services, reloading Cortex^®-M firmware and restarting Cortex^®-M.

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

49. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

49.1. Boot time assignment

The WWDG peripheral is not used at boot time.

49.2. Runtime assignment

49.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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/Watchdog	WWDG	WWDG			☐

49.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Core/Watchdog	WWDG	WWDG1			⬚	☐
		WWDG2					☐

50. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the WWDG peripheral for the embedded software components listed in the above tables.

As there is only one WWDG counter cycle between the WWDG early interrupt and the WWDG reset generation, ST preconizes to allocate the WWDG early interrupt to Cortex^®-M for a better reactivity and not to Cortex^®-A.

• STM32Cube: WWDG HAL driver and header file of WWDG HAL module

51. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

52. Article purpose

The purpose of this article is to:

• briefly introduce the PWR peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

53. Peripheral overview

The PWR peripheral is used to control the device power supply configuration.

It has 6 input pins (named wakeup pins) which can be programmed to wake the system up from low power. The wakeup pins are listed with WKUP prefix in the STM32MP15 Datasheet.

These pins can be used by the Cortex^®-A7 non secure (via Cortex^®-A7 secure services) or the Cortex^®-M4.

The PWR peripheral provides 2 output hardware lines named PWR_ON and PWR_LP:

• In STPMIC1 configuration, PWR_ON allows to select the register bank (active or low power). PWR_LP is not used.
• In the power discrete solution they drive VDDcore which feeds the Cortex^®-A7, the Cortex^®-M4 and the peripherals. They also control the DDR power supplies (VDD_DDR, VREF_DDR, VTT_DDR).

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.

54. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

54.1. Boot time assignment

54.1.1. On STM32MP15x lines 

The PWR is closely configured together with RCC by all the boot components: the ROM code, the FSBL, the SSBL and up to Linux^® kernel. Its configuration is carried by the device tree.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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)
Power & Thermal	PWR	PWR	✓	✓	✓

54.2. Runtime assignment

54.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Power & Thermal	PWR	PWR	✓	✓	✓

55. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the PWR peripheral for the embedded software components listed in the above tables.

• Linux^®: power management, regulator framework and interrupt framework
• OP-TEE:
  • core/arch/arm/plat-stm32mp1/drivers/stm32mp1_pwr.c
  • core/arch/arm/plat-stm32mp1/drivers/stm32mp1_pwr_irq.c
• U-Boot: arch/arm/mach-stm32mp/stm32mp1/pwr_regulator.c
• STM32Cube: PWR HAL driver

56. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned:

• pwr_irq irqchip in Linux
• Power overview

57. How to go further

The PWR is interfaced with the hardware debug port (HDP) of the STM32MP15. This link offers the flexibility to observe the main PWR state signals on debug pins.

Please refer to STM32MP15 reference manuals for the exact list of signals that can be monitored.

STM32MP15 RCC internal peripheral

STM32MP15 ETZPC internal peripheral STM32MP15 HASH internal peripheral STM32MP15 RNG internal peripheral

STM32MP15 TAMP internal peripheral

ETM internal peripheral STM internal peripheral

Applicable for

STM32MP15x lines

---

58. Article purpose

The purpose of this article is to:

• briefly introduce the CEC peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

59. Peripheral overview

The CEC (consumer electronics control) or HDMI-CEC peripheral is used to receive/send messages from/to devices, such as TV or tuner, through a HDMI cable.

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.

Refer to the STM32 CEC presentation for an overview of the CEC hardware block capabilities.

60. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

60.1. Boot time assignment

The CEC peripheral is not used at boot time.

60.2. Runtime assignment

60.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Visual	CEC	CEC		☐	☐	Assignment (single choice)

61. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the CEC peripheral for the embedded software components listed in the above tables.

• Linux^®: CEC framework
• STM32Cube: STM32Cube CEC HAL driver and header file of CEC HAL module

62. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

See also additional information in the CEC device tree configuration article for Linux^®.

63. How to go further

Refer to the STM32 CEC application note (AN4066) for a detailed description of the CEC peripheral and applicable use-cases.

Even if this application note is related to STM32 microcontrollers, it also applies to STM32 MPUs.

65. Article purpose

The purpose of this article is to:

• briefly introduce the DCMI peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

66. Peripheral overview

The DCMI (digital camera memory interface) peripheral is used to receive some video data from an external parallel camera sensor device or any other digital video equipment supporting parallel interface.

The DCMI hardware block can receive raw data frames in RGB565 and YUV422 formats as well as JPEG compressed data.

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

Refer to STM32 DCMI presentation for an overview of DCMI hardware block and its capabilities.

67. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

67.1. Boot time assignment

67.1.1. On STM32MP1 series

The DCMI peripheral is not used at boot time.

67.1.2. On STM32MP2 series

Click on to expand or collapse the legend...

• ☐ 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.
• ⬚ 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.
• ✓ 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 STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Visual	DCMI	DCMI			⬚

67.2. Runtime assignment

67.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Visual	DCMI	DCMI		☑	☐	Assignment (single choice)

67.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Visual	DCMI	DCMI	⬚OP-TEE	☑	⬚	☐

68. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the DCMI peripheral for the embedded software components listed in the above tables.

• Linux^®: V4L2 framework
• STM32Cube:
  • for STM32MP15x lines : DCMI HAL driver and header file of DCMI HAL module
  • for STM32MP25x lines : DCMI HAL driver and header file of DCMI HAL module

69. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

See also additional information in the DCMI device tree configuration article for Linux^®.

70. How to go further

Refer to STM32 DCMI Application Note (AN5020) for a detailed description of the DCMI peripheral and applicable use-cases.

This application note is related to STM32 microcontrollers but it is also applicable to STM32 MPUs. This document can help to better understand stm32-dcmi V4L2 kernel driver and debug camera sensor and DCMI interactions.

72. Article purpose

The purpose of this article is to:

• briefly introduce the DSI peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

73. Peripheral overview

The DSI peripheral implements all the protocol functions defined in the MIPI^® Display Serial Interface (MIPI^® DSI) specification. It provides an interface to communicate with a DSI-compliant display. The MIPI^® DSI is part of a group of communication protocols defined by the MIPI^® Alliance .

On STM32MP15x lines , the DSI peripheral:

• supports up to 2 D-PHY data lanes.

On STM32MP25x lines , the DSI peripheral:

• supports up to 4 D-PHY data lanes.
• supports the RIF security architecture: The RISUP differentiates the access right of accesses performed toward the following RIF protected peripheral ID:
  • "DSI common": DSI common registers for DSI-wrapper and DSI-Host
  • "DSI_TRIG": DSI Wrapper trigger-A to update a smart panel
  • "DSI_RD": DSI-Host read access to a smart panel

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

74. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

Even if some MIPI DSI modes are supported by the DSI internal peripheral, in practice:

• software frameworks like U-Boot or Linux^® kernel do not support all the possible modes.
• hardware integration constraints such as support for all the clock values or the pll configurations make it difficult to use all possible modes.

Select a MIPI DSI panel or bridge supporting the DSI video burst mode because this mode is supported by all software frameworks and is easier to fine tune. Please consider the following recommendations when selecting a MIPI DSI panel or bridge for your project:

• Pixel data transmission
  • in DSI command mode: not supported by neither U-Boot nor Linux^® kernel, use instead the DSI video burst mode.
  • in DSI video mode:
    • burst mode: supported
    • non-burst mode with sync events or pulses: supported with clock constraints to be considered .

• Command transmission (initialization sequence, backlight...)
  • in DSI command mode: supported
  • in DSI video mode:
    • burst mode: supported if there is enough time to send commands before or/and after pixel data .
    • non-burst mode with sync events or pulses: supported but there are timing constraints to be considered .

If non-burst mode has to be used for a specific MIPI DSI panel or bridge, check non-burst mode constraints.

74.1. Boot time assignment

74.1.1. On STM32MP15x lines 

The DSI is used at boot time for displaying a splash screen through the U-Boot framework.

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.
• ☑ 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.
• ⬚ 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.
• ✓ 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)
Visual	DSI	DSI			☐

74.1.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

• ☐ 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.
• ⬚ 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.
• ✓ 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 STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Visual	DSI	DSI	☐	☐	☐	Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature

The below table shows the possible boot time allocations for the features of the DSI instance.

Feature	Boot time allocation			Comment
	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
CMN			☑
RDFIFO			☑
TRIG			☑

74.2. Runtime assignment

74.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Visual	DSI	DSI		☐

74.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Visual	DSI	DSI	☐OP-TEE	☐	☐	☐	☐	Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature

The below table shows the possible runtime allocations for the features of the DSI instance.

Feature	Runtime allocation					Comment
	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
CMN	⬚OP-TEE	☑	⬚	☐
RDFIFO	⬚OP-TEE	☑	⬚	☐
TRIG	⬚OP-TEE	☑	⬚	☐

75. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the DSI peripheral for the embedded software components listed in the above tables.

• Linux^®: DRM/KMS framework
• U-Boot: U-Boot framework (for the display splash screen)
• STM32Cube: DSI HAL driver and header file of DSI HAL module

76. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

See also additional information in the DSI device tree configuration article for Linux^®.

77. How to go further

Refer to the STM32 DSI application note (AN4860) for a detailed description of the DSI peripheral and applicable use-cases.

Even if this application note is related to STM32 microcontrollers, it also applies to STM32 MPUs.

77.1. Non-burst mode constraints

In MIPI^® DSI video burst mode, the setting for the DSI peripheral's PLL is quite relaxed. The DSI peripheral can send out pixel data in bursts, at rate higher that the pixel clock frequency. The consumer of the pixel data (the MIPI DSI display panel or bridge) will internally re-sample such data to the correct clock frequency. This makes easy to configure the DSI in video burst mode.

In MIPI^® DSI video non-burst mode, instead, the DSI peripheral must send out the pixel data at the exact pixel clock frequency required by the MIPI DSI display panel or bridge. But, the set of pixel clock frequencies allowed by the DSI peripheral is limited by:

• the input frequency of the DSI peripheral's PLL (linked to the HSE oscillator on STM32MP15x lines  or to a flexgen clock on STM32MP25x lines );
• the programmability of the DSI peripheral's PLL;
• the min and max frequency of the VCO of the DSI peripheral's PLL;
• the selected bit per pixel.

77.1.1. On STM32MP15x lines 

The following script dumps all the possible pixel clock frequencies allowed, that can be checked against the pixel clock frequency required by the MIPI DSI panel or bridge.

1. !/bin/bash

hse=24000000 vcomin=1000000000 vcomax=2000000000 n_lanes=2

1. 24 bpp

byte_per_pixel=3

for i in {1..7}; do

  for n in {10..125}; do
    vco=$(($hse*2*$n/$i))
    if [ $vco -lt $vcomin -o $vco -gt $vcomax ]; then
      continue
    fi
    for o in 1 2 4 8; do
      hs_clk=$(($hse*$n/($i*$o)))
      echo $(($hs_clk*$n_lanes/(8*$byte_per_pixel)))
    done
  done

done | sort -nu

If the required frequency is not listed, you can either:

• check the spec or contact the vendor of the MIPI DSI panel or bridge to identify other pixel clock frequencies allowed;
• consider using a different frequency for the HSE oscillator.

It is possible to change the value of the variables in the script to dump the pixel clock frequencies for different HSE oscillators. Please also check in ROM code overview the values of HSE oscillator's frequency accepted by the BootROM. By changing the HSE oscillator, the Clock device tree configuration in TF-A and OP-Tee device tree must be aligned too.

77.1.2. On STM32MP25x lines 

The DSI internal peripheral and related clock programmability on STM32MP25x lines  is good enough for supporting the MIPI^® DSI video non-burst mode without modifying the HSE clock frequency.

78. References

Applicable for

STM32MP15x lines, STM32MP25x lines

---

79. Article purpose

The purpose of this article is to:

• briefly introduce the GPU peripheral and its main features,
• indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
• list the software frameworks and drivers managing the peripheral,
• explain how to configure the peripheral.

80. Peripheral overview

The GPU peripheral is a dedicated graphics processing unit. It accelerates numerous 3D graphics applications such as graphical user interface (GUI), menu display or animations. It works together with an optimized software stack designed for industry-standard APIs and supporting Android^TM and Linux^® embedded development platforms (read the STM32 MPU reference manual for more details).

80.1. On STM32MP15x lines 

The GPU peripheral main API supports are:

• OpenGL^® ES 1.1 and 2.0
• OpenVG^® 1.1
• EGL^™ 1.4

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

80.2. On STM32MP25x lines 

The GPU peripheral provides a powerful hardware acceleration means for all modern Graphic, but also Neural, and general parallel computing applications.

Main API are the same as on STM32MP15x lines , with the following extra ones:

• OpenGL^® ES 3.2.8 (backward compatible: OpenGL^® ES 2.1 & OpenGL^® ES 1.1)
• Vulkan 1.3
• OpenVG^® 1.3
• OpenCL^® 3.0
• OpenVX^® 1.3

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

81. Peripheral usage

This chapter is applicable in the scope of the OpenSTLinux BSP running on the Arm^® Cortex^®-A processor(s), and the STM32CubeMPU Package running on the Arm^® Cortex^®-M processor.

81.1. Boot time assignment

81.1.1. On STM32MP1 series

The GPU peripheral is not used at boot time.

81.1.2. On STM32MP2 series

Click on to expand or collapse the legend...

• ☐ 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.
• ⬚ 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.
• ✓ 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 STM32MP25 reference manuals.

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Visual	GPU	GPU			⬚

81.2. Runtime assignment

81.2.1. On STM32MP15x lines 

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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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)
Visual	GPU	GPU		☐

81.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 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.
• ☑ 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.
• ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in 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 STM32MP25 reference manuals.

Domain	Peripheral	Runtime allocation						Comment
		Instance	Cortex-A35 secure (OP-TEE / TF-A BL31)	Cortex-A35 non-secure (Linux)	Cortex-M33 secure (TF-M)	Cortex-M33 non-secure (STM32Cube)	Cortex-M0+ (STM32Cube)
Visual	GPU	GPU	⬚OP-TEE	☑	⬚	⬚

82. Software frameworks and drivers

Below are listed the software frameworks and drivers managing the GPU peripheral for the embedded software components listed in the above tables.

• Linux^®: OpenGL^® ES framework

Add a link to "GPU framework overview" article when available.

83. How to assign and configure the peripheral

The peripheral assignment can be done via the STM32CubeMX graphical tool (and manually completed if needed).
This tool also helps to configure the peripheral:

• partial device trees (pin control and clock tree) generation for the OpenSTLinux software components,
• HAL initialization code generation for the STM32CubeMPU Package.

The configuration is applied by the firmware running in the context in which the peripheral is assigned.

See also additional information in the GPU device tree configuration article for Linux^®.

84. How to go further

Please go through the articles belonging to the GPU category.

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

Cortex^®

Operating system

Analog-to-digital converter. The process of converting a sampled analog signal to a digital code that represents the amplitude of the original signal sample.

Central processing unit

Direct memory access

Voltage reference buffer (STM32 specific)

Low-power timer (STM32 specific)

External interrupt

Board support package

Second stage boot loader

Open portable trusted execution environment

Linux^® is a registered trademark of Linus Torvalds.

Read only memory

Trusted firmware for Arm^® Cortex^®-A

Boot loader stage 2

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

Hardware abstraction layer

Digital-to-analog converter (Electronic circuit that converts a binary number into a continuously varying value.)

Low speed internal oscillator (STM32 clock source)

Reset and clock control

Inter-processor communication controller

Receive

Transmit

Resource Isolation Framework

Hardware semaphore

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.)

Nested vectored interrupt controller

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.)

Flash memory shortened to gain space in titles, tables and block diagrams

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.)

Cyclic redundancy check calculation unit

Trusted Domain Compartment IDentifier - NEW

Elliptic curve cryptography

Error correction capability

First stage boot loader

Doubledata rate (memory domain)

Low power (MIPI^® Alliance DSI standard)

Consumer electronics control (HDMI standard)

High-definition multimedia interface (HDMI standard)

Digital Camera memory interface

Video 4 Linux^® version 2

Display serial interface (MIPI^® Alliance standard)

Mobile Industry Processor Interface, open membership organization that includes leading companies in the mobile industry that share the objective of defining and promoting open specifications for interfaces inside mobile terminals, see MIPI^® Alliance standard web site https://www.mipi.org

Physical layer protocol

Resource Isolation Slave Unit for Peripherals - NEW

High speed external oscillator (STM32 clock source)

Graphics processing units

Graphical user interface

Microprocessor unit

Application programming interface

Open graphics library (see http://www.opengl.org/ for more details)

Open vector graphics (see http://www.khronos.org/openvg/ for more details)

Khronos native platform graphics interface (See http://www.khronos.org/egl/ for more details)

Open computing language (See http://www.opencl.org/ for more details)