STM32MP15 peripherals overview

Revision as of 15:26, 13 February 2019 by Registered User

Template:ArticleMainWriter Template:ArticleApprovedVersion


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

Contents

1 Internal peripherals overview[edit]

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 SRAMRETRAMTIMTIMLPTIMGPIOGPIOIPCCRCCPWRDTSDBGMCUHDPSTMBSECQUADSPIFMCSDMMCFDCANETHSDMMCUSBHOTGUSARTUSARTUSARTI2CI2CI2CSPISPIRNGHASHETZPCCRYPCRCTZCRNGHASHTAMPCRYPCRCGPUDSILTDCDCMICECVREFBUFDACDFSDMADCSPI I2SSPDIFRXSAI
STM32MP1 internal peripherals overview

Template:WarningImageMapOverlay



2 Internal peripherals assignment[edit]

Internal peripherals assignment table template

Information about the "ADC internal peripheral" depends on the microprocessor device.

Several articles are created to manage STM32 MPU diversity and provide the appropriate level of information. Browse the one corresponding to the STM32 MPU you use.

STM32 MPU devices Associated articles
STM32MP13x lines More info.png STM32MP13 ADC internal peripheral
STM32MP15x lines More info.png STM32MP15 ADC internal peripheral



3 Article purpose[edit]

The purpose of this article is to:

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

4 Peripheral overview[edit]

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

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

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

5 Peripheral usage[edit]

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

5.1 Boot time assignment[edit]

The DAC peripheral is not used at boot time.

5.2 Runtime assignment[edit]

5.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Analog DAC DAC Assignment (single choice)

6 Software frameworks and drivers[edit]

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

7 How to assign and configure the peripheral[edit]

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

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

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

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

8 References[edit]



9 Article purpose[edit]

The purpose of this article is to:

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

10 Peripheral overview[edit]

The DFSDM (Digital Filter for Sigma-Delta Modulator) peripheral is used as a generic ADC. It benefits from external analog frontend interfaces and internal digital filters.
It can be used in various applications[1] such as: audio record with MEMS microphones, energy measurement with STPMS2[2] for electricity meters or motor control...

The DFSDM peripheral provides several features, among which:

  • Serial or parallel input channels:
    • External analog frontend serial interfaces (SPI, manchester coded single wire interface, clock output), for various sigma-delta modulators
    • Alternative Internal digital parallel interfaces (from internal ADC[3] or memory data stream via DMA[4] or CPU)
  • Digital filters, that offers up to 24-bit final ADC resolution
  • Conversions that can be launched continuously, or using various triggers: by software, TIM[5], LPTIM[6], EXTI[7] or synchronously with DFSDM filter 0
  • Event detectors: analog watchdog high/low thresholds, short-circuit detector, extremes detector
  • Break generation to TIM[5] on analog watchdog or short-circuit detector events
DFSDM features Number of channels Number of filters
STM32MP13x lines More info.png 4 2
STM32MP15x lines More info.png 8 6

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

11 Peripheral usage[edit]

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

11.1 Boot time assignment[edit]

The DFSDM peripheral is not used at boot time.

11.2 Runtime assignment[edit]

11.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Analog DFSDM DFSDM Assignment (single choice)

11.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Analog DFSDM DFSDM Assignment (single choice)

12 Software frameworks and drivers[edit]

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

13 How to assign and configure the peripheral[edit]

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

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

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

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

14 How to go further[edit]

See:

  • STM32L4 System Digital Filter for SD Modulators interface[1], online DFSDM training with application examples from STMicroelectronics
  • Getting started with sigma-delta digital interface[8], application note from STMicroelectronics

15 References[edit]


Information about the "VREFBUF internal peripheral" depends on the microprocessor device.

Several articles are created to manage STM32 MPU diversity and provide the appropriate level of information. Browse the one corresponding to the STM32 MPU you use.

STM32 MPU devices Associated articles
STM32MP13x lines More info.png STM32MP13 VREFBUF internal peripheral
STM32MP15x lines More info.png STM32MP15 VREFBUF internal peripheral



16 Article purpose[edit]

The purpose of this article is to:

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

17 Peripheral overview[edit]

The SAI (Serial Audio Interface) peripheral offers a wide set of audio protocols, such as: I2S standards (LSB or MSB-justified), PCM/DSP, TDM and S/PDIF. The SAI contains two independent audio sub-blocks. Each sub-block has its own clock generator and I/O line controller, and can be configured either as transmitter or receiver.

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

18 Peripheral usage[edit]

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

18.1 Boot time assignment[edit]

The SAI peripheral is not used at boot time.

18.2 Runtime assignment[edit]

18.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Audio SAI SAI1 Assignment (single choice)
SAI2 Assignment (single choice)

18.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Audio SAI SAI1 Assignment (single choice)
SAI2 Assignment (single choice)
SAI3 Assignment (single choice)
SAI4 Assignment (single choice)

19 Software frameworks and drivers[edit]

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

20 How to assign and configure the peripheral[edit]

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

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

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

When the Arm® Cortex®-A7 core operates in non-secure access mode, the SAI is controlled by the Linux kernel framework. Refer to SAI Linux driver to drive the SAI through Linux kernel ALSA framework. Refer to Soundcard configuration and SAI device tree configuration to configure the SAI through the Linux kernel device tree[1].

21 How to go further[edit]

STM32H7 SAI training [2] introduces the SAI features and applications. The SAI versions in STM32H7 and STM32MP1 series are very close. In consequence this training is also relevant for STM32MP1 series. The user should refer to the STM32MP13 reference manuals or STM32MP15 reference manuals for a complete description.

22 References[edit]



23 Article purpose[edit]

The purpose of this article is to:

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

24 Peripheral overview[edit]

The SPDIFRX peripheral is designed to receive an S/PDIF flow compliant with IEC-60958 and IEC-61937. The SPDIFRX receiver provides two separated paths to retrieve the audio data and the user and channel information.

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

25 Peripheral usage[edit]

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

25.1 Boot time assignment[edit]

The SPDIFRX peripheral is not used at boot time.

25.2 Runtime assignment[edit]

25.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Audio SPDIFRX SPDIFRX Assignment (single choice)

25.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Audio SPDIFRX SPDIFRX Assignment (single choice)

26 Software frameworks and drivers[edit]

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

Warning white.png Warning
The SPDIFRX peripheral provides WFA (Wait For activity) feature, to start its synchronization process on a valid input signal. Nevertheless, this mechanism does not always protect against false activity detection, in case of noise on the S/PDIF input. On STM32MP15 evaluation board, when no signal is present on S/PDIF connector, the hardware amplification stage can introduce noise, leading to spurious synchronization error interrupts. The number of false activity detection can be decreased by tuning the amplification stage. For details refer to the "Receiving S/PDIF audio stream" application note [1].

27 How to assign and configure the peripheral[edit]

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

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

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

When the Arm® Cortex®-A7 core operates in non-secure access mode, the SPDIFRX is controlled by the Linux kernel framework. Refer to the SPDIFRX Linux driver to drive the SPDIFRX through Linux kernel ALSA framework. Refer to Soundcard configuration and SPDIFRX device tree configuration to configure the SPDIFRX through Linux kernel Device tree.

28 How to go further[edit]

The STM32H7 SPDIFRX training [2], introduces the STM32 S/PDIF Receiver interface on the STM32H7. This training also applies to the STM32 MPU SPDIFRX internal peripheral.

The "Receiving S/PDIF audio stream" application note [1] describes electrical interfaces to properly connect the S/PDIF stream generated by an external device to the SPDIFRX peripheralv, for STM32F4/F7/H7 series. This application note also applies to the STM32 MPU SPDIFRX internal peripheral.

29 References[edit]



30 Article purpose[edit]

The purpose of this article is to:

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

31 Peripheral overview[edit]

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

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

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

  • P1_TO_P2 subchannel
  • P2_TO_P1 subchannel

A subchannel consists in:

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


IPCC peripheral.png
The IPCC supports the following channel operating modes:

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

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

32 Peripheral usage[edit]

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

32.1 Boot time assignment[edit]

The IPCC peripheral is not used at boot time.

32.2 Runtime assignment[edit]

32.2.1 On STM32MP15x lines More info.png[edit]

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

  • IPCC processor 1 interface is assigned to Arm® Cortex®-A7 non-secure context.
  • IPCC processor 2 interface is assigned to Arm® Cortex®-M4 context.


IPCC overview.png

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

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Coprocessor IPCC IPCC Shared (none or both)

33 Software frameworks and drivers[edit]

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

34 How to assign and configure the peripheral[edit]

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

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

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

The IPCC peripheral is shared between the Arm Cortex-A and Cortex-M contexts. A particular attention must therefore be paid to have a complementary configuration on both contexts. In STMicroelectronics distribution, the IPCC is configured as described below. To ensure the coherency of the system, it is recommended to keep this configuration unchanged in your implementation.

  • Processor interface
Processor interface Context
Cortex-A7 non-secure
(Linux)
Cortex-M4
(STM32Cube)
Processor 1 interface
Processor 2 interface
  • Channel allocation
Channel Mode Usage Software client frameworks
Cortex-A7 non-secure
(Linux)
Cortex-M4
(STM32Cube)
Channel 1 Full-duplex communication RPMsg transfer from Cortex-M to Cortex-A
  • The Cortex-M core uses this channel to indicate that a message is available
  • The Cortex-A core uses this channel to indicate that the message is treated
RPMsg framework OpenAMP
Channel 2 Full-duplex communication RPMsg transfer from Cortex-A to Cortex-M
  • The Cortex-A core uses this channel to indicate that a message is available
  • The Cortex-M core uses this channel to indicate that the message is treated
RPmsg framework OpenAMP
Channel 3 Simplex communication Cortex-M4 shutdown request RemoteProc framework CprocSync cube utility
Channel 4 free
Channel 5 free
Channel 6 free


Applicable for STM32MP15x lines

35 Article purpose[edit]

The purpose of this article is to:

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

36 Peripheral overview[edit]

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

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

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

37 Peripheral usage[edit]

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

37.1 Boot time assignment[edit]

37.1.1 On STM32MP15x lines More info.png[edit]

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

Click on the right to expand the legend...

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

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

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

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

37.2 Runtime assignment[edit]

37.2.1 On STM32MP15x lines More info.png[edit]

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

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


Click on 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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Coprocessor HSEM HSEM

38 Software frameworks and drivers[edit]

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

39 How to assign and configure the peripheral[edit]

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

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

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

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



40 Article purpose[edit]

The purpose of this article is to:

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

41 Peripheral overview[edit]

The RTC peripheral is used to provide the date and clock to the application. It supports programmable alarms and wake up capabilities.

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

42 Peripheral usage[edit]

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

42.1 Boot time assignment[edit]

42.1.1 On STM32MP1 series[edit]

By default after a backup domain power-on reset (performed at boot time), all RTC registers can be read or written in both secure and non-secure modes.
In OpenSTLinux distribution, the first stage bootloader (FSBL, running in secure mode) keeps this default configuration, leaving full control to Linux® at runtime.

The RTC peripheral is able to generate two interrupts:

  • A secure interrupt, connected to the Arm® Cortex®-A7 GIC, not used in OpenSTLinux distribution.
  • A non-secure interrupt, connected both to Arm® Cortex®-A7 GIC and Cortex-M4 NVIC (STM32MP15x lines More info.png only): this interrupt is used on Linux® and by default in OpenSTLinux distribution.

The RTC peripheral is part of the backup domain which reset and clock are controlled via the RCC by the first stage bootloader (FSBL, running in secure mode) at boot time.
The RTC reset occurs when the backup domain is reset. To avoid clearing the TAMP register contents, this is only done on cold boot, not on wake up.

Click on the right to expand the legend...

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

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

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

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

42.2 Runtime assignment[edit]

42.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core RTC RTC RTC is mandatory to resynchronize STGEN after exiting low-power modes.

42.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core RTC RTC RTC is mandatory to resynchronize STGEN after exiting low-power modes.

43 Software frameworks and drivers[edit]

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

44 How to assign and configure the peripheral[edit]

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

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

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

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



45 Article purpose[edit]

The purpose of this article is to:

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

46 Peripheral overview[edit]

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 either HSI(High Speed Internal oscillator) or HSE(High Speed External oscillator). During boot phase, STGEN is clocked by HSI until HSE is setup. This should be done at an early stage. Caution is needed when switching from one source to another as the STGEN counter must be updated according to the new frequency. Otherwise, the time reference will be incorrect.

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

  • STGENC for the control: secure port,
  • STGENR for the read-only access: non secure port.

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

47 Peripheral usage[edit]

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

47.1 Boot time assignment[edit]

47.1.1 On STM32MP1 series[edit]

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


Click on the right to expand the legend...

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

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

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

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

47.2 Runtime assignment[edit]

47.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

47.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core STGEN STGEN

48 Software frameworks and drivers[edit]

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

Linux®/ U-Boot use the Arm Cortex-A7 generic timer that gets its counter from the STGEN, but this is transparent at runtime: therefore, there is no framework or driver to notice for these components.

In OP-TEE, the STGEN's counter value is saved/restored during low-power sequences to keep the platform time coherency. The STGEN configuration is done by TF-A. The frequency of the counter is restored in TF-A as well.

49 How to assign and configure the peripheral[edit]

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

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

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

50 References[edit]



51 Article purpose[edit]

The purpose of this article is to:

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

52 Peripheral overview[edit]

The SYSCFG peripheral is used to configure various system aspects like IOs compensation, Ethernet clocking path, …

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

53 Peripheral usage[edit]

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

53.1 Boot time assignment[edit]

53.1.1 On STM32MP1 series[edit]

The SYSCFG peripheral is configured by TF-A and U-Boot at boot time.

Click on the right to expand the legend...

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

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

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

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

53.2 Runtime assignment[edit]

53.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

53.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core SYSCFG SYSCFG

54 Software frameworks and drivers[edit]

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

Linux and STM32Cube can directly change the SYSCFG at runtime from various drivers.

  • Linux®: for example, Linux I2C driver uses the syscon framework[1] to enable the I2C fast mode plus (FM+) in the SYSCFG for the instances allocated to itself
  • STM32Cube: for example, I2C HAL driver uses its SYSCFG HAL driver to do the same on the instances allocated to itself

55 How to assign and configure the peripheral[edit]

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

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

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

56 References[edit]



57 Article purpose[edit]

The purpose of this article is to:

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

58 Peripheral overview[edit]

The DMA peripheral is used to perform direct accesses from/to a device or a memory. Each DMA instance supports 8 channels. The selection of the device connected to each DMA channel and controlling the DMA transfers is done via the DMAMUX.

Note: Directly accessing DDR from the DMA is not recommended for high-bandwith or latency-critical transfers. This means that DMA transfers configured by the Arm® Cortex®-A7 operating system, that usually target buffers in external memory, require a hardware mechanism to chain the DMA and a MDMA channel in order to achieve the following flow:

DDR<-> MDMA <-> MCU SRAM <-> DMA <-> device

This feature was already present on STM32H7 microcontroller series. It is documented in application note AN5001[1]. Linux® support is also documented in Linux® Kernel documentation, STM32 DMA-MDMA chaining[2].

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

59 Peripheral usage[edit]

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

59.1 Boot time assignment[edit]

The DMA peripheral is not used at boot time.

59.2 Runtime assignment[edit]

59.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA DMA DMA1 Assignment (single choice)
DMA2 Assignment (single choice)
DMA3 Assignment (single choice)

59.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/DMA DMA DMA1 Assignment (single choice)
DMA2 Assignment (single choice)

60 Software frameworks and drivers[edit]

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

61 How to assign and configure the peripheral[edit]

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

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

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

62 References[edit]



63 Article purpose[edit]

The purpose of this article is to:

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

64 Peripheral overview[edit]

The DMAMUX peripheral is used to perform requestor line (or device controller) selection for each channel from DMA instances:

  • In STM32MP13x lines More info.png, there is a first DMAMUX instance to cover both DMA1 and DMA2, and second DMAMUX instance to cover DMA3.
  • In STM32MP15x lines More info.png, there is a single DMAMUX instance to cover both DMA1 and DMA2.

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

65 Peripheral usage[edit]

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

65.1 Boot time assignment[edit]

The DMAMUX peripheral is not used at boot time.

65.2 Runtime assignment[edit]

65.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA DMAMUX DMAMUX1 Assignment (single choice)
DMAMUX2 Assignment (single choice)

65.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/DMA DMAMUX DMAMUX Shareable (multiple choices supported)

66 Software frameworks and drivers[edit]

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

67 How to assign and configure the peripheral[edit]

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

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

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



68 Article purpose[edit]

The purpose of this article is to:

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

69 Peripheral overview[edit]

The MDMA peripheral is used to perform high-speed data transfers between memory and memory or between peripherals and memory. The MDMA controller offers 32 channels. The selection of the device connected to each channel and controlling DMA transfers is done in MDMA peripheral.

Among all the requestor lines described in the reference manual, DMA channels are the only lines that allow to perform transfers with chained DMA and MDMA (refer to DMA internal peripheral article). As a result, when a device is not connected to the MDMA, it is anyway possible to operate in DMA mode via the DMA controller and chain DMA and MDMA.

The MDMA is a secure peripheral. This means that it performs each transfer in the context of the master that requested it:

  • a transfer requested by the Arm® Cortex®-A7 non-secure core propagates non-secure accesses to the targeted device and/or memory.
  • a transfer requested by Arm Cortex-A7 secure core propagates secure accesses to the targeted device and/or memory.

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

70 Peripheral usage[edit]

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

70.1 Boot time assignment[edit]

The MDMA peripheral is not used at boot time.

70.2 Runtime assignment[edit]

70.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA MDMA MDMA Shareable (multiple choices supported)

70.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/DMA MDMA MDMA Shareable (multiple choices supported)

71 Software frameworks and drivers[edit]

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

STM32CubeMX allows to distinguish between non-secure and secure channels, among all the available channels.

On STM32MP15x lines More info.png, the MDMA is visible from the Arm Cortex-M4 core. However, it is not supported in this context by STM32MPU Embedded Software distribution.

72 How to assign and configure the peripheral[edit]

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

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

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



73 Article purpose[edit]

The purpose of this article is to:

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

74 Peripheral overview[edit]

The EXTI peripheral is used to get an interrupt when a GPIO is toggling. It can also wake up the system from Stop low power mode, by means of the PWR internal peripheral when a wake up event occurs, before (eventualy - see the note below) propagating an interrupt to the client processor (Cortex-A7 GIC or Cortex-M4 NVIC in case of STM32MP15). The wake up events can be internal (from other IPs clocked by the LSE, LSI or HSI from RCC), or external (from GPIO).

Notice that:

  • Up to 16 GPIO pins can be configured as external interrupts: for each index between 0 and 15, one EXTI can be selected among all banks (EXTI<index> = GPIO<one_bank><index>).
  • On STM32MP13x lines More info.png: The 16 GPIO and one internal peripheral events ( AVD/PVD), can generate interrupts connected to the GIC. All the other internal peripheral events can wake up the system, but the EXTI does not generate any interrupt to the GIC; in such cases, another peripheral interrupt has to be used as a trigger via the GIC.
  • On STM32MP15x lines More info.png: The 16 GPIO and 5 internal peripheral events (AVD/PVD, CPU1 SEV, CPU2 SEV, WWDG1 reset, CPU2 SYSRESETREQ) can generate interrupts connected to the GIC and NVIC. All the other internal peripheral events can wake up the system, but the EXTI does not generate any interrupt to the GIC or NVIC for them; in such cases, another peripheral interrupt has to be used as a trigger via the GIC or NVIC.
  • By default, at reset, all EXTI wake up events are non-secure.

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

75 Peripheral usage[edit]

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

75.1 Boot time assignment[edit]

The EXTI peripheral is not used at boot time, but is configured during Linux initialization.

75.1.1 On STM32MP15x lines More info.png[edit]

Since wake-up event configuration is done via register bit-field reads and writes, concurrent accesses from Linux and the coprocessor are not possible at boot time:

  • Linux configures all EXTI events during their respective consumer driver probing
  • The coprocessor uses the resource management mechanisms to request and configure the EXTI events it needs.

75.2 Runtime assignment[edit]

75.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Interrupts EXTI EXTI

75.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Interrupts EXTI EXTI Shared
Info white.png Information
The EXTI peripheral is not listed in STM32CubeMX peripherals list because its configuration is partly embedded in the Device tree (for all internal EXTI sources, coming from peripherals with wake up capabilities) and completed with the GPIO configuration that comes from STM32CubeMX pinout view

The OP-TEE EXTI driver is not activated and not used by OpenSTLinux on STM32MP15x lines More info.png.

76 Software frameworks and drivers[edit]

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


77 How to assign and configure the peripheral[edit]

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

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

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

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



78 Article purpose[edit]

The purpose of this article is to:

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

79 Peripheral overview[edit]

The GIC peripheral is the Arm® Cortex®-A7 interrupt controller.
It is consequently not accessible from the Arm® Cortex®-M4 core on STM32MP15x lines More info.png.

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

80 Peripheral usage[edit]

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

80.1 Boot time assignment[edit]

80.1.1 On STM32MP1 series[edit]

The GIC peripheral is not used at boot time.

80.2 Runtime assignment[edit]

80.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Interrupts GIC GIC

80.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Interrupts GIC GIC

81 Software frameworks and drivers[edit]

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

82 How to assign and configure the peripheral[edit]

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

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

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



83 Article purpose[edit]

The purpose of this article is to:

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

84 Peripheral overview[edit]

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

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

85 Peripheral usage[edit]

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

85.1 Boot time assignment[edit]

The NVIC peripheral is not used at boot time.

85.2 Runtime assignment[edit]

85.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Interrupts NVIC NVIC

86 Software frameworks and drivers[edit]

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

87 How to assign and configure the peripheral[edit]

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

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

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



88 Article purpose[edit]

The purpose of this article is to:

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

89 Peripheral overview[edit]

The GPIO peripheral is used to configure the device IO ports, also called pins or pads.

On STM32MP13x lines More info.png, each GPIO instance controls 16 pins (for GPIOA to GPIOG), 15 pins (for GPIOH) or 8 pins (for GPIOI).
On STM32MP15x lines More info.png, each GPIO instance controls 16 pins (for GPIOA to GPIOJ) or 8 pins (for GPIOK and GPIOZ).

Every IO port implements the logic shown in the image below, taken from STM32MP15 reference manuals (and the same exists in STM32MP13 reference manuals):

  • The IO pin (on the right) is the physical connection to a chip external ball, soldered on the PCB. The link between each GPIO pin and each ball of the package is given in the datasheet (Datasheets for STM32MP13x lines More info.png and Datasheets for STM32MP15x lines More info.png).
  • The Read and Write accesses allow the processor (Arm® Cortex®-A7 for for STM32MP1 series or Arm® Cortex®-M4 for for STM32MP15x lines More info.png) to configure the peripheral, control the IO pin and get its status.
  • Alternate function (AF) links allow to connect the IO port to an internal peripheral digital line. In such a case, the IO direction is given by the line purpose: for instance, UART transmit line (TX) is an output.
  • Analog links allow to connect the IO port to an internal peripheral analog line. In such a case, the IO direction is given by the line purpose: for instance, ADC input line is an input.

IO port.png

Note:
  • the pull-up and pull-down resistors are disabled (by hardware) in analog mode.
  • at reset, all pins are set in analog input mode to protect the device and minimize the power consumption. All unused pins should be kept in this state.


The pin configuration done by the software consists in:

  • setting the pin mode in the GPIOx_MODER register:
    • input or output if the pin is used as general purpose (GPIO), controlled by software.
    • analog.
    • alternate function (AF).
  • selecting the alternate function in the GPIOx_AFRH/L register (only when the pin mode is AF):
    • each IO port can support up to 16 alternate functions that are documented in the datasheet (Datasheets for STM32MP13x lines More info.png and Datasheets for STM32MP15x lines More info.png).
  • setting the pin characteristics:
    • no pull-up and no pull-down or pull-up or pull-down in the GPIOx_PUPDR register, needs to be selected to be coherent with the hardware schematics.
    • push-pull or open-drain in the GPIOx_OTYPER register, needs to be selected to be coherent with the hardware schematics.
    • output speed in the GPIOx_OSPEEDR register needs to be tuned to achieve the expected level of performance (rising and falling times) while limiting electromagnetic interferences (EMI) and overconsumption. As example, the table below summarizes the maximum achievable frequency for each supported IO voltage and a 30pF load:
  • On STM32MP13x lines More info.png:
GPIOx_OSPEEDR Meaning VDD=3v3 VDD=1v8
HSLV OFF
VDD=1v8
HSLV ON
b00 Low speed 21 MHz 5 MHz 23 MHz
b01 Medium speed 44 MHz 15 MHz 44 MHz
b10 High speed 100 MHz 37 MHz 90 MHz
b11 Very high speed 166 MHz 50 MHz 133 MHz
  • On STM32MP15x lines More info.png:
GPIOx_OSPEEDR Meaning VDD=3v3 VDD=1v8
HSLV OFF
VDD=1v8
HSLV ON
b00 Low speed 24 MHz 11 MHz 22 MHz
b01 Medium speed 83 MHz 28 MHz 79 MHz
b10 High speed 125 MHz 66 MHz 101 MHz
b11 Very high speed 150 MHz 70 MHz 111 MHz
Notes:
  • More information is available in the IO speed settings chapter of the "Getting started with..." Application Note (AN5474 for STM32MP13x lines More info.png or AN5031 for STM32MP15x lines More info.png.
  • There are different IO types with different characteristics: for instance, all pads are not able to achieve 150 MHz while supplied at 3v3. Refer to the datasheet (Datasheets for STM32MP13x lines More info.png and Datasheets for STM32MP15x lines More info.png) to get the characteristics for each pin.
  • When supplied with VDD=1v8, it is possible to enable the high speed low voltage (HSLV) pad mode for FTH (Five volt Tolerant High speed) and FTE (Five volt Tolerant Extended high speed) IO types on some peripherals via SYSCFG HSLVEN bits. Warning: As it could be destructive if used when VDD>2.7V, thanks to carefully read the HSLVEN bits documentation in STM32MP13 reference manuals or STM32MP15 reference manuals, especially the management of the OTP bit PRODUCT_BELOW_2V5 (for STM32MP1 series) and lock mechanism (for STM32MP13x lines More info.png only).

The table below shows all possible characteristics combinations for each pin mode:

pin mode GPIOx_PUPDR GPIOx_OTYPER GPIOx_OSPEEDR
analog
 
Not applicable Not applicable Not applicable
input (GPIO or AF)
 
no pull-up and no pull-down
or pull-down
or pull-up
Not applicable Not applicable
output (GPIO or AF)
or bi-directional (AF)
push-pull
or open-drain
cf. the table above
Note:
  • 'Not applicable' means that setting this register has no effect but, in any case, there is no risk for the device.
  • On the other hand, leaving a register not initialized whereas it should be, may lead to an unpredictable behavior!

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

90 Peripheral usage[edit]

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

90.1 Boot time assignment[edit]

The STM32CubeMX tool allows to configure in one place the GPIO configuration that is applied at boot time and used at runtime, so it is highly recommended to use it to generate your device tree. Moreover, STM32CubeMX integrates all the information documented in the datasheet (Datasheets for STM32MP13x lines More info.png and Datasheets for STM32MP15x lines More info.png), making this configuration step straightforward.

Since a GPIO configuration is done via atomic registers read and write, concurrent accesses from different cores must be avoided and that is why all GPIO configurations are done by the Arm® Cortex®-A7. The strategy is to progressively initialize the GPIO all along the boot chain, as soon as one boot component needs to use them:

  • Most of the GPIOs used by the ROM code are directly defined in the ROM code but it is possible to change some pins muxing via dedicated words in BSEC.
  • The other boot components are relying on a common binding[1] in the device tree to get the pins configuration:
    • The SSBL and Linux pinctrl only configure non-secure pins.
    • The FSBL configures both secure and non-secure pins.
      • On STM32MP15x lines More info.png, Linux also initializes the GPIO used by the coprocessor, via its resource manager.
90.1.1 On STM32MP13x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/IOs GPIO GPIOA-I The pins can individually be secured
90.1.2 On STM32MP15x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/IOs GPIO GPIOA-K (*) The pins cannot be secured

(*): despite they cannot be secured, the pins can be used by the secure context

GPIOZ The pins can individually be secured

90.2 Runtime assignment[edit]

The GPIO configuration must not be done from different cores to avoid concurrent accesses, but this is not the case for the GPIO using: each core can manipulate IO on its own since dedicated set/clear registers are available for that.

Nevertheless, beyond the boot time, the GPIO configuration also evolves at runtime: while entering in low power mode, some GPIOs may be put back to analog input mode in order to reduce the power consumption. This is done in two times:

  1. the Arm® Cortex®-A7 non-secure takes care of the non-secure pins with Linux IOs pins frameworks.
  2. the Arm® Cortex®-A7 secure takes care of the secure pins behind PSCI secure services.

On wakeup, the boot chain restores the GPIO configuration similarly to what is done at boot time.

90.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/IOs GPIO GPIOA-I The pins can individually be secured
90.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/IOs GPIO GPIOA-K (*) The pins can individually be shared

(*): despite they cannot be secured, the pins can be used by the secure context

GPIOZ The pins can individually be secured or shared

91 Software frameworks and drivers[edit]

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

92 How to assign and configure the peripheral[edit]

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

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

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

In Linux kernel, each GPIO bank is declared as a "gpio-controller" in the device tree and each pin can then be used via two different consumer frameworks:

93 References[edit]



94 Article purpose[edit]

The purpose of this article is to:

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

95 Peripheral overview[edit]

The BKPSRAM internal memory is located in the VSW power domain, allowing it to be supplied during Standby low power mode, or to be switched off.

  • STM32MP13x lines More info.png BKPSRAM is 8 Kbytes wide.
  • STM32MP15x lines More info.png BKPSRAM is 4 Kbytes wide.

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

96 Peripheral usage[edit]

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

96.1 Boot time assignment[edit]

The BKPSRAM internal memory is not used during a cold boot or a wake up from Standby with DDR OFF.

The BKPSRAM internal memory is used by the runtime secure monitor (from the FSBL or the OP-TEE secure OS) during wake-up from Standby low power mode with the DDR in Self-Refresh mode. In that case, the BKPSRAM internal memory contains the secure context that has to be restored before jumping back to Linux execution, in DDR.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/RAM BKPSRAM BKPSRAM

96.2 Runtime assignment[edit]

96.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM BKPSRAM BKPSRAM Assignment (single choice)

96.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/RAM BKPSRAM BKPSRAM Assignment (single choice)

97 Software frameworks and drivers[edit]

The BKPSRAM peripheral can be allocated to either:

  • the Arm® Cortex®-A7 secure to be used by the runtime secure monitor (from the FSBL or the OP-TEE secure OS) to save/restore the secure context before entering/after exiting Standby low power mode with DDR in Self-Refresh mode. Standby low power mode is reached thanks to PSCI [1] secure services (from the FSBL or OP-TEE secure monitor). This is the default assignment.

or

  • the Cortex-A7 non-secure to be used under Linux® as reserved memory, for instance.
Warning white.png Warning
Default OpenSTLinux delivery prevents to define BKPSRAM as non-secure. This requires to modify TF-A source code with one of the following strategies:
  • set BKPSRAM as non-secure and degrade low power modes support, removing Standby mode

or

  • manage on-the-fly secure/non-secure switch of the BKPSRAM in the secure monitor for sequential usage for Standby management and Linux kernel reserved memory

Thus, below are listed the software frameworks and drivers managing the BKPSRAM peripheral for the embedded software components listed in the above tables.

98 How to assign and configure the peripheral[edit]

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

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

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

99 References[edit]



100 Article purpose[edit]

The purpose of this article is to:

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

101 Peripheral overview[edit]

The DDRCTRL and DDRPHYC peripherals are used to configure the physical interface to the external DDR memory. Access to the DDR memory can be filtered via the TZC controller.

Notice that it is possible to perform DDR bandwidth measurement thanks to the DDRPERFM internal peripheral.

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

102 Peripheral usage[edit]

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

102.1 Boot time assignment[edit]

102.1.1 On STM32MP1 series[edit]

The DDRCTRL and DDRPHYC peripherals are kept secure and used by the FSBL to initialize the access to the DDR where it loads the SSBL (U-Boot) for execution.
STMicroelectronics wishes to make the DDR memory configuration as easy as possible, for this reason a dedicated application note[1] has been published and a DDR tuning function is available in STM32CubeMX tool in order to generate the device tree configuration that is given to the FSBL to perform this initialization.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/RAM DDR via DDRCTRL DDR

102.2 Runtime assignment[edit]

The DDRCTRL and DDRPHYC peripherals are accessed at runtime by the secure monitor (from the FSBL or OP-TEE) to put the DDR in self-refresh state before going into Stop or Standby low power mode:

  • On STM32MP13x lines More info.png, OP-TEE is default located in DDR and it jumps into TF-A BL2 FSBL resident code in SYSRAM to configure the DDRCTRL and DDRPHYC
  • On STM32MP15x lines More info.png, OP-TEE is default located in SYSRAM so it embeds the services to configure the DDRCTRL and DDRPHYC

On Standby exit, the ROM code loads the FSBL that again configures the DDRCTRL and DDRPHYC before proceeding with the wake-up procedure.

The TZC controller configures DDR memory access.

102.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM DDR via DDRCTRL DDR

102.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/RAM DDR via DDRCTRL DDR

103 Software frameworks and drivers[edit]

Below are listed the software frameworks and drivers managing the DDRCTRL and DDRPHYC peripherals for the embedded software components listed in the above tables.

104 How to assign and configure the peripheral[edit]

The DDRCTRL and DDRPHYC device tree configuration is generated via STM32CubeMX tool, according to the DDR characteristics (type, size, frequency, speed grade). This configuration is applied during boot time by the FSBL (see boot chain overview).

105 References[edit]


MCU SRAM internal memory


106 Article purpose[edit]

The purpose of this article is to:

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

107 Peripheral overview[edit]

The RETRAM internal memory is 64 Kbytes wide and is physically near to the Arm® Cortex®-M4 for optimized performance from the core. It is located in the VSW power domain, allowing it to be supplied during Standby low power mode, and to retain retention firmware that can be executed very quickly by the Cortex-M4 on wake up from Standby mode.

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

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

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

108 Peripheral usage[edit]

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

108.1 Boot time assignment[edit]

108.1.1 On STM32MP15x lines More info.png[edit]

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


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/RAM RETRAM RETRAM

108.2 Runtime assignment[edit]

108.2.1 On STM32MP15x lines More info.png[edit]

At runtime the RETRAM can be allocated to:

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

or

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

or


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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/RAM RETRAM RETRAM Assignment to the Cortex-M4 if used

109 Software frameworks and drivers[edit]

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

110 How to assign and configure the peripheral[edit]

The peripheral assignment can be done manually.

  • In device trees generation for the OpenSTLinux software components:
  • In the linker script for the STM32CubeMPU Package.



111 Article purpose[edit]

The purpose of this article is to:

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

112 Peripheral overview[edit]

The SYSRAM peripheral is an internal memory peripheral. It is physically located near the Arm® Cortex-A to optimize the core performance.

  • STM32MP13x lines More info.png SYSRAM is 128-Kbyte wide
  • STM32MP15x lines More info.png SYSRAM is 256-Kbyte wide

The SYSRAM is a secure peripheral that it can be split into a secure and a non-secure regions with a 4-Kbyte granularity.

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

113 Peripheral usage[edit]

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

113.1 Boot time assignment[edit]

113.1.1 On STM32MP13x lines More info.png[edit]

The ROM code leaves the SYSRAM secure when it jumps to the entry point of the FSBL that it just loaded into the SYSRAM.
The FSBL does not have to keep any context in SYSRAM when it jumps to the SSBL: each boot stage is independent from the other.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/RAM SYSRAM SYSRAM

113.1.2 On STM32MP15x lines More info.png[edit]

The ROM code mainly configures the SYSRAM as a secure peripheral during its execution. It uses 9 Kbytes located at the beginning of the SYSRAM to store its read and write data. Among them, it stores the boot context in the first 512 bytes of SYSRAM: this boot context contains several information (such as the selected boot device) and pointers to the ROM code exported services (used for secure boot authentication). The ROM code loads the FSBL just after the boot context, into the remaining 247 Kbytes of SYSRAM, and eventually branches the Cortex®-A7 core 0 execution to this FSBL.
The FSBL code can use the whole SYSRAM, but it must take care not to overwrite the boot context before taking it into account.


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/RAM SYSRAM SYSRAM

113.2 Runtime assignment[edit]

113.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM SYSRAM SYSRAM Shareable (multiple choices supported)

Secure section required for low power entry and exit

113.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/RAM SYSRAM SYSRAM Shareable (multiple choices supported)

Secure section required for low power entry and exit

114 Software frameworks and drivers[edit]

In STMicroelectronics distribution, the SYSRAM runtime mapping is the one reached at the end of the boot. It is consequently fully secure and can contain a secure OS (like OP-TEE).

You may decide to split the SYSRAM at runtime. In this case:

  • set the SYSRAM bottom secure, for a Cortex®-A7 secure monitor or a secure OS (such as OP-TEE)

and

  • set the SYSRAM top non-secure, for instance for using in Linux® as reserved memory
Info white.png Information
STM32MP13 embeds an on-the-fly DDR cyphering engine, the DDRMCE internal peripheral, allowing to put secure sensitive code inside the external DDR, instead of the SYSRAM

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

115 How to assign and configure the peripheral[edit]

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

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

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



116 Article purpose[edit]

The purpose of this article is to:

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

117 Peripheral overview[edit]

The LPTIM peripheral is a single channel low-power timer unit, that can continue to run even during low power modes when it selects a clock source that remains active in RCC.

The LPTIM peripheral is available in different configurations. Depending on the selected instance, it can act as PWM, quadrature encoder[1], external event counter or trigger source for other internal peripherals, like ADC[2], DFSDM[3] and DAC[4] (on STM32MP15x lines More info.png).

LPTIM features PWM External event counter
Trigger source
Quadrature encoder
LPTIM1, LPTIM2 Yes Yes Yes
LPTIM3 Yes Yes
LPTIM4, LPTIM5 Yes
  • On STM32MP13x lines More info.png, LPTIM3 can be used for RCC HSE clock source monitoring

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

118 Peripheral usage[edit]

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

118.1 Boot time assignment[edit]

The LPTIM peripheral is not used at boot time.

118.2 Runtime assignment[edit]

118.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Timers LPTIM LPTIM1
LPTIM2 Assignment (single choice)
LPTIM3 Assignment (single choice)
LPTIM3 can be used for HSE monitoring
LPTIM4
LPTIM5

118.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Timers LPTIM LPTIM1 Assignment (single choice)
LPTIM2 Assignment (single choice)
LPTIM3 Assignment (single choice)
LPTIM4 Assignment (single choice)
LPTIM5 Assignment (single choice)

119 Software frameworks and drivers[edit]

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

120 How to assign and configure the peripheral[edit]

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

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

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

For Linux kernel configuration, please refer to LPTIM device tree configuration and STM32 LPTIM Linux driver articles.

121 References[edit]



122 Article purpose[edit]

The purpose of this article is to:

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

123 Peripheral overview[edit]

The TIM peripheral is a multi-channel timer unit, available in various configurations, depending on the instance used. There are basically following categories: advanced-control timers, general-purpose timers and basic timers.

The TIM can provide: PWM with complementary output and dead-time insertion, break detection, input capture[1], quadrature encoder[2] interface (typically used for rotary encoders), trigger source for other internal peripherals like: ADC[3], DFSDM[4]. The full list can be found in Peripherals Interconnect matrix in the reference manual.

The TIM peripheral is available in different configurations, depending on the selected instance :

  • TIM1 and TIM8 are advanced-control timers, with 6 independent channels.
  • TIM2, TIM3, TIM4 and TIM5 are general-purpose timers, with 4 independent channels.
  • TIM12, TIM13 and TIM14 are general-purpose timers, with 2 (TIM12) or 1 (TIM13 and TIM14) independent channels.
  • TIM15, TIM16 and TIM17 are also general-purpose timers, with 2 (TIM15) or 1 (TIM16 and TIM17) independent channels. Compare to TIM12, TIM13 and TIM14, this configuration brings some features that are very useful for motor control (like break function, DMA burst mode control, complementary output with dead-time insertion, ...)
  • TIM6 and TIM7 are basic timers


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

124 Peripheral usage[edit]

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

124.1 Boot time assignment[edit]

The TIM peripheral is not used at boot time.

124.2 Runtime assignment[edit]

124.2.1 On STM32MP13x lines More info.png[edit]

TIM12 and/or TIM15 can be allocated to the Arm® Cortex®-A7 secure core to be controlled in the secure monitor (OP-TEE).
TIM13, TIM14, TIM16 and TIM17 can also be allocated to the Arm® Cortex®-A7 secure context, but it is not supported yet by OpenSTLinux.

Info white.png Information
RCC[5] owns one prescaler per TIM group corresponding to APB1, APB2 and APB6 buses: TIMG1PRE, TIMG2PRE and TIMG3PRE, respectively. TIMG3PRE is securable in RCC. The allocation to Cortex-A7 contexts should ideally be done on a per group basis to get independent clocking setup on each side, this is why the TIM instances groups are shown in the summary table below.


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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Timers TIM TIM1 (APB2 group)
TIM2 (APB1 group)
TIM3 (APB1 group)
TIM4 (APB1 group)
TIM5 (APB1 group)
TIM6 (APB1 group)
TIM7 (APB1 group)
TIM8 (APB2 group)
TIM12 (APB6 group) Assignment (single choice)
TIM12 or TIM15 can be used for HSI/CSI calibration[6]
TIM13 (APB6 group) Assignment (single choice)
TIM14 (APB6 group) Assignment (single choice)
TIM15 (APB6 group) Assignment (single choice)
TIM12 or TIM15 can be used for HSI/CSI calibration[6]
TIM16 (APB6 group) Assignment (single choice)
TIM17 (APB6 group) Assignment (single choice)

124.2.2 On STM32MP15x lines More info.png[edit]

TIM12 and/or TIM15 can be allocated to the Arm® Cortex®-A7 secure core to be controlled in the secure monitor (TF-A or OP-TEE).

Info white.png Information
RCC[5] owns one prescaler per TIM group corresponding to APB1 and APB2 buses: TIMG1PRE and TIMG2PRE, respectively. The allocation to Cortex-A7 or the Cortex-M4 should ideally be done on a per group basis to get independent clocking setup on each side, this is why the TIM instances groups are shown in the summary table below.


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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Timers 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[6]
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[6]
TIM16 (APB2 group) Assignment (single choice)
TIM17 (APB2 group) Assignment (single choice)

125 Software frameworks and drivers[edit]

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

126 How to assign and configure the peripheral[edit]

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

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

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

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

127 How to go further[edit]

STM32 cross-series timer overview[7] application note.

128 References[edit]



129 Article purpose[edit]

The purpose of this article is to:

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

130 Peripheral overview[edit]

The IWDG peripheral is a watchdog unit that can be used to protect application frameworks running on Cortex-A7 from endless loops. This peripheral supports an independent clocking source in order to be able to continue running even when the rest of the system is in low power mode (STOP, STANDBY). Another important feature of this block is the early interrupt feature that allows to trigger an interrupt at a given power supply threshold before reaching the final reset: this gives the opportunity to run a recovery mechanism that will try to revive the system with minimum impact.

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

131 Peripheral usage[edit]

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

131.1 Boot time assignment[edit]

131.1.1 On STM32MP1 series[edit]

Pay attention to the fact that IWDG can be configured to be automatically active at startup (without any software intervention) via BSEC. When this is the case, the watchdog is anyway frozen during ROM code execution but it will start to decrement its counter as soon as the ROM code is left so it is important to reload the watchdog from the boot chain in this case. This behavior is implemented for IWDG2 only in STMicroelectronics distribution.
Notice also that BSEC features some freeze bits that allow to freeze IWDG during platform Stop and Standby low power periods, avoiding to have to wake up (via RTC) for the only purpose of reloading the watchdog.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Core/Watchdog IWDG Any instance

131.2 Runtime assignment[edit]

131.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Watchdog IWDG IWDG1 IWDG1 is secure programmable via ETZPC but this is not used / supported so not shown in STM32CubeMX
IWDG2 Shared (none or both):
  • Cortex-A7 non secure for reload
  • Cortex-A7 secure for early interrupt handling

131.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Watchdog IWDG IWDG1
IWDG2 Shared (none or both):
  • Cortex-A7 non secure for reload
  • Cortex-A7 secure for early interrupt handling

132 Software frameworks and drivers[edit]

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

IWDG1 can be allocated to the Cortex-A7 secure.
IWDG2 can be allocated to the Cortex-A7 non-secure. In this configuration, the secure monitor (from OP-TEE or TF-A) is able to receive IWDG early interrupts that can be used to save some logs before reset or, on STM32MP15x lines More info.png only, in a tentative to reset the Cortex-A7 without interfering with Cortex-M4 execution.

133 How to assign and configure the peripheral[edit]

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

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

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



134 Article purpose[edit]

The purpose of this article is to:

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

135 Peripheral overview[edit]

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

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

136 Peripheral usage[edit]

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

136.1 Boot time assignment[edit]

The WWDG peripheral is not used at boot time.

136.2 Runtime assignment[edit]

136.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Core/Watchdog WWDG WWDG

137 Software frameworks and drivers[edit]

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

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

138 How to assign and configure the peripheral[edit]

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

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

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



139 Article purpose[edit]

The purpose of this article is to:

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

140 Peripheral overview[edit]

The OTG peripheral is used to interconnect other systems with STM32 MPU devices, using USB standard.

The OTG peripheral is a USB Dual-Role Device (DRD) controller that supports both device and host functions.

OTG speeds supported HS (480 Mb/s) FS (12 Mb/s) LS (1.5 Mb/s)
Host mode Yes Yes Yes
Device mode Yes Yes

OTG supports the following PHY interfaces:

OTG peripheral PHY interfaces STM32MP13x lines More info.png STM32MP15x lines More info.png
UTMI interface connected to internal HS PHY for HS/FS/LS speeds Yes Yes
On-chip full-speed PHY for FS/LS speeds Yes

The OTG peripheral is fully compliant with

  • On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification[1], Revision 2.0, May 8, 2009
  • Universal Serial Bus Revision 2.0 Specification[2], Revision 2.0, April 27, 2000
  • USB 2.0 Link Power Management Addendum Engineering Change Notice to the USB 2.0 specification[3], July 16, 2007
  • USB 2.0 Transceiver Macrocell Interface (UTMI) Specification[4], Version 1.05, March 29, 2001
  • UTMI+ Specification[5], Revision 1.0, February 25, 2004

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

141 Peripheral usage[edit]

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

141.1 Boot time assignment[edit]

141.1.1 On STM32MP1 series[edit]

The OTG peripheral is used by ROM code, FSBL and SSBL in device mode (DFU) to support serial boot for flash programming with STM32CubeProgrammer.


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
High speed interface OTG (USB OTG) OTG (USB OTG) The OTG can be used by ROM code, FSBL and SSBL in DFU mode to support serial boot.
It can be used also in U-boot with command line tools.

141.2 Runtime assignment[edit]

141.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface OTG (USB OTG) OTG (USB OTG) Assignment (single choice)

141.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
High speed interface OTG (USB OTG) OTG (USB OTG)

142 Software frameworks and drivers[edit]

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

143 How to assign and configure the peripheral[edit]

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

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

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

For Linux kernel configuration, please refer to OTG device tree configuration.
For U-Boot configuration, please refer to Configure USB OTG node in U-Boot.

144 References[edit]



145 Article purpose[edit]

The purpose of this article is to:

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

146 Peripheral overview[edit]

The USBH peripheral is used to interconnect other systems with STM32 MPU devices, using USB standard.

The USBH peripheral is a USB Host controller supporting high-speed (480 Mbit/s) using an EHCI controller, and full- and low- speeds (12 and 1.5 Mbit/s) through OHCI controller.
The USBH peripheral has two physical ports providing a UTMI+ physical interface, mapped on an on-chip 2-port high-speed UTMI+ PHY.
It supports the standard registers used for low- and full-speed operation (OHCI model) and high-speed operation (EHCI model) and the power management feature called Link Power Management (LPM).

The supported standards are:

  • Universal Serial Bus Revision 2.0 Specification[1], Revision 2.0, April 27, 2000
  • USB 2.0 Link Power Management Addendum Engineering Change Notice to the USB 2.0 specification[2], July 16, 2007
  • Enhanced Host Controller Interface Specification for Universal Serial Bus[3], Revision 1.0, March 12, 2002
  • EHCI v1.1 Addendum[4], August 2008
  • Open Host Controller Interface Specification for USB[5], Release 1.0a, September 14, 1999
  • USB 2.0 Transceiver Macrocell Interface (UTMI) Specification[6], Version 1.05, March 29, 2001
  • UTMI+ Specification[7], Revision 1.0, February 25, 2004

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

147 Peripheral usage[edit]

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

147.1 Boot time assignment[edit]

147.1.1 On STM32MP1 series[edit]

The USBH peripheral is usually not used at boot time. But it may be used by the SSBL (see Boot chain overview), for example to boot a kernel stored on a USB key (mass storage).


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
High speed interface USBH (USB Host) USBH (USB Host)

147.2 Runtime assignment[edit]

147.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface USBH (USB Host) USBH (USB Host)

147.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
High speed interface USBH (USB Host) USBH (USB Host)

148 Software frameworks and drivers[edit]

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

149 How to assign and configure the peripheral[edit]

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

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

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

For Linux kernel and U-boot configuration, please refer to USBH device tree configuration.

150 References[edit]



151 Article purpose[edit]

The purpose of this article is to:

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

152 Peripheral overview[edit]

The USBPHYC peripheral is a block that contains a dual port USB high-speed UTMI+ PHY and a UTMI switch. It makes the interface between:

  • the internal USB controllers (USBH and OTG)
  • the external USB physical lines (DP, DM)

The USBPHYC peripheral:

  • controls a two port high-speed PHY:
    • Port1 connected to the USBH controller
    • Port2 connected via the UTMI+switch to the USBH or to the OTG controller
  • sets the PLL values
  • performs other controls (and monitoring) on the PHY.

USBPHYC.png

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

153 Peripheral usage[edit]

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

153.1 Boot time assignment[edit]

153.1.1 On STM32MP1 series[edit]

USBPHYC instances are boot devices that support Flash programming with STM32CubeProgrammer.

The USBPHYC peripheral is used by ROM code, FSBL and SSBL when using OTG in Device mode (DFU).


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
High speed interface USBPHYC (USB HS PHY controller) USBPHYC (USB HS PHY controller) The USBPHYC can be used by ROM code, FSBL and SSBL in DFU mode to support serial boot.
It can be used also in U-boot by OTG and USBH with command line tools.

153.2 Runtime assignment[edit]

153.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface USBPHYC (USB HS PHY controller) USBPHYC (USB HS PHY controller) Assignment (single choice)

153.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
High speed interface USBPHYC (USB HS PHY controller) USBPHYC (USB HS PHY controller)

154 Software frameworks and drivers[edit]

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

155 How to assign and configure the peripheral[edit]

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

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

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

For U-boot and Linux kernel configuration, please refer to USBPHYC device tree configuration.



156 Article purpose[edit]

The purpose of this article is to:

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

157 Peripheral overview[edit]

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[1] or i2c-bus.org[2]
For more information about SMBus please refer to this link: SMBus wikipedia[3] or i2c-bus.org[4]

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 STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

158 Peripheral usage[edit]

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

158.1 Boot time assignment[edit]

158.1.1 On STM32MP1 series[edit]

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.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Low speed interface I2C Any instance

158.2 Runtime assignment[edit]

158.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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).
Used for PMIC control on ST boards.
I2C5 Assignment (single choice)

158.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
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)

159 Software frameworks and drivers[edit]

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

160 How to assign and configure the peripheral[edit]

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

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

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

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

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

161 References[edit]



162 Article purpose[edit]

The purpose of this article is to:

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

163 Peripheral overview[edit]

The SPI peripheral is 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 runtime assignment chapter to check I2S feature support for each SPI instance.

163.1 SPI main features[edit]

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

163.2 I2S main features[edit]

Only available for SPI supporting I2S mode.

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

163.3 Specific features[edit]

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 the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

164 Peripheral usage[edit]

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

164.1 Boot time assignment[edit]

The SPI peripheral is not used at boot time.

164.2 Runtime assignment[edit]

164.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

164.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
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)

165 Software frameworks and drivers[edit]

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

166 How to assign and configure the peripheral[edit]

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

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

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

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[1].

167 References[edit]



168 Article purpose[edit]

The purpose of this article is to:

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

169 Peripheral overview[edit]

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.

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

170 Peripheral usage[edit]

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

170.1 Boot time assignment[edit]

170.1.1 On STM32MP1 series[edit]

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

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Low speed interface USART Any instance

170.2 Runtime assignment[edit]

170.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

170.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
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)

171 Software frameworks and drivers[edit]

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

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


172 How to assign and configure the peripheral[edit]

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

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

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

See also additional information in the Serial TTY device tree configuration article for Linux®.

173 How to go further[edit]

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

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

174 References[edit]



175 Article purpose[edit]

The purpose of this article is to:

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

176 Peripheral overview[edit]

The FMC peripheral includes two memory controllers:

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

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

176.1 NOR/PSRAM memory controller (or external bus interface controller)[edit]

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.

176.2 NAND Flash controller[edit]

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.

177 Peripheral usage[edit]

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

177.1 Boot time assignment[edit]

177.1.1 On STM32MP1 series[edit]

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

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Mass storage FMC FMC

177.2 Runtime assignment[edit]

177.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

177.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Mass storage FMC FMC Assignment (single choice)

178 Software frameworks and drivers[edit]

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

179 How to assign and configure the peripheral[edit]

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

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

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

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



180 Article purpose[edit]

The purpose of this article is to:

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

181 Peripheral overview[edit]

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

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

182 Peripheral usage[edit]

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

182.1 Boot time assignment[edit]

182.1.1 On STM32MP1 series[edit]

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

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Mass storage QUADSPI QUADSPI

182.2 Runtime assignment[edit]

182.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

182.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Mass storage QUADSPI QUADSPI Assignment (single choice)

183 Software frameworks and drivers[edit]

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

184 How to assign and configure the peripheral[edit]

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

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

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

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



185 Article purpose[edit]

The purpose of this article is to:

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

186 Peripheral overview[edit]

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

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

187 Peripheral usage[edit]

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

187.1 Boot time assignment[edit]

187.1.1 On STM32MP1 series[edit]

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.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Mass storage SDMMC SDMMC1
SDMMC2

187.2 Runtime assignment[edit]

187.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

187.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Mass storage SDMMC SDMMC1
SDMMC2
SDMMC3 Assignment (single choice)

188 Software frameworks and drivers[edit]

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

189 How to assign and configure the peripheral[edit]

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

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

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

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



190 Article purpose[edit]

The purpose of this article is to:

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

191 Peripheral overview[edit]

The ETH peripheral 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.

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 the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

192 Peripheral usage[edit]

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

192.1 Boot time assignment[edit]

192.1.1 On STM32MP1 series[edit]

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.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Networking ETH Any instance Assignment (single choice)

192.2 Runtime assignment[edit]

192.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

192.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Networking ETH ETH Assignment (single choice)

193 Software frameworks and drivers[edit]

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

194 How to assign and configure the peripheral[edit]

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

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

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

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.



195 Article purpose[edit]

The purpose of this article is to:

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

196 Peripheral overview[edit]

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

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 the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented.

197 Peripheral usage[edit]

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

197.1 Boot time assignment[edit]

The FDCAN peripheral is not used at boot time.

197.2 Runtime assignment[edit]

197.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

197.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Networking FDCAN FDCAN1 Assignment (single choice)
FDCAN2 Assignment (single choice)

198 Software frameworks and drivers[edit]

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

199 How to assign and configure the peripheral[edit]

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

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

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

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.

200 References[edit]

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



201 Article purpose[edit]

The purpose of this article is to:

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

202 Peripheral overview[edit]

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.

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

203 Peripheral usage[edit]

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

203.1 Boot time assignment[edit]

The DTS peripheral is not used at boot time.

203.2 Runtime assignment[edit]

203.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

203.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Power & Thermal DTS DTS

204 Software frameworks and drivers[edit]

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

205 How to assign and configure the peripheral[edit]

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

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

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



Information about the "PWR internal peripheral" depends on the microprocessor device.

Several articles have been created to manage STM32 MPU diversity and provide the relevant level of information. Browse the one corresponding to the STM32 MPU you use.

STM32 MPU devices Associated articles
STM32MP13x lines More info.png STM32MP13 PWR internal peripheral
STM32MP15x lines More info.png STM32MP15 PWR internal peripheral



206 Article purpose[edit]

The purpose of this article is to:

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

207 Peripheral overview[edit]

The RCC peripheral is used to control the internal peripherals, as well as the reset signals and clock distribution. The RCC gets several internal (LSI, HSI and CSI) and external (LSE and HSE) clocks. They are used as clock sources for the hardware blocks, either directly or indirectly, via the four PLLs (PLL1, PLL2, PLL3 and PLL4) that allow to achieve high frequencies.

The RCC is a secure peripheral. There are two levels of security, which are controlled via two bits in the RCC_TZCR register (only accessible in secure mode):

  • TZEN allows to set some RCC registers in secure mode, in particular registers for configuring PLL1 and PLL2, in order to secure a TrustZone perimeter for the Cortex®-A7 secure core and its peripherals.
  • MCKPROT allows extending the TZEN secure clock control perimeter to PLL3 and to the MCU subsystem, so to the Cortex®-M4 and its bus clock.

Please note that all RCC registers can be read from the non-secure world.

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

208 Peripheral usage[edit]

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

208.1 Boot time assignment[edit]

208.1.1 On STM32MP1 series[edit]

The RCC security level differs for each boot chain:

  • the trusted boot chain sets TZEN to 1 and MCKPROT to 0
  • the basic boot chain sets TZEN to 0 and MCKPROT to 0

The RCC is used by all the boot components: the ROM code, the FSBL, the SSBL and up to the Linux® kernel.) Each component is able to reset and gate internal peripherals

FSBL is responsible to make an minimal configuration tree initialization for the SSBL. Then the main initialization step is performed by the SSBL: it consists in configuring all the input clocks, the PLL and the clock sources that are selected as kernel clocks for all peripherals. The whole configuration is carried out by the device tree. The clock tree for the STM32MP13x lines More info.png is specified here. The clock tree for the STM32MP15x lines More info.png is specified here.

The STM32CubeMX tool allows configuring in one place the clock tree that will be applied at boot time and used at runtime, so it is highly recommended to use it to generate your device tree. Moreover, the STM32CubeMX integrates all the information documented in the STM32 MPU reference manuals, making this configuration step straightforward.


Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Power & Thermal RCC RCC

208.2 Runtime assignment[edit]

The Arm® Cortex®-A7 secure core controls all the secure registers (refer to TZEN and MCKPROT bit descriptions) through the RCC OP-TEE driver. The access to some secure registers from the Cortex®-A7 non-secure core can be achieved via runtime secure services implemented in the secure monitor (from the OP-TEE if it is present, otherwise from the TF-A).


208.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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 RCC RCC

208.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Power & Thermal RCC RCC

209 Software frameworks and drivers[edit]

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

210 How to assign and configure the peripheral[edit]

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

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

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

211 How to go further[edit]

The RCC is interfaced with the HDP internal peripheral, thus offering the flexibility to monitor the main RCC state signals on the debug pins.

Please refer to the STM32MPU reference manuals for the full list of signals that can be monitored.

212 References[edit]



213 Article purpose[edit]

The purpose of this article is to:

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

214 Peripheral overview[edit]

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.

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

215 Peripheral usage[edit]

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

215.1 Boot time assignment[edit]

215.1.1 On STM32MP1 series[edit]

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

Click on the right to expand the legend...

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

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

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

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

215.2 Runtime assignment[edit]

215.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

215.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security BSEC BSEC Cortex-M4 can read BSEC shadow register (BSEC_OTP_DATAx) to read a lower OTP value

216 Software frameworks and drivers[edit]

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

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 using OP-TEE BSEC PTA (see OP-TEE device tree for details)

217 How to assign and configure the peripheral[edit]

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

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

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

See also additional information in the BSEC device tree configuration article.



218 Article purpose[edit]

The purpose of this article is to:

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

219 Peripheral overview[edit]

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

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

220 Peripheral usage[edit]

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

220.1 Boot time assignment[edit]

The CRC peripheral is not used at boot time.

220.2 Runtime assignment[edit]

220.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

220.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security CRC CRC1
CRC2

221 Software frameworks and drivers[edit]

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

222 How to assign and configure the peripheral[edit]

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

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

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



223 Article purpose[edit]

The purpose of this article is to:

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

224 Peripheral overview[edit]

The CRYP peripheral provides hardware acceleration to encrypt or decrypt data using the DES[1], TDES[2] or AES[3] algorithms. It also supports multiple key sizes and chaining modes.

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

225 Peripheral usage[edit]

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

225.1 Boot time assignment[edit]

225.1.1 On STM32MP13x lines More info.png[edit]

CRYP could be used in ROM code during boot process for FSBL decryption.

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Security CRYP CRYP Boot ROM allocation is managed with the bit 7 in OTP 9

225.1.2 On STM32MP15x lines More info.png[edit]

The CRYP peripheral is not used at boot time.

225.2 Runtime assignment[edit]

225.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Security CRYP CRYP Assignment (single choice)

225.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security CRYP CRYP1 Assignment (single choice)
CRYP2

226 Software frameworks and drivers[edit]

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

227 How to assign and configure the peripheral[edit]

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

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

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

228 References[edit]



229 Article purpose[edit]

The purpose of this article is to:

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

230 Peripheral overview[edit]

The ETZPC peripheral is used to configure TrustZone security in a STM32 MPU device. That STM32 MPU device has bus masters and slaves with programmable-security attributes (securable resources) such as:

  • on-chip RAM/ROM with programmable secure region size
  • AHB and APB peripherals to be made secure
  • AHB masters to be granted secure rights

Refer to the STM32 MPU reference manuals for the complete list of features, and to the software frameworks and drivers, introduced below, to see which features are implemented. Securable peripherals list varies from one platform to another.

230.1 On STM32MP15x lines More info.png[edit]

The ETZPC peripheral also allows peripheral isolation. With MCU isolation, some peripherals can be assigned to Cortex-M4 context execution only. Those peripherals will not be accessible for Cortex-A7 contexts (secure and non-secure).

231 Peripheral usage[edit]

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

ETZPC peripheral is write-secure only. TF-A configures it at boot time but its final boot configuration is set by OP-TEE during its initialization and managed by OP-TEE at runtime. Linux kernel and U-Boot supports the ETZPC as a firewall bus. This firewall bus is responsible for checking the ETZPC configuration to determine which hardware resources can be used or not.

231.1 Boot time assignment[edit]

231.1.1 On STM32MP1 series[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Security ETZPC Any instance ETZPC configuration is set by OP-TEE

231.2 Runtime assignment[edit]

231.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

231.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security ETZPC ETZPC

232 Software frameworks and drivers[edit]

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

233 How to assign and configure the peripheral[edit]

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

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

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

This configuration is done in OP-TEE, through device tree.
Refer to ETZPC device tree configuration.

234 How to go further[edit]

The ETZPC is an STMicroelectronics extension of the Arm® peripheral: TrustZone Protection Controller[1]

235 References[edit]


Applicable for STM32MP13x lines, STM32MP15x lines


236 Article purpose[edit]

The purpose of this article is to:

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

237 Peripheral overview[edit]

The HASH peripheral is used to compute a message digest.
The HASH peripheral is also able to give the HMAC[1] used for authentication using the same algorithm support.

237.1 On STM32MP13x lines More info.png[edit]

Secure Hash algorithms supports:

  • SHA-1 [2]
  • SHA-2 :
    • SHA-224
    • SHA-256
    • SHA-384
    • SHA-512
    • Truncated output SHA-512/224, SHA512/256
  • SHA-3 [3]:
    • SHA3-224
    • SHA3-256
    • SHA3-384
    • SHA3-512
    • SHAKE128 and 256
    • Keccak-based functions
  • HMAC support for all supported algorithm

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

237.2 On STM32MP15x lines More info.png[edit]

Secure Hash algorithms supports:

  • MD5 [4]
  • SHA-1 [2]
  • SHA-2 :
    • SHA-224
    • SHA-256
  • HMAC support for all supported algorithm

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

238 Peripheral usage[edit]

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

238.1 Boot time assignment[edit]

The HASH instance is used as boot device to support binary authentication.

238.1.1 On STM32MP13x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

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

238.1.2 On STM32MP15x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Security HASH HASH1
HASH2 not used at boot time.

238.2 Runtime assignment[edit]

238.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Security HASH HASH Assignment (single choice)

238.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security HASH HASH1 Assignment (single choice)
HASH2

239 Software frameworks and drivers[edit]

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

240 How to assign and configure the peripheral[edit]

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

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

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

241 References[edit]



242 Article purpose[edit]

The purpose of this article is to:

  • Briefly introduce the RNG peripheral and its main features,
  • Indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
  • List the software frameworks and drivers managing the peripheral,
  • Explain how to configure the peripheral.

243 Peripheral overview[edit]

The RNG peripheral is used to provide 32-bit random numbers.

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

The RNG can be assigned to non-secure or secure world (default behavior). If the RNG is assigned to the secure world then the non-secure world can request random numbers through the OP-TEE RNG PTA. More information about this mechanism can be found in OP-TEE documentation [1]. Else, the software component uses its RNG driver directly.

What is applicable for the Linux Kernel is applicable for U-Boot.

RNG implementations overview

244 Peripheral usage[edit]

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

The hardware RNG peripheral for Arm® Cortex®-A processor is default assigned to OP-TEE, for which the driver and interfaces are maintained. This is the default and recommended setup.

It is still possible to assign the RNG to the Linux Kernel, but it is necessary to deactivate it in OP-TEE device tree and activate it in the Linux kernel device tree, declare it as a firewall exception in the OP-TEE firewall driver and declare your board in the flavorlist-no_rng in the OP-TEE board configuration makefile .

244.1 Boot time assignment[edit]

244.1.1 On STM32MP13x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Security RNG RNG Required for DPA peripheral protection

244.1.2 On STM32MP15x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Security RNG RNG1

244.2 Runtime assignment[edit]

If the Arm® Cortex®-A processor hardware RNG peripheral is assigned to OP-TEE, then the Linux Kernel can request random numbers through the hardware random framework which is interfaced with the OP-TEE RNG Linux driver .

If the Arm® Cortex®-A processor hardware RNG peripheral is assigned to the Linux Kernel, then the Linux Kernel can access it through the hardware random framework which is interfaced with the Linux RNG driver .

244.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Security RNG RNG Assignment (single choice)

244.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security RNG RNG1 Assignment (single choice)
RNG2

245 Software frameworks and drivers[edit]

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

246 How to assign and configure the peripheral[edit]

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

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

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

This configuration is done in OP-TEE, through device tree.
Refer to RNG device tree configuration.

247 References[edit]



248 Article purpose[edit]

The purpose of this article is to:

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

249 Peripheral overview[edit]

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.

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

250 Peripheral usage[edit]

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

250.1 Boot time assignment[edit]

250.1.1 On STM32MP1 series[edit]

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.

Click on the right to expand the legend...

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

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

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

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

250.2 Runtime assignment[edit]

250.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

250.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security TZC TZC

251 Software frameworks and drivers[edit]

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

252 How to assign and configure the peripheral[edit]

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

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

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

See also additional information in the OP-TEE overview article.

253 How to go further[edit]

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

254 References[edit]



255 Article purpose[edit]

The purpose of this article is to:

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

256 Peripheral overview[edit]

The TAMP peripheral is a secure peripheral.

The TAMP peripheral is used to prevent any attempt by an attacker to perform an unauthorized physical or electronic action against the device. It also includes the backup registers that remain powered-on when the platform is switched off.

The TAMP peripheral control the access to the backup registers.

It is important to notice that a tamper event can erase the following secrets:

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

257 Peripheral usage[edit]

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

257.1 Boot time assignment[edit]

The TAMP is used at boot time to share data between the ROM code, FSBL and SSBL: see STM32MP13 backup registers or STM32MP15 backup registers for further information.

257.1.1 On STM32MP1 series[edit]

Click on the right to expand the legend...

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

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

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

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

257.2 Runtime assignment[edit]

TAMP is seen as a system peripheral. The tamper detection and management is, after configuration, non modifiable. TAMP is configured in OP-TEE to manage tamper events.

257.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

257.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Security TAMP TAMP

258 Software frameworks and drivers[edit]

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

259 How to assign and configure the peripheral[edit]

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

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

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

For the Linux kernel configuration, sysconf part, please refer to TAMP device tree configuration.
For the secure configuration, please refer to TAMP device tree configuration and Tamper configuration.

260 References[edit]



261 Article purpose[edit]

The purpose of this article is to:

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

262 Peripheral overview[edit]

The DBGMCU peripheral is used by the boot chain and by OP-TEE to get the device ID and revision, to adapt their behavior accordingly.
The DBGMCU peripheral is also used to configure internal peripherals behavior when one of the available cores enters in debug mode.

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 a watchdog (IWDG) frozen when the Cortex®-A7 enters in debug mode (via a breakpoint or JTAG break) and to avoid getting a watchdog reset during a debug session.

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

263 Peripheral usage[edit]

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

263.1 Boot time assignment[edit]

263.1.1 On STM32MP13x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Trace & Debug DBGMCU DBGMCU

263.1.2 On STM32MP15x lines More info.png[edit]

Click on the right to expand the legend...

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

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

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

Domain Peripheral Boot time allocation Comment
Instance Cortex-A7
secure
(ROM code)
Cortex-A7
secure
(TF-A BL2)
Cortex-A7
non-secure
(U-Boot)
Trace & Debug DBGMCU DBGMCU

263.2 Runtime assignment[edit]

263.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

263.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Trace & Debug DBGMCU DBGMCU

264 Software frameworks and drivers[edit]

There is no software dedicated to the DBGMCU internal peripheral delivered with STM32MPU ecosystem. Nevertheless, debuggers like STM32CubeIDE and OpenOCD use the DBGMCU.

265 How to assign and configure the peripheral[edit]

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

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

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



266 Article purpose[edit]

The purpose of this article is to:

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

267 Peripheral overview[edit]

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.

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

268 Peripheral usage[edit]

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

268.1 Boot time assignment[edit]

The HDP peripheral is not used at boot time.

268.2 Runtime assignment[edit]

268.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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

268.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Trace & Debug HDP HDP

269 Software frameworks and drivers[edit]

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

270 How to assign and configure the peripheral[edit]

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

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

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



271 Article purpose[edit]

The purpose of this article is to:

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

272 Peripheral overview[edit]

The STM peripheral is used to log STM traces into the embedded trace FIFO (ETF). This trace can include hardware events (the list is given in the STM32MP15 reference manuals) or direct 'printf like' log from the Cortex®-A7. Once in the ETF buffer, the trace can be dumped directly from the Cortex®-A7 or to the trace port interface unit (TPIU), connected to an external probe able to decode it.

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

273 Peripheral usage[edit]

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

273.1 Boot time assignment[edit]

273.1.1 On STM32MP1 series[edit]

The STM can be used to debug the boot sequence using an external probe, without any associated embedded software.

273.2 Runtime assignment[edit]

273.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Trace & Debug STM STM

274 Software frameworks and drivers[edit]

The STM can be used to debug the run time application using an external probe, without any associated embedded software.

There is no software dedicated to the STM internal peripheral delivered with the STM32 MPU ecosystem but the STM trace can be captured using an external probe.

275 How to assign and configure the peripheral[edit]

Configuration of the STM is done via JTAG scripts. Those scripts must be built by the user using the STM32MP15 reference manuals .



276 Article purpose[edit]

The purpose of this article is to:

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

277 Peripheral overview[edit]

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

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

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

278 Peripheral usage[edit]

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

278.1 Boot time assignment[edit]

The CEC peripheral is not used at boot time.

278.2 Runtime assignment[edit]

278.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Visual CEC CEC Assignment (single choice)

279 Software frameworks and drivers[edit]

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

280 How to assign and configure the peripheral[edit]

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

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

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

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

281 How to go further[edit]

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

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

282 References[edit]



283 Article purpose[edit]

The purpose of this article is to:

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

284 Peripheral overview[edit]

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

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

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

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

285 Peripheral usage[edit]

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

285.1 Boot time assignment[edit]

The DCMI peripheral is not used at boot time.

285.2 Runtime assignment[edit]

285.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Visual DCMI DCMI Assignment (single choice)

286 Software frameworks and drivers[edit]

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

287 How to assign and configure the peripheral[edit]

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

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

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

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

288 How to go further[edit]

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

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

289 References[edit]



290 Article purpose[edit]

The purpose of this article is to:

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

291 Peripheral overview[edit]

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

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

292 Peripheral usage[edit]

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

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

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

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

  • Pixel data transmission
    • in DSI command mode: not supported by neither U-Boot nor Linux® kernel, use instead the DSI video burst mode.
    • in DSI video mode:
      • burst mode: supported
      • non-burst mode with sync events or pulses: supported with clock constraints to be considered [2].
  • Command transmission (initialization sequence, backlight...)
    • in DSI command mode: supported
    • in DSI video mode:
      • burst mode: supported if there is enough time to send commands before or/and after pixel data [2].
      • non-burst mode with sync events or pulses: supported but there are timing constraints to be considered [2].

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

292.1 Boot time assignment[edit]

292.1.1 On STM32MP15x lines More info.png[edit]

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

Click on the right to expand the legend...

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

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

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

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

292.2 Runtime assignment[edit]

292.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Visual DSI DSI

293 Software frameworks and drivers[edit]

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

294 How to assign and configure the peripheral[edit]

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

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

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

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

295 How to go further[edit]

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

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

295.1 Non-burst mode constraints[edit]

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

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

  • the frequency of the HSE oscillator (the input of the DSI peripheral's PLL);
  • the programmability of the DSI peripheral's PLL;
  • the min and max frequency of the VCO of the DSI peripheral's PLL;
  • the selected bit per pixel.

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

  1. !/bin/bash

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

  1. 24 bpp

byte_per_pixel=3

for i in {1..7}; do

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

done | sort -nu

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

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

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

296 References[edit]



297 Article purpose[edit]

The purpose of this article is to:

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

298 Peripheral overview[edit]

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

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

299 Peripheral usage[edit]

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

299.1 Boot time assignment[edit]

The GPU peripheral is not used at boot time.

299.2 Runtime assignment[edit]

299.2.1 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Visual GPU GPU

300 Software frameworks and drivers[edit]

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

  • Linux®: OpenGL®ES framework

301 How to assign and configure the peripheral[edit]

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

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

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

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

302 How to go further[edit]

Please go through the articles belonging to the GPU category.


Applicable for STM32MP13x lines, STM32MP15x lines

303 Article purpose[edit]

The purpose of this article is to:

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

304 Peripheral overview[edit]

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.

On STM32MP13x lines More info.png, the LTDC layer2 can be set as secure (under ETZPC control), whereas the layer1 is always non-secure. On STM32MP15x lines More info.png, the LTDC is a non-secure peripheral.

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

305 Peripheral usage[edit]

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

305.1 Boot time assignment[edit]

305.1.1 On STM32MP1 series[edit]

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

Click on the right to expand the legend...

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

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

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

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

305.2 Runtime assignment[edit]

305.2.1 On STM32MP13x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possibilities 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)

305.2.2 On STM32MP15x lines More info.png[edit]

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 is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are hardware connected in the device.

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

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

(STM32Cube)
Visual LTDC LTDC

306 Software frameworks and drivers[edit]

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

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.

307 How to assign and configure the peripheral[edit]

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

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

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

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

308 How to go further[edit]

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.

309 References[edit]


|}

310 References[edit]