STM32MP15 peripherals overview

Revision as of 15:32, 27 October 2021 by Registered User
This message will disappear after all relevant tasks have been resolved.
Semantic MediaWiki
There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

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[edit source]

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[1], 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:

STM32MP1IPsOverview legend.png

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 [2] may expose more possibilities than what is shown here.


STGENSYSCFGRTCEXTIGICNVICIWDGIWDGWWDGDMADMADMAMUXMDMASYSRAMDDR via DDR CTRLBKPSRAMMCU SRAMMCU SRAMRETRAMTIMTIMLPTIMGPIOGPIOIPCCHSEMRCCPWRDTSDBGMCUHDPSTMBSECQUADSPIFMCSDMMCFDCANETHSDMMCUSBHOTGUSBPHYCUSARTUSARTUSARTI2CI2CI2CSPISPIRNGHASHETZPCCRYPCRCTZCRNGHASHTAMPCRYPCRCGPUDSILTDCDCMICECVREFBUFDACDFSDMADCSPI I2SSPDIFRXSAI
STM32MP1 internal peripherals overview

2. Internal peripherals assignment[edit source]

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[edit source]

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[edit source]

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[edit source]

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[edit source]

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[edit source]

5.1. Boot time[edit source]

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[edit source]

5.2.1. Overview[edit source]

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[edit source]

5.2.2.1. On STM32MP13x lines More info.png[edit source]
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 More info.png[edit source]
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.3. Peripheral configuration[edit source]

5.2.4. Peripheral assignment[edit source]

5.2.4.1. On STM32MP13x lines More info.png[edit source]

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 More info.png[edit source]

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[edit source]

  1. ↑ Getting started with STM32 MPU devices#Multiple-core architecture concepts
  2. ↑ STM32MP15 reference manuals 


| 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[1]
|-
| 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[1]
|-
| 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)
| 
| ☐
|
|
|-



| rowspan="6" | Low speed interface
| rowspan="6" | 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)
|-



| rowspan="6" | Low speed interface 
 or 
 audio
| rowspan="6" | 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)
|-



| rowspan="8" | Low speed interface
| rowspan="8" | 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)
|-


7. Article purpose[edit source]

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.

8. Peripheral overview[edit source]

The FMC peripheral includes two memory controllers:

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

8.1. NOR/PSRAM memory controller (or external bus interface controller)[edit source]

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.

8.2. NAND Flash controller[edit source]

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.

8.3. Features[edit source]

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.

8.4. Security support[edit source]

8.4.1. On STM32MP13x lines More info.png[edit source]

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

8.4.2. On STM32MP15x lines More info.png[edit source]

The FMC is a non-secure peripheral.

9. Peripheral usage and associated software[edit source]

9.1. Boot time[edit source]

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

9.2. Runtime[edit source]

9.2.1. Overview[edit source]

The FMC peripheral can be allocated to:

  • the Arm® Cortex®-A7 secure context, on STM32MP13x lines More info.png 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 More info.png only, to be controlled in STM32Cube MPU Package by FMC HAL driver.

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

9.2.2. Software frameworks[edit source]

9.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Mass storage FMC Linux MTD Framework
9.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Mass storage FMC Linux MTD Framework STM32Cube FMC driver

9.2.3. Peripheral configuration[edit source]

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.

9.2.4. Peripheral assignment[edit source]

9.2.4.1. On STM32MP13x lines More info.png[edit source]

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)
9.2.4.2. On STM32MP15x lines More info.png[edit source]

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)

10. How to go further[edit source]

11. References[edit source]

  1. ↑ 1.0 1.1 How to activate HSI and CSI oscillators calibration



12. Article purpose[edit source]

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.

13. Peripheral overview[edit source]

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.

13.1. Features[edit source]

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.

13.2. Security support[edit source]

13.2.1. On STM32MP13x lines More info.png[edit source]

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

13.2.2. On STM32MP15x lines More info.png[edit source]

The QUADSPI is a non-secure peripheral.

14. Using the peripheral-associated software[edit source]

14.1. Boot time[edit source]

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

14.2. Runtime[edit source]

14.2.1. Overview[edit source]

Allocation of the QUADSPI instances can be:

  • The Arm® Cortex®-A7 secure context, on STM32MP13x lines More info.png 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 More info.png 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.

14.2.2. Software frameworks[edit source]

14.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Mass storage QUADSPI Linux MTD framework
14.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Mass storage QUADSPI Linux MTD framework STM32Cube QUADSPI driver

14.2.3. Peripheral configuration[edit source]

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.

14.2.4. Peripherals assignment[edit source]

14.2.4.1. On STM32MP13x lines More info.png[edit source]

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)
14.2.4.2. On STM32MP15x lines More info.png[edit source]

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)

15. References[edit source]



16. Article purpose[edit source]

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.

17. Peripheral overview[edit source]

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

17.1. Features[edit source]

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.

17.2. Security support[edit source]

17.2.1. On STM32MP13x lines More info.png[edit source]

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

17.2.2. On STM32MP15x lines More info.png[edit source]

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

18. Peripheral usage and associated software[edit source]

18.1. Boot time[edit source]

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

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

Info white.png Information
The SDMMC instances are ordered by address in the device tree arch/arm/boot/dts/stm32mp151.dtsi file for STM32MP15x lines More info.png: 
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.

18.2. Runtime[edit source]

18.2.1. Overview[edit source]

On STM32MP13x lines More info.png 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 More info.png 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.

18.2.2. Software frameworks[edit source]

18.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Mass storage SDMMC Linux MMC framework
18.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Mass storage SDMMC Linux MMC framework STM32Cube SDMMC driver

18.2.3. Peripheral configuration[edit source]

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.

18.2.4. Peripheral assignment[edit source]

18.2.4.1. On STM32MP13x lines More info.png[edit source]

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)
18.2.4.2. On STM32MP15x lines More info.png[edit source]

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)

19. References[edit source]



20. Article purpose[edit source]

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.

21. Peripheral overview[edit source]

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.

21.1. Features[edit source]

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 More info.png 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.

21.2. Security support[edit source]

21.2.1. On STM32MP13x lines More info.png[edit source]

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

21.2.2. On STM32MP15x lines More info.png[edit source]

The single instance ETH is a non-secure peripheral.

22. Peripheral usage and associated software[edit source]

22.1. Boot time[edit source]

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.

22.2. Runtime[edit source]

22.2.1. Overview[edit source]

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

22.2.2. Software frameworks[edit source]

22.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Networking ETH Linux netdev/ethernet framework
22.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Networking ETH Linux netdev/ethernet framework

22.2.3. Peripheral configuration[edit source]

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.

22.2.4. Peripheral assignment[edit source]

22.2.4.1. On STM32MP13x lines More info.png[edit source]

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)
22.2.4.2. On STM32MP15x lines More info.png[edit source]

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)

23. References[edit source]



24. Article purpose[edit source]

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.

25. Peripheral overview[edit source]

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.

25.1. Features[edit source]

Both FDCAN instances are compliant with classic CAN protocol[1] and CAN FD[2] (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.

25.2. Security support[edit source]

FDCAN is a non secure peripheral.

26. Peripheral usage and associated software[edit source]

26.1. Boot time[edit source]

The FDCAN is not used at boot time.

26.2. Runtime[edit source]

26.2.1. Overview[edit source]

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 More info.png only

26.2.2. Software frameworks[edit source]

26.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Networking FDCAN Linux net/can framework
26.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Networking FDCAN Linux net/can framework STM32Cube FDCAN driver

26.2.3. Peripheral configuration[edit source]

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.

26.2.4. Peripheral assignment[edit source]

26.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ☐
26.2.4.2. On STM32MP15x lines More info.png[edit source]

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)

27. References[edit source]

  1. ↑ CAN protocol implementations, from the CAN in Automation group (CiA)
  2. ↑ CAN FD - The basic idea, from the CAN in Automation group (CiA)


28. Peripheral overview[edit source]

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.

28.1. Features[edit source]

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.

28.2. Security support[edit source]

The DTS is a non secure peripheral.

29. Peripheral usage and associated software[edit source]

29.1. Boot time[edit source]

DTS is not used at boot time.

29.2. Runtime[edit source]

29.2.1. Overview[edit source]

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

29.2.2. Software frameworks[edit source]

29.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Power & Thermal DTS Linux thermal framework
29.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Power & Thermal DTS Linux thermal framework

29.2.3. Peripheral configuration[edit source]

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.

29.2.4. Peripheral assignment[edit source]

29.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ☐
29.2.4.2. On STM32MP15x lines More info.png[edit source]

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 ☐

30. References[edit source]



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



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


31. Article purpose[edit source]

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.

32. Peripheral overview[edit source]

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.

32.1. Features[edit source]

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.

32.2. Security support[edit source]

The BSEC is a secure peripheral.

33. Peripheral usage and associated software[edit source]

33.1. Boot time[edit source]

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

33.2. Runtime[edit source]

33.2.1. Overview[edit source]

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

Info white.png 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 More info.png, using OP-TEE PTA
  • on STM32MP15x lines More info.png, using TF-A "secure monitor calls" or OP-TEE PTA

Please refer to BSEC device tree configuration for more details.

33.2.2. Software frameworks[edit source]

33.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Security BSEC OP-TEE OTP PTA Linux NVMEM framework
33.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Security BSEC OP-TEE OTP PTA Linux NVMEM framework

33.2.3. Peripheral configuration[edit source]

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.

33.2.4. Peripheral assignment[edit source]

33.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ✓ ✓
33.2.4.2. On STM32MP15x lines More info.png[edit source]

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 ✓ ✓

34. How to go further[edit source]

35. References[edit source]



36. Article purpose[edit source]

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.

37. Peripheral overview[edit source]

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

37.1. Features[edit source]

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.

37.2. Security support[edit source]

37.2.1. On STM32MP13x lines More info.png[edit source]

CRC is a non-secure peripheral.

37.2.2. On STM32MP15x lines More info.png[edit source]

CRC1 and CRC2 are non-secure peripherals.

38. Peripheral usage and associated software[edit source]

38.1. Boot time[edit source]

CRC instances are not used at boot time.

38.2. Runtime[edit source]

38.2.1. Overview[edit source]

CRC instances can be allocated to:

or, on STM32MP15x lines More info.png only

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

38.2.2. Software frameworks[edit source]

38.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Security CRC Linux Crypto framework
38.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Security CRC Linux Crypto framework STM32Cube CRC driver

38.2.3. Peripheral configuration[edit source]

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.

38.2.4. Peripheral assignment[edit source]

38.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ☐
38.2.4.2. On STM32MP15x lines More info.png[edit source]

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 ☐

39. References[edit source]


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
| 
| 
| ☐
| 
|-


40. Article purpose[edit source]

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.

41. Peripheral overview[edit source]

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.

41.1. Features[edit source]

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[edit source]

The TZC is a secure peripheral.

42. Peripheral usage and associated software[edit source]

42.1. Boot time[edit source]

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.

42.2. Runtime[edit source]

42.2.1. Overview[edit source]

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

42.2.2. Software frameworks[edit source]

42.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Security TZC OP-TEE TZC driver
42.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Security TZC OP-TEE TZC driver

42.2.3. Peripheral configuration[edit source]

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

This configuration is done in OP-TEE.

42.2.4. Peripheral assignment[edit source]

42.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ✓
42.2.4.2. On STM32MP15x lines More info.png[edit source]

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 ✓

43. How to go further[edit source]

The TZC is an Arm® peripheral: TZC-400 TrustZone Address Space Controller[1]

44. References[edit source]

  1. ↑ http://infocenter.arm.com/help/topic/com.arm.doc.ddi0504c/DDI0504C_tzc400_r0p1_trm.pdf 


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


45. Article purpose[edit source]

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.

46. Peripheral overview[edit source]

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

46.1. Features[edit source]

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.

46.2. Security support[edit source]

The DBGMCU is a non secure peripheral.

47. Peripheral usage and associated software[edit source]

47.1. Boot time[edit source]

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.

47.2. Runtime[edit source]

47.2.1. Overview[edit source]

There is no real runtime support for DBGMCU.

47.2.2. Software frameworks[edit source]

47.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Trace & Debug DBGMCU
47.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Trace & Debug DBGMCU

47.2.3. Peripheral configuration[edit source]

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.

47.2.4. Peripheral assignment[edit source]

47.2.4.1. On STM32MP13x lines More info.png[edit source]

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
47.2.4.2. On STM32MP15x lines More info.png[edit source]

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


48. Article purpose[edit source]

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.

49. Peripheral overview[edit source]

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 More info.png and datasheets for STM32MP15x lines More info.png):
    • 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.

49.1. Features[edit source]

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.

49.2. Security support[edit source]

The HDP is a non-secure peripheral.

50. Peripheral usage and associated software[edit source]

50.1. Boot time[edit source]

The HDP is not used at boot time.

50.2. Runtime[edit source]

50.2.1. Overview[edit source]

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


50.2.2. Software frameworks[edit source]

50.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Trace & Debug HDP HDP Linux driver
50.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Trace & Debug HDP HDP Linux driver

50.2.3. Peripheral configuration[edit source]

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.

50.2.4. Peripheral assignment[edit source]

50.2.4.1. On STM32MP13x lines More info.png[edit source]

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 ☐
50.2.4.2. On STM32MP15x lines More info.png[edit source]

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

51. Article purpose[edit source]

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.

52. Peripheral overview[edit source]

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 More info.png, the LTDC is connected to the DSI internal peripheral that provides an interface to communicate with MIPI® DSI-compliant display panels.

52.1. Features[edit source]

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.

52.2. Security support[edit source]

52.2.1. On STM32MP13x lines More info.png[edit source]

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

52.2.2. On STM32MP15x lines More info.png[edit source]

The LTDC is a non-secure peripheral.

53. Peripheral usage and associated software[edit source]

53.1. Boot time[edit source]

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

53.2. Runtime[edit source]

53.2.1. Overview[edit source]

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 More info.png, 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.

53.2.2. Software frameworks[edit source]

53.2.2.1. On STM32MP13x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux
Visual LTDC OP-TEE Trusted UI DRM/KMS framework
53.2.2.2. On STM32MP15x lines More info.png[edit source]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Visual LTDC DRM/KMS framework

53.2.3. Peripheral configuration[edit source]

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

53.2.4. Peripheral assignment[edit source]

53.2.4.1. On STM32MP13x lines More info.png[edit source]

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)
53.2.4.2. On STM32MP15x lines More info.png[edit source]

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 ☐

54. How to go further[edit source]

Refer to STM32 LTDC application note (AN4861) [2] 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.

55. References[edit source]

  1. ↑ U-Boot framework
  2. ↑ LCD-TFT display controller (LTDC) on STM32 MCUs application note (AN4861) 


|}

56. References[edit source]



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

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)

Power management integrated circuit

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.

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

Microprocessor unit

Single-level cell is a kind of NAND flash

Elliptic curve cryptography

Error correction capability

Serial peripheral interface

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

Second stage boot loader

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

Extended trustzone protection controller

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

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

User interface

Retrieved from "https://wiki.st.com/stm32mpu-ecosystem-v4/index.php?title=STM32MP15_peripherals_overview&oldid=80026"