STM32MP15 peripherals overview

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

Internal peripherals assignment table template

| rowspan="1" | Analog
| rowspan="1" | ADC
| ADC
| 
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Analog
| rowspan="1" | DAC
| DAC
| 
| ☐
| ☐
| Assignment (single choice)
|-

STM32MP15 DFSDM internal peripheral

| rowspan="1" | Analog
| rowspan="1" | VREFBUF
| VREFBUF
| 
| ☐
|
| Assignment (single choice)
|-

| rowspan="4" | Audio
| rowspan="4" | SAI
| SAI1
| 
| ☐
| ☐
| Assignment (single choice)
|-
| SAI2
| 
| ☐
| ☐
| Assignment (single choice)
|-
| SAI3
| 
| ☐
| ☐
| Assignment (single choice)
|-
| SAI4
| 
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Audio
| rowspan="1" | SPDIFRX
| SPDIFRX
| 
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Coprocessor
| rowspan="1" | IPCC
| IPCC
|
| ☑
| ☑
| Shared (none or both)
|-

| rowspan="1" | Coprocessor
| rowspan="1" | HSEM
| HSEM
| ✓
| ✓
| ✓
| 
|-

| rowspan="1" | Core
| rowspan="1" | RTC
| RTC
| ✓
| ✓
|
| RTC is mandatory to resynchronize  STGEN after exiting  low-power modes.
|-

3. Article purpose

The purpose of this article is to:

• briefly introduce the STGEN peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how it can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the STGEN peripheral.

4. Peripheral overview

The STGEN peripheral provides the reference clock used by the Arm^® Cortex^®-A7 generic timer for its counters, including the system tick generation.

It is clocked by ACLK (the AXI bus clock), so caution is needed when this clock is changed; otherwise the operating system (running on the Cortex-A7) might run with a varying reference clock.

4.1. Features

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

4.2. Security support

The STGEN is a single-instance peripheral that can be accessed via the two following register sets:

• STGENC for the control. That is, a secure port (under ETZPC control).
• STGENR for the read-only access. That is, a non secure port.

5. Peripheral usage and associated software

5.1. Boot time

The STGEN is first initialized by the ROM code, then updated by the FSBL (see Boot chain overview) once the clock tree is set up.

5.2. Runtime

5.2.1. Overview

Linux^® and OP-TEE use the Arm Cortex-A7 generic timer that gets its counter from the STGEN, but this is transparent at run time.

Hence there is no runtime allocation decision for this peripheral: both contexts are selected by default.

5.2.2. Software frameworks

5.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Core	STGEN	see comment	see comment	Not applicable as the STGEN peripheral is configured at boot time and not accessed at runtime

5.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Core	STGEN	see comment	see comment		Not applicable as the STGEN peripheral is configured at boot time and not accessed at runtime

5.2.4. Peripheral assignment

5.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Core	STGEN	STGEN	✓	✓

5.2.4.2. On STM32MP15x lines 

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 a runtime 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	STGEN	STGEN	✓	✓

6. References

| rowspan="1" | Core
| rowspan="1" | SYSCFG
| SYSCFG
| 
| ✓
| ✓
|
|-

| rowspan="2" | Core/DMA
| rowspan="2" | DMA
| DMA1
|
| ☐
| ☐
| Assignment (single choice)
|-
| DMA2
|
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Core/DMA
| rowspan="1" | DMAMUX
| DMAMUX
|
| ☐
| ☐
| Shareable (multiple choices supported)
|-

| rowspan="1" | Core/DMA
| rowspan="1" | MDMA
| MDMA
| ☐
| ☐
|
| Shareable (multiple choices supported)
|-

| rowspan="1" | Core/Interrupts
| rowspan="1" | EXTI
| EXTI
|
| ✓
| ✓
| Shared
|-

| rowspan="1" | Core/Interrupts
| rowspan="1" | GIC
| GIC
| ✓
| ✓
|
|
|-

| rowspan="1" | Core/Interrupts
| rowspan="1" | NVIC
| NVIC
| 
|
| ✓
|
|-

| rowspan="2" | Core/IOs
| rowspan="2" | GPIO
| GPIOA-K
|
| ☐
| ☐
| Shareable (with pin granularity)
|-
| GPIOZ
| ☐
| ☐
| ☐
| Shareable (with pin granularity)
|-

| rowspan="1" | Core/RAM
| rowspan="1" | BKPSRAM
| BKPSRAM
| ☐
| ☐
|
| Assignment (single choice)
|-

| rowspan="1" | Core/RAM
| rowspan="1" | DDR via DDRCTRL
| DDR
| ✓
| ✓
|
|
|-

MCU SRAM internal memory

| rowspan="1" | Core/RAM
| rowspan="1" | RETRAM
| RETRAM
| ☐
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Core/RAM
| rowspan="1" | SYSRAM
| SYSRAM
| ☐
| ☐
|
| Shareable (multiple choices supported)
|-

| rowspan="5" | Core/Timers
| rowspan="5" | LPTIM
| LPTIM1
|
| ☐
| ☐
| Assignment (single choice)
|-
| LPTIM2
|
| ☐
| ☐
| Assignment (single choice)
|-
| LPTIM3
|
| ☐
| ☐
| Assignment (single choice)
|-
| LPTIM4
|
| ☐
| ☐
| Assignment (single choice)
|-
| LPTIM5
|
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="14" | Core/Timers
| rowspan="14" | TIM
| TIM1 (APB2 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM2 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM3 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM4 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM5 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM6 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM7 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM8 (APB2 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM12 (APB1 group)
| ☐
| ☐
| ☐
| Assignment (single choice)
TIM12 or TIM15 can be used for HSI/CSI calibration
|-
| TIM13 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM14 (APB1 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM15 (APB2 group)
| ☐
| ☐
| ☐
| Assignment (single choice)
TIM12 or TIM15 can be used for HSI/CSI calibration
|-
| TIM16 (APB2 group)
|
| ☐
| ☐
| Assignment (single choice)
|-
| TIM17 (APB2 group)
|
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="2" | Core/Watchdog
| rowspan="2" | IWDG
| IWDG1
| ☐
|
|
|
|-
| IWDG2
| ☐
| ☐
| 
| Shared (none or both):

• Cortex-A7 non secure for reload
• Cortex-A7 secure for early interrupt handling

|-

| rowspan="1" | Core/Watchdog
| rowspan="1" | WWDG
| WWDG
|
| 
| ☐
| 
|-

| rowspan="1" | High speed interface
| rowspan="1" | OTG (USB OTG)
| OTG (USB OTG)
| 
| ☐
|
|
|-

| rowspan="1" | High speed interface
| rowspan="1" | USBH (USB Host)
| USBH (USB Host)
| 
| ☐
|
|
|-

| rowspan="1" | High speed interface
| rowspan="1" | USBPHYC (USB HS PHY controller)
| USBPHYC (USB HS PHY controller)
| 
| ☐
|
|
|-

7. Article purpose

The purpose of this article is to:

• briefly introduce the I2C peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the I2C peripheral.

8. Peripheral overview

The I2C bus interface serves as an interface between the microcontroller and the serial I2C bus.
It provides multi-master capability, and controls all I2C bus-specific sequencing, protocol, arbitration and timing.
The I2C controller allows to be a slave as well if need be.
It is also SMBus 2.0 compatible.
For more information about I2C please refer to this link: I2C wikipedia or i2c-bus.org
For more information about SMBus please refer to this link: SMBus wikipedia or i2c-bus.org

8.1. Features

Here are the main features:

• Multi-master
• Standard (100 KHz) and fast speed modes (400 KHz and Plus 1 MHz)
• I2C 10-bit address
• I2C slave capabilities (programmable I2C address)
• DMA capabilities
• SMBus 2.0 compatible
  • Standard bus protocol (quick command; byte, word, block read/write)
  • Host notification
  • Alert

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

8.2. Security support

8.2.1. On STM32MP13x lines 

There are five I2C instances:

• I2C instances 1 and 2 are non-secure.
• I2C instances 3, 4 and 5 can be secure (under ETZPC control).

8.2.2. On STM32MP15x lines 

There are six I2C instances:

• I2C instances 1, 2, 3 and 5 are non-secure.
• I2C instances 4 and 6 can be secure (under ETZPC control).

9. Peripheral usage and associated software

9.1. Boot time

The I2C peripheral is usually not used at boot time. But it may be used by the SSBL and/or FSBL (see Boot chain overview), for example, to configure a PMIC (see PMIC hardware components), or to access data stored in an external EEPROM.

9.2. Runtime

9.2.1. Overview

Secure instances can be allocated to:

• the Arm^® Cortex^®-A7 secure core to be controlled in OP-TEE by the OP-TEE I2C driver

All I2C instances can be allocated to:

• the Arm^® Cortex^®-A7 non-secure core to be controlled in U-Boot or Linux^® by the I2C framework

On STM32MP15x lines , all but I2C4&6 instances can be allocated to:

• the Arm^® Cortex^®-M4 to be controlled in STM32Cube MPU Package by STM32Cube I2C driver

Chapter Peripheral assignment describes which peripheral instance can be assigned to which context.

9.2.2. Software frameworks

9.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Low speed interface	I2C	OP-TEE I2C driver	I2C Engine framework

9.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Low speed interface	I2C	OP-TEE I2C driver	I2C Engine framework	STM32Cube I2C driver

9.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

For Linux^® kernel configuration, please refer to I2C configuration.

Please refer to I2C device tree configuration for detailed information on how to configure I2C peripherals.

9.2.4. Peripheral assignment

9.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Low speed interface	I2C	I2C1		☐
		I2C2		☐
		I2C3	☐	☐	Assignment (single choice)
		I2C4	☐	☐	Assignment (single choice)
		I2C5	☐	☐	Assignment (single choice)

9.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Low speed interface	I2C	I2C1		☐	☐	Assignment (single choice)
		I2C2		☐	☐	Assignment (single choice)
		I2C3		☐	☐	Assignment (single choice)
		I2C4	☐	☐		Assignment (single choice). Used for PMIC control on ST boards.
		I2C5		☐	☐	Assignment (single choice)
		I2C6	☐	☐		Assignment (single choice)

11. Article purpose

The purpose of this article is to:

• briefly introduce the SPI peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the SPI peripheral and for some of them the I2S features.

12. Peripheral overview

The SPI peripheral can be used to communicate with an external devices using the SPI (Serial Peripheral Interface).
A subset of the SPI instances supports the I2S audio protocol. These SPI/I2S peripherals can alternatively be used in audio applications, when they are configured as an I2S interface. Refer to peripheral assignment chapter to check I2S feature support for each SPI instance.

12.1. Features

12.1.1. SPI main features

• Full-duplex, half-duplex and simplex synchronous modes.
• Slave and master modes.

12.1.2. I2S main features

Only available for SPI supporting I2S mode.

• Full-duplex or simplex modes.
• Slave and master modes.
• Four audio protocols supported.

12.1.3. Specific features

Some of the SPI peripheral characteristics depend on I2S support, as summarized in following table:

SPI modes/features	I2S supported	I2S not supported
Rx & TxFIFO size (N) [x 8-bit]	16	8
Maximum configurable data size [bits]	32	16

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

12.2. Security support

12.2.1. On STM32MP13x lines 

There are five SPI instances:

• SPI4 and SPI5 are secure peripheral (under ETZPC control)
• The other SPI instances are non-secure peripherals

12.2.2. On STM32MP15x lines 

There are six SPI instances:

• SPI6 is a secure peripheral (under ETZPC control)
• The other SPI instances are non-secure peripherals

13. Peripheral usage and associated software

13.1. Boot time

The SPI is not used at boot time.

13.2. Runtime

13.2.1. Overview

The secure instances can be allocated to:

• the Arm^® Cortex^®-A7 secure core. Notice that the SPI OP-TEE driver is not available in OpenSTLinux distribution yet.

All the SPI instances can be allocated to:

• the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by:

• the SPI framework for SPI configured in SPI mode
• the ALSA framework for SPI configured in I2S mode

or, on STM32MP15x lines  only,

• the Cortex-M4 to be controlled in STM32Cube MPU Package by STM32Cube SPI driver

Chapter Peripheral assignment describes which peripheral instance can be assigned to which context.

13.2.2. Software frameworks

13.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Low speed interface	SPI		Linux SPI framework	SPI configured in SPI mode
Audio	SPI		Linux ALSA framework	SPI configured in I2S mode Only for SPI supporting I2S feature

13.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Low speed interface	SPI		Linux SPI framework	STM32Cube SPI driver	SPI configured in SPI mode
Audio	SPI		Linux ALSA framework	STM32Cube I2S driver	SPI configured in I2S mode Only for SPI supporting I2S feature

13.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration by itself can be done via STM32CubeMX tool for all internal peripheral, then it can manually be completed (especially for external peripherals) according to the information given in the corresponding software framework article.

When the Arm^® Cortex^®-A7 core operates in non-secure access mode, the SPI is controlled by the Linux kernel framework.

• SPI mode:

Refer to SPI framework to check how to drive SPI through Linux kernel.

• I2S mode:

Refer to I2S Linux driver to drive the SPI through Linux kernel ALSA framework. Refer to Soundcard configuration to configure it through the Linux kernel device tree.

13.2.4. Peripheral assignment

13.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Low speed interface or audio	SPI	SPI2S1		☐
		SPI2S2		☐
		SPI2S3		☐
		SPI2S4	⬚	☐	Assignment (single choice)
		SPI5	⬚	☐	Assignment (single choice)

13.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Low speed interface or audio	SPI	SPI2S1		☐	☐	Assignment (single choice)
		SPI2S2		☐	☐	Assignment (single choice)
		SPI2S3		☐	☐	Assignment (single choice)
		SPI4		☐	☐	Assignment (single choice)
		SPI5		☐	☐	Assignment (single choice)
		SPI6	⬚	☐		Assignment (single choice)

15. Article purpose

The purpose of this article is to:

• briefly introduce the USART peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when needed, how to configure the USART peripheral.

16. Peripheral overview

The USART peripheral is used to interconnect STM32 MPU devices with other systems, typically via RS232 or RS485 protocols. In addition, the USART can be used for smartcard interfacing or SPI master/slave operation and supports the Synchronous mode.

The UART peripheral is similar to the USART, but does not support the Synchronous mode nor the smartcard interfacing.

High-speed data communications can be achieved by using the DMA internal peripheral for multibuffer configuration.

16.1. Features

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

16.2. Security support

16.2.1. On STM32MP13x lines 

USART1 and USART2 are a secure instances (under ETZPC control).
The other UARTs and USARTs are non-secure instances.

16.2.2. On STM32MP15x lines 

USART1 is a secure instance (under ETZPC control).
The other UARTs and USARTs are non-secure instances.

17. Peripheral usage and associated software

17.1. Boot time

All USART and UART instances that are not securable via ETZPC (see #Security support) are boot devices that support serial boot for Flash programming with STM32CubeProgrammer.

17.2. Runtime

17.2.1. Overview

The STM32 MPU devices feature four USART instances (supporting both Asynchronous and Synchronous modes), and four UART instances (supporting only Asynchronous mode).

Secure USART can be allocated to:

• the Arm^® Cortex^®-A7 secure core to be used under OP-TEE with the USART OP-TEE driver, typically to communicate with a smartcard.

All USART and UART instances can be allocated to:

• the Arm^® Cortex^®-A7 non-secure core to be used under Linux^® with the tty framework. However, the Linux^® kernel supports only the UART Asynchronous mode (Synchronous mode not supported).

or, on STM32MP15x lines  only,

• the Arm^® Cortex^®-M4 to be used with STM32Cube MPU Package with USART HAL driver. Both USART Synchronous and Asynchronous modes are supported by the STM32Cube MPU Package.

Chapter Peripheral assignment describes which peripheral instance can be assigned to which context.

17.2.2. Software frameworks

17.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Low speed interface	USART	USART OP-TEE driver	Linux serial/tty framework

17.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Low speed interface	USART	USART OP-TEE driver	Linux serial/tty framework	STM32Cube USART driver

17.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals) according to the information given in the corresponding software framework article or, for Linux in the Serial TTY device tree configuration article.

17.2.4. Peripheral assignment

17.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Low speed interface	USART	USART1	☐	☐	Assignment (single choice)
		USART2	☐	☐	Assignment (single choice)
		USART3		☐
		UART4		☐
		UART5		☐
		USART6		☐
		UART7		☐
		UART8		☐

17.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Low speed interface	USART	USART1	☐	☐		Assignment (single choice)
		USART2		☐	☐	Assignment (single choice)
		USART3		☐	☐	Assignment (single choice)
		UART4		☐	☐	Assignment (single choice). Used for Linux® serial console on ST boards.
		UART5		☐	☐	Assignment (single choice)
		USART6		☐	☐	Assignment (single choice)
		UART7		☐	☐	Assignment (single choice)
		UART8		☐	☐	Assignment (single choice)

18. How to go further

Additional documentation on USART peripheral is available on st.com:

• STM32 USART training presents the STM32 Universal Synchronous/Asynchronous Receiver/Transmitter interface.
• STM32 USART automatic baud rate detection presents STM32 USART automatic baud rate detection.

20. Article purpose

The purpose of this article is to:

• briefly introduce the FMC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain how to configure the FMC peripheral if necessary.

21. Peripheral overview

The FMC peripheral includes two memory controllers:

• The NOR/PSRAM memory controller
• The NAND memory controller.

21.1. NOR/PSRAM memory controller (or external bus interface controller)

The FMC NOR/PSRAM memory controller is used to interface static memory devices, but it is also used to interface Ethernet devices, LCD devices, and so on.

The FMC NOR/PSRAM controller generates the appropriate signal timings to drive the following types of memories:

• Asynchronous SRAM, FRAM and ROM
  • 8 bits
  • 16 bits
• PSRAM (CellularRAM™)
  • Asynchronous mode
  • Burst mode for synchronous accesses with configurable option to split burst access when crossing boundary page for CRAM 1.5.
  • Multiplexed or non-multiplexed
• NOR Flash memory
  • Asynchronous mode
  • Burst mode for synchronous accesses
  • Multiplexed or non-multiplexed

The FMC NOR/PSRAM controller supports a wide range of devices through programmable timings.
Among those programmable timings, there are:

• Programmable wait states (up to 15)
• Programmable bus turnaround cycles (up to 15)
• Programmable output enable and write enable delays (up to 15)
• Independent read and write timings and protocol to support the widest variety of memories and timings
• Programmable continuous clock output.

The FMC NOR/PSRAM controller also supports up to four external devices.

21.2. NAND Flash controller

The FMC NAND Flash controller is used to interface STM32 MPU with SLC 8-bit or 16-bit NAND Flash memory devices.

The FMC NAND Flash controller supports:

• Programmable error correction capability (ECC) using BCH8 code, BCH4 code or Hamming code
• Programmable page size of 2048, 4096 and 8192 bytes
• Programmable memory timings
• Multiple dice per package.
  

21.3. Features

Refer to STM32MP13 reference manuals or STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to know which features are really implemented.

21.4. Security support

21.4.1. On STM32MP13x lines 

The FMC is a secure peripheral (under ETZPC control).

21.4.2. On STM32MP15x lines 

The FMC is a non-secure peripheral.

22. Peripheral usage and associated software

22.1. Boot time

The FMC NAND Flash controller is the boot device that supports serial boot for Flash programming with STM32CubeProgrammer.

22.2. Runtime

22.2.1. Overview

The FMC peripheral can be allocated to:

• the Arm^® Cortex^®-A7 secure context, on STM32MP13x lines  only, but this is not supported in OpenSTLinux.

or

• the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the MTD framework.

or

• the Arm^® Cortex^®-M4, on STM32MP15x lines  only, to be controlled in STM32Cube MPU Package by FMC HAL driver.

Chapter #Peripheral assignment describes which instance can be assigned to which context.

22.2.2. Software frameworks

22.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Mass storage	FMC		Linux MTD Framework

22.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Mass storage	FMC		Linux MTD Framework	STM32Cube FMC driver

22.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the given information in the corresponding software framework article.

For Linux kernel configuration, please refer to FMC device tree configuration.

22.2.4. Peripheral assignment

22.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Mass storage	FMC	FMC	⬚	☐	Assignment (single choice)

22.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Mass storage	FMC	FMC		☐	☐	Assignment (single choice)

25. Article purpose

The purpose of this article is to

• briefly introduce the QUADSPI peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when needed, how to configure the QUADSPI peripheral.

26. Peripheral overview

The Quad-SPI interface (QUADSPI peripheral) interfaces the processor with serial NOR flash and serial NAND flash memories.
It supports:

• Single, Dual- or Quad-SPI flash memories
• A dual-flash mode, allowing to aggregate two flash memories into a virtual-single one
• Dual data rate and memory-mapped modes.

26.1. Features

Refer to STM32MP13 reference manuals or STM32MP15 reference manuals for the complete feature list and to the software components introduced below to know the implemented features.

26.2. Security support

26.2.1. On STM32MP13x lines 

The QUADSPI is a secure peripheral (under ETZPC control).

26.2.2. On STM32MP15x lines 

The QUADSPI is a non-secure peripheral.

27. Using the peripheral-associated software

27.1. Boot time

QUADSPI instance is a boot device that supports serial boot for flash programming with STM32CubeProgrammer.

27.2. Runtime

27.2.1. Overview

Allocation of the QUADSPI instances can be:

• The Arm^® Cortex^®-A7 secure context, on STM32MP13x lines  only, but this is not supported in OpenSTLinux.

or

• The Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the MTD framework

or

• The Arm^® Cortex^®-M4, on STM32MP15x lines  only, to be controlled in STM32Cube MPU Package by QUADSPI HAL driver

Chapter #Peripherals assignment describes which peripheral instances can be assigned to which context.

27.2.2. Software frameworks

27.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Mass storage	QUADSPI		Linux MTD framework

27.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Mass storage	QUADSPI		Linux MTD framework	STM32Cube QUADSPI driver

27.2.3. Peripheral configuration

The firmware, running in the context to which the peripheral is assigned, applies the configuration that can be done alone via the STM32CubeMX tool for all internal peripherals and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

For Linux kernel configuration, please refer to QUADSPI device tree configuration.

27.2.4. Peripherals assignment

27.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Mass storage	QUADSPI	QUADSPI	⬚	☐	Assignment (single choice)

27.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Mass storage	QUADSPI	QUADSPI		☐	☐	Assignment (single choice)

29. Article purpose

The purpose of this article is to

• briefly introduce the SDMMC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the SDMMC peripheral.

30. Peripheral overview

The SDMMC peripheral is used to interconnect STM32 MPU to SD memory cards, SDIO and MMC devices.

30.1. Features

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

30.2. Security support

30.2.1. On STM32MP13x lines 

The SDMMC1/2 instances are secure peripherals (under ETZPC control).

30.2.2. On STM32MP15x lines 

The SDMMC1/2/3 instances are non-secure peripherals.

31. Peripheral usage and associated software

31.1. Boot time

SDMMC1/2 instances can be used to support memory boot on SD or MMC Flash devices.

The SDMMC3 (only present on STM32MP15x lines ) is not used at boot time.

Information

The SDMMC instances are ordered by address in the device tree arch/arm/boot/dts/stm32mp151.dtsi file for STM32MP15x lines : sdmmc3: sdmmc@48004000 { ... sdmmc1: sdmmc@58005000 { ... sdmmc2: sdmmc@58007000 { By default, in OpenSTLinux distribution, sdmmc3 is disabled so the sdmmc1 (SD card on Evaluation boards and Discovery kits) and sdmmc2 (eMMC on Evaluation boards and Wifi on Discovery kits) are respectively aliased to mmc0 and mmc1. If you enable sdmmc3, it will take the mmc0 alias and the aliases above will shift, so don't forget to update the Linux kernel boot command accordingly! For instance, 'root=/dev/mmcblk0p6' will become 'root=/dev/mmcblk1p6' to mount the rootfs from the sdmmc1 (SD card) when sdmmc3 is enabled.

31.2. Runtime

31.2.1. Overview

On STM32MP13x lines  only, the SDMMC1/2 instances can be allocated to the Arm^® Cortex^®-A7 secure context but this is not supported in OpenSTLinux.

All the SDMMC instances can be allocated to the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the MMC framework.

On STM32MP15x lines  only, SDMMC3 can be allocated to the Arm^® Cortex^®-M4 to be controlled in STM32Cube MPU Package by STM32Cube SDMMC driver.

Chapter #Peripheral assignment describes which peripheral instance can be assigned to which context.

31.2.2. Software frameworks

31.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Mass storage	SDMMC		Linux MMC framework

31.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Mass storage	SDMMC		Linux MMC framework	STM32Cube SDMMC driver

31.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

For Linux^® kernel configuration, please refer to SDMMC device tree configuration.

31.2.4. Peripheral assignment

31.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Mass storage	SDMMC	SDMMC1	⬚	☐	Assignment (single choice)
		SDMMC2	⬚	☐	Assignment (single choice)

31.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Mass storage	SDMMC	SDMMC1		☐
		SDMMC2		☐
		SDMMC3		☐	☐	Assignment (single choice)

33. Article purpose

The purpose of this article is to:

• briefly introduce the Ethernet peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the Ethernet peripheral.

34. Peripheral overview

The Ethernet peripheral (ETH) is based on Synopsys DesignWare^® Ethernet GMAC IP, which enables the host to communicate data using the Gigabit Ethernet protocol (IEEE 802.3) at 10, 100 and 1000 Mbps.
The peripheral is composed of three main layers: the gigabit ethernet media access controller (GMAC), the MAC transaction layer (MTL), and the MAC DMA controller (MDC). The driver used to drive the ETH is Stmmac.

34.1. Features

The Ethernet peripheral main features are the following:

• Compliance with IEEE 802.3 specifications
• Support for IEEE 1588-2002 and IEEE 1588-2008 standards for precision networked clock synchronization

IEEE 802.3-az for Energy Efficient Ethernet (EEE)

IEEE 802.3x flow control automatic transmission of zero-quanta pause frame on flow control input de-assertion.

IEEE 802.1Q VLAN tag detection for reception frames on STM32MP15x lines  only

AMBA 2.0 for AHB Master/Slave ports and AMBA 3.0 for AXI Master/Slave ports

• Configurability allowing to support data transfer rates of 10/100/100 Mbps, 10/100 Mbps only or 1000 Mbps only
• Support for multiple TCP/IP offload functions

Refer to STM32MP13 reference manuals or STM32MP15 reference manuals for the complete features list, and to the software components, introduced below, to see which features are implemented.

34.2. Security support

34.2.1. On STM32MP13x lines 

The two ETH instances are secure peripherals (under ETZPC control).

34.2.2. On STM32MP15x lines 

The single instance ETH is a non-secure peripheral.

35. Peripheral usage and associated software

35.1. Boot time

The Ethernet peripheral can be used at boot time by SSBL (by UBoot with tftp protocol for image loading). See How_to_boot_the_kernel_via_TFTP_from_U-Boot for more details.

35.2. Runtime

35.2.1. Overview

The Ethernet peripheral(s) can be allocated to the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the NetDev Framework.

35.2.2. Software frameworks

35.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Networking	ETH		Linux netdev/ethernet framework

35.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Networking	ETH		Linux netdev/ethernet framework

35.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article. When the Ethernet peripheral is assigned to the Linux^® OS, it is configured through the device tree according to the information given in the Ethernet device tree configuration article.

35.2.4. Peripheral assignment

35.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Networking	ETH	ETH1	⬚	☐	Assignment (single choice)
		ETH2	⬚	☐	Assignment (single choice)

35.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Networking	ETH	ETH		☐		Assignment (single choice)

37. Article purpose

The purpose of this article is to:

• briefly introduce the FDCAN peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the FDCAN peripheral.

38. Peripheral overview

FDCAN peripheral handles data communication in a Controller Area Network (CAN) bus system using message-based protocol originally designed for in-vehicle communication. The CAN subsystem consists of two CAN modules (FDCAN1 and FDCAN2), a shared message RAM and an optional clock calibration unit.

38.1. Features

Both FDCAN instances are compliant with classic CAN protocol and CAN FD (CAN with Flexible Data-Rate) protocol. In addition, FDCAN1 supports time triggered CAN (TTCAN).

FDCAN1 and FDCAN2 share a dedicated 10 Kbyte CAN SRAM for message transfers.

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

38.2. Security support

FDCAN is a non secure peripheral.

39. Peripheral usage and associated software

39.1. Boot time

The FDCAN is not used at boot time.

39.2. Runtime

39.2.1. Overview

FDCAN instances can be allocated to:

• the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the NetDev framework (See CAN overview)

or, on STM32MP15x lines  only

• the Arm^® Cortex^®-M4 to be controlled in STM32Cube MPU Package by STM32Cube FDCAN driver

39.2.2. Software frameworks

39.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Networking	FDCAN		Linux net/can framework

39.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Networking	FDCAN		Linux net/can framework	STM32Cube FDCAN driver

39.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals) according to the information given in the corresponding software framework article. When the FDCAN peripheral is assigned to the Linux^® OS, it is configured through the device tree according to the information given in the FDCAN device tree configuration article.

39.2.4. Peripheral assignment

39.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Networking	FDCAN	FDCAN1		☐
		FDCAN2		☐

39.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Networking	FDCAN	FDCAN1		☐	☐	Assignment (single choice)
		FDCAN2		☐	☐	Assignment (single choice)

41. Peripheral overview

The DTS peripheral is used to monitor the device temperature and take some preventive action (like frequency scaling or peripheral disabling) in case it is becoming too high and before destroying the component.

41.1. Features

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

41.2. Security support

The DTS is a non secure peripheral.

42. Peripheral usage and associated software

42.1. Boot time

DTS is not used at boot time.

42.2. Runtime

42.2.1. Overview

The monitoring is done from the Cortex-A7 non-secure context with Linux^® thermal management framework.

42.2.2. Software frameworks

42.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Power & Thermal	DTS		Linux thermal framework

42.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Power & Thermal	DTS		Linux thermal framework

42.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

42.2.4. Peripheral assignment

42.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Power & Thermal	DTS	DTS		☐

42.2.4.2. On STM32MP15x lines 

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 a runtime 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	DTS	DTS		☐

43. References

| rowspan="1" | Power & Thermal
| rowspan="1" | PWR
| PWR
| ✓
| ✓
| ✓
|
|-

| rowspan="1" | Power & Thermal
| rowspan="1" | RCC
| RCC
| ✓
| ✓
| ✓
|
|-

44. Article purpose

The purpose of this article is to

• briefly introduce the BSEC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the BSEC peripheral.

45. Peripheral overview

The BSEC peripheral is used to control an OTP (one time programmable) fuse box, used for on-chip non-volatile storage for device configuration and security parameters.

45.1. Features

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

45.2. Security support

The BSEC is a secure peripheral.

46. Peripheral usage and associated software

46.1. Boot time

The BSEC is configured at boot time to set up platform security.

46.2. Runtime

46.2.1. Overview

The BSEC is a system peripheral and is controlled by the Arm^® Cortex^®-A7 secure:

Information

BSEC lower OTP access can be made available to the Arm® Cortex®-A7 non-secure. Upper OTP access can be managed as exceptions: on STM32MP13x lines , using OP-TEE PTA on STM32MP15x lines , using TF-A "secure monitor calls" or OP-TEE PTA Please refer to BSEC device tree configuration for more details.

46.2.2. Software frameworks

46.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Security	BSEC	OP-TEE OTP PTA	Linux NVMEM framework

46.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Security	BSEC	OP-TEE OTP PTA	Linux NVMEM framework

46.2.3. Peripheral configuration

The configuration is based on Device tree, please refer to BSEC device tree configuration article.
It can be applied by the firmware running in a secure context, done in TF-A or in OP-TEE.
It can also be configured by Linux^® kernel, please refer to NVMEM overview article.

46.2.4. Peripheral assignment

46.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Security	BSEC	BSEC	✓	✓

46.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Security	BSEC	BSEC	✓	✓

49. Article purpose

The purpose of this article is to

• briefly introduce the CRC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain how to configure the CRC peripheral.

50. Peripheral overview

The CRC peripheral is used to verify data transmission or storage integrity.

50.1. Features

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

50.2. Security support

50.2.1. On STM32MP13x lines 

CRC is a non-secure peripheral.

50.2.2. On STM32MP15x lines 

CRC1 and CRC2 are non-secure peripherals.

51. Peripheral usage and associated software

51.1. Boot time

CRC instances are not used at boot time.

51.2. Runtime

51.2.1. Overview

CRC instances can be allocated to:

• the Arm^® Cortex^®-A7 non-secure for using in Linux^® with Linux Crypto framework

or, on STM32MP15x lines  only

• the Arm^® Cortex^®-M4 for using in STM32Cube with STM32Cube CRC driver

Chapter Peripheral assignment describes which peripheral instance can be assigned to which context.

51.2.2. Software frameworks

51.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Security	CRC		Linux Crypto framework

51.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Security	CRC		Linux Crypto framework	STM32Cube CRC driver

51.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

51.2.4. Peripheral assignment

51.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Security	CRC	CRC		☐

51.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Security	CRC	CRC1		☐
		CRC2			☐

52. References

STM32MP15 CRYP internal peripheral

| rowspan="1" | Security
| rowspan="1" | ETZPC
| ETZPC
| ✓
| ✓
| ✓
| 
|-

| rowspan="2" | Security
| rowspan="2" | HASH
| HASH1
| ☐
| ☐
| 
| Assignment (single choice)
|-
| HASH2
| 
| 
| ☐
| 
|-

| rowspan="2" | Security
| rowspan="2" | RNG
| RNG1
| ☐
| ☐
| 
| Assignment (single choice)
|-
| RNG2
| 
| 
| ☐
| 
|-

53. Article purpose

The purpose of this article is to:

• briefly introduce the TZC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how it can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the TZC peripheral.

54. Peripheral overview

The TZC peripheral is used to filter read/write accesses to the DDR controller according to TrustZone access rights, and according to Non-Secure master Address ID (NSAID) on up to 9 programmable regions.

54.1. Features

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

54.2. Security support

The TZC is a secure peripheral.

55. Peripheral usage and associated software

55.1. Boot time

The TZC is configured at boot time to setup DDR accesses. It is initially configured thanks to TF-A FW Configuration. OP-TEE redefined the TZC regions based on device tree.

55.2. Runtime

55.2.1. Overview

The TZC is a system peripheral and is controlled by the Arm^® Cortex^®-A7 secure.

55.2.2. Software frameworks

55.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Security	TZC	OP-TEE TZC driver

55.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Security	TZC	OP-TEE TZC driver

55.2.3. Peripheral configuration

The configuration is applied by the firmware running in the secure context.

This configuration is done in OP-TEE.

55.2.4. Peripheral assignment

55.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Security	TZC	TZC	✓

55.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Security	TZC	TZC	✓

56. How to go further

The TZC is an Arm^® peripheral: TZC-400 TrustZone Address Space Controller

57. References

| rowspan="1" | Security
| rowspan="1" | TAMP
| TAMP
| ✓
| ✓
|
|
|-

58. Article purpose

The purpose of this article is to:

• briefly introduce the DBGMCU peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the DBGMCU peripheral.

59. Peripheral overview

The DBGMCU peripheral is used to configure internal peripherals behavior when one of the available cores enters in debug mode.
For instance, it allows to freeze a watchdog (IWDG) to avoid getting a watchdog reset when the Cortex^®-A7 enters in debug mode (via a breakpoint or JTAG break).

59.1. Features

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

59.2. Security support

The DBGMCU is a non secure peripheral.

60. Peripheral usage and associated software

60.1. Boot time

DBGMCU is used by the boot chain to get the device ID and revision, to adapt its behavior accordingly.
During a debug session, the DBGMCU can be accessed via the debug access port (DAP) to configure the expected behavior on break, typically to get IWDG2 frozen when the Cortex^®-A7 enters in debug mode.

60.2. Runtime

60.2.1. Overview

There is no real runtime support for DBGMCU.

60.2.2. Software frameworks

60.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Trace & Debug	DBGMCU

60.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Trace & Debug	DBGMCU

60.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article.

60.2.4. Peripheral assignment

60.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Trace & Debug	DBGMCU	DBGMCU			No assignment

60.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Trace & Debug	DBGMCU	DBGMCU				No assignment

61. Article purpose

The purpose of this article is to

• briefly introduce the HDP peripheral (hardware debug port) and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when needed, how to configure the HDP peripheral.

62. Peripheral overview

The HDP peripheral is used to output some internal signals on up to 8 GPIO pins.

Follow the sequence below to connect a GPIO to an internal signal via the HDP:

• First of all, look for the internal signal you want to monitor in the HDP signal multiplexing table of the STM32MP13 reference manuals or STM32MP15 reference manuals:
  • Search for the HDP signal on which you can get it among eight possible choices.
  • Note the corresponding HDPx multiplexing value to select.
• Then, look for the most suitable GPIO pin on which you can output HDPx (in the datasheets for STM32MP13x lines  and datasheets for STM32MP15x lines ):
  • Note the GPIO bank and pin.
  • Note the corresponding GPIO alternate function (AF) to select.

The GPIO bank, pin, alternate function and HDPx multiplexing value are the information required to configure each HDP signal.

62.1. Features

Refer to STM32MP13 reference manuals or STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to know which features are really implemented.

62.2. Security support

The HDP is a non-secure peripheral.

63. Peripheral usage and associated software

63.1. Boot time

The HDP is not used at boot time.

63.2. Runtime

63.2.1. Overview

The HDP can be allocated to the Arm^® Cortex^®-A7 non-secure core to be used under Linux^® HDP driver.

63.2.2. Software frameworks

63.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Trace & Debug	HDP		HDP Linux driver

63.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Trace & Debug	HDP		HDP Linux driver

63.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration by itself can be performed via the STM32CubeMX tool for all internal peripherals. It can then be manually completed (especially for external peripherals) according to the information given in the corresponding software framework article.

63.2.4. Peripheral assignment

63.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Trace & Debug	HDP	HDP		☐

63.2.4.2. On STM32MP15x lines 

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 a runtime 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)
Trace & Debug	HDP	HDP		☐

| rowspan="1" | Trace & Debug
| rowspan="1" | STM
| STM
|
| 
|
| No assignment possible 
|-

| rowspan="1" | Visual
| rowspan="1" | CEC
| CEC
| 
| ☐
| ☐
| Assignment (single choice)
|-

| rowspan="1" | Visual
| rowspan="1" | DCMI
| DCMI
| 
|☐ 
|☐ 
| Assignment (single choice)
|-

| rowspan="1" | Visual
| rowspan="1" | DSI
| DSI
| 
| ☐
|
|
|-

| rowspan="1" | Visual
| rowspan="1" | GPU
| GPU
| 
| ☐
|
|
|-

Applicable for

STM32MP13x lines, STM32MP15x lines

---

64. Article purpose

The purpose of this article is to:

• briefly introduce the LTDC peripheral and its main features
• indicate the level of security supported by this hardware block
• explain how each instance can be allocated to the runtime contexts and linked to the corresponding software components
• explain, when necessary, how to configure the LTDC peripheral.

65. Peripheral overview

The LCD-TFT (Liquid Crystal Display - Thin Film Transistor) Display Controller peripheral (LTDC) is used to provide an interface to a variety of parallel digital RGB LCD and TFT display panels. The LTDC generates the parallel digital RGB (Red, Green, Blue) signals and the related control signals (horizontal and vertical synchronizations, Pixel Clock and Data Enable).
Moreover, on STM32MP15x lines , the LTDC is connected to the DSI internal peripheral that provides an interface to communicate with MIPI^® DSI-compliant display panels.

65.1. Features

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

65.2. Security support

65.2.1. On STM32MP13x lines 

The LTDC layer2 can be set as secure (under ETZPC control), whereas the layer1 is always non-secure.

65.2.2. On STM32MP15x lines 

The LTDC is a non-secure peripheral.

66. Peripheral usage and associated software

66.1. Boot time

The LTDC is used at boot time for displaying a splash screen thanks to the U-Boot framework .

66.2. Runtime

66.2.1. Overview

The LTDC internal peripheral is allocated to the Arm^® Cortex^®-A7 non-secure core to be controlled in Linux^® by the Linux DRM/KMS framework.

On STM32MP13x lines , the LTDC can be set secure from ETZPC : this is done at runtime when OP-TEE trusted user interface (Trusted UI) is launched in order to switch the LTDC control and the input layer2 as secure, to display a secure content that cannot be seen from the non-secure world.

Chapter Peripheral assignment describes which peripheral instance can be assigned to which context.

66.2.2. Software frameworks

66.2.2.1. On STM32MP13x lines 

Domain	Peripheral	Software components		Comment
		OP-TEE	Linux
Visual	LTDC	OP-TEE Trusted UI	DRM/KMS framework

66.2.2.2. On STM32MP15x lines 

Domain	Peripheral	Software components			Comment
		OP-TEE	Linux	STM32Cube
Visual	LTDC		DRM/KMS framework

66.2.3. Peripheral configuration

The configuration is applied by the firmware running in the context to which the peripheral is assigned. The configuration can be done alone via the STM32CubeMX tool for all internal peripherals, and then manually completed (particularly for external peripherals), according to the information given in the corresponding software framework article or in the LTDC device tree configuration article for Linux^®.

66.2.4. Peripheral assignment

66.2.4.1. On STM32MP13x lines 

Click on the right to expand the legend...

STM32MP13 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 a runtime 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 STM32MP13 reference manuals.

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Visual	LTDC	LTDC	☐	☐	Shareable (multiple choices supported)

66.2.4.2. On STM32MP15x lines 

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 a runtime 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	LTDC	LTDC		☐

67. How to go further

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

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

68. References

|}

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.

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

Voltage reference buffer (STM32 specific)

Inter-processor communication controller

Hardware semaphore

Real time clock

System time generator

First stage boot loader

Linux^® is a registered trademark of Linus Torvalds.

Open portable trusted execution environment

System configuration

Direct memory access

External interrupt

Generic interrupt controller

Nested vectored interrupt controller

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

Doubledata rate (memory domain)

High speed internal oscillator (STM32 clock source) or High speed synchronous serial interface (MIPI^® Alliance standard)

Multi Speed Internal oscillator (STM32 clock source)

USB on-the-go (Capability/type of USB port, acting primarily as USB device, to also act as USB host. Also known as USB OTG.)

USB Host (STM32 specific)

High speed (MIPI^® alliance DSI standard)

Inter-integrated circuit (Bi-directional 2-wire bus standard for efficient inter-IC control.)

System management bus

Second stage boot loader

Power management integrated circuit

Electrically-erasable programmable read-only memory

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

Microprocessor unit

Serial peripheral interface

Integrated interchip sound

Extended trustzone protection controller

Advanced Linux sound architecture

Universal synchronous/asynchronous receiver/transmitter

Universal asynchronous receiver/transmitter

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

Read only memory

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

Single-level cell is a kind of NAND flash

Elliptic curve cryptography

Error correction capability

Secure digital

Secure digital input/output

Multimedia card

SD memory card (https://www.sdcard.org)

Former spelling for e•MMC ('e' in italic)

Ethernet

Virtual LAN. Network of computers that behave as if they are connected to the same wire even though they may actually be physically located on different segments of a LAN

Advanced high-performance bus

Controller area network (robust bus mainly used for automotive applications)

Device tree source (in software context) or digital temperature sensor (in peripheral context)

Reset and clock control

Boot and Security and OTP control

One time programmed

Pseudo Trusted Application

Cyclic redundancy check calculation unit

TrustZone^® address space Controller for DDR
Arm^® and TrustZone^® are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

TrustZone^®
Arm^® and TrustZone^® are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Tamper

debug and test protocol, named from the Joint Test Action Group that developed it

Hardware debug port

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

GPIO alternate function

System trace module

Consumer electronics control (HDMI standard)

Digital Camera memory interface

Display serial interface (MIPI^® Alliance standard)

Graphics processing units

LCD TFT display controller (STM32 specific)

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

User interface