STM32MP15 peripherals overview

Revision as of 15:26, 13 February 2019 by Gerald Baeza (talk | contribs)

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 "ADC internal peripheral" depends on the microprocessor device.

To manage this diversity and to provide the relevant level of information, several articles have been created. Please browse the one corresponding to the STM32 MPU you use.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 ADC internal peripheral
STM32MP15x STM32MP15 ADC internal peripheral


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


3 Article purpose[edit]

The purpose of this article is to

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

4 Peripheral overview[edit]

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

4.1 Features[edit]

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[5] or memory data stream via DMA[6] 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[7], LPTIM[8], EXTI[9] or synchronously with DFSDM filter 0
  • Event detectors: analog watchdog high/low thresholds, short-circuit detector, extremes detector
  • Break generation to TIM[7] on analog watchdog or short-circuit detector events
DFSDM features Number of channels Number of filters
STM32MP13x lines Warning.png 4 2
STM32MP15x lines More info.png 8 6

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

4.2 Security support[edit]

The DFSDM is a non-secure peripheral.

5 Peripheral usage and associated software[edit]

5.1 Boot time[edit]

The DFSDM is not used at boot time.

5.2 Runtime[edit]

5.2.1 Overview[edit]

The DFSDM can be allocated to:

  • the Arm® Cortex®-A7 non-secure core to be used under Linux® by the IIO or ALSA framework

or

The peripheral assignment chapter describes which peripheral instance can be assigned to which context.

5.2.2 Software frameworks[edit]

5.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Analog DFSDM Linux IIO framework
Linux ALSA framework
5.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Analog DFSDM Linux IIO framework
Linux ALSA framework
STM32Cube DFSDM driver

5.2.3 Peripheral configuration[edit]

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

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

5.2.4 Peripheral assignment[edit]

5.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Analog DFSDM DFSDM Assignment (single choice)
5.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Analog DFSDM DFSDM Assignment (single choice)

6 How to go further[edit]

See:

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

7 References[edit]


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

To manage this diversity and to provide the relevant level of information, several articles have been created. Please browse the one corresponding to the STM32 MPU you use.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 VREFBUF internal peripheral
STM32MP15x STM32MP15 VREFBUF internal peripheral


8 Article purpose[edit]

The purpose of this article is to:

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

9 Peripheral overview[edit]

The SAI (Serial Audio Interface) 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.

9.1 Features[edit]

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

9.2 Security support[edit]

All the SAI instances are non secure peripherals.

10 Peripheral usage and associated software[edit]

10.1 Boot time[edit]

The SAI is not used at boot time.

10.2 Runtime[edit]

10.2.1 Overview[edit]

SAI instances can be allocated to:

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

10.2.2 Software frameworks[edit]

10.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Audio SAI ALSA framework
10.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Audio SAI ALSA framework STM32Cube SAI driver

10.2.3 Peripheral configuration[edit]

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

When the Arm® Cortex®-A7 core operates in non-secure access mode, the 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].

10.2.4 Peripheral assignment[edit]

10.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Audio SAI SAI1 Assignment (single choice)
SAI2 Assignment (single choice)
10.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

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

12 References[edit]


13 Article purpose[edit]

The purpose of this article is to:

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

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

14.1 Features[edit]

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

14.2 Security support[edit]

The SPDFIRX is a non secure peripheral.

15 Peripheral usage and associated software[edit]

15.1 Boot time[edit]

The SPDFIRX is not used at boot time.

15.2 Runtime[edit]

15.2.1 Overview[edit]

The SPDIFRX instance can be allocated to:

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

15.2.2 Software frameworks[edit]

15.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Audio SPDIFRX ALSA framework
15.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Audio SPDIFRX ALSA framework STM32Cube SPDIFRX driver

15.2.3 Peripheral configuration[edit]

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

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

15.2.4 Peripheral assignment[edit]

15.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Audio SPDIFRX SPDIFRX Assignment (single choice)
15.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Audio SPDIFRX SPDIFRX Assignment (single choice)

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

17 References[edit]


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


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


Technical information related to "RTC internal peripheral" depends on the microprocessor device.
Several articles have been created, one per STM32 MPU device, to manage those differences.
You can find information corresponding to the STM32 MPU you use, by clicking on on of articles below.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 RTC internal peripheral
STM32MP15x STM32MP15 RTC internal peripheral


18 Article purpose[edit]

The purpose of this article is to:

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

19 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 ACLK (the AXI bus clock), so caution is needed when this clock is changed; otherwise the operating system (running on the Cortex-A7) might run with a varying reference clock.

19.1 Features[edit]

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

19.2 Security support[edit]

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

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

20 Peripheral usage and associated software[edit]

20.1 Boot time[edit]

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

20.2 Runtime[edit]

20.2.1 Overview[edit]

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

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

20.2.2 Software frameworks[edit]

20.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core STGEN see comment see comment Not applicable as the STGEN peripheral is configured at boot time and not accessed at runtime
20.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core STGEN see comment see comment Not applicable as the STGEN peripheral is configured at boot time and not accessed at runtime

20.2.3 Peripheral configuration[edit]

20.2.4 Peripheral assignment[edit]

20.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core STGEN STGEN
20.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Core STGEN STGEN

21 References[edit]



Technical information related to "SYSCFG internal peripheral" depends on the microprocessor device.
Several articles have been created, one per STM32 MPU device, to manage those differences.
You can find information corresponding to the STM32 MPU you use, by clicking on one of the articles below.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 SYSCFG internal peripheral
STM32MP15x STM32MP15 SYSCFG internal peripheral


22 Article purpose[edit]

The purpose of this article is to:

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

23 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].

23.1 Features[edit]

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

23.2 Security support[edit]

23.2.1 On STM32MP13x lines Warning.png[edit]

DMA1 and DMA2 instances are non-secure peripherals. DMA3 is a secure peripheral.

23.2.2 On STM32MP15x lines More info.png[edit]

DMA1 and DMA2 instances are non-secure peripherals.

24 Peripheral usage and associated software[edit]

24.1 Boot time[edit]

The DMA is not used at boot time.

24.2 Runtime[edit]

24.2.1 Overview[edit]

24.2.1.1 On STM32MP13x lines Warning.png[edit]

DMA1 and DMA2 can be assigned to the Arm® Cortex®-A7 non-secure context to be controlled in Linux® by the dmaengine framework.
DMA3 can be assigned to the Arm® Cortex®-A7 secure context, to be controlled by a DMA OP-TEE driver, not supported yet by OpenSTLinux.

24.2.1.2 On STM32MP15x lines More info.png[edit]

Each DMA instance can be allocated to:

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

or

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

24.2.2 Software frameworks[edit]

24.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/DMA DMA OP-TEE DMA driver Linux dmaengine framework
24.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/DMA DMA Linux dmaengine framework STM32Cube DMA driver

24.2.3 Peripheral configuration[edit]

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

24.2.4 Peripheral assignment[edit]

24.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA DMA DMA1 Assignment (single choice)
DMA2 Assignment (single choice)
DMA3 Assignment (single choice)
24.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

25 References[edit]


26 Article purpose[edit]

The purpose of this article is to:

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

27 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 Warning.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.

27.1 Features[edit]

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

27.2 Security support[edit]

27.2.1 On STM32MP13x lines Warning.png[edit]

The DMAMUX1 is a non-secure peripheral. The DMAMUX2 is a secure peripheral.

27.2.2 On STM32MP15x lines More info.png[edit]

The DMAMUX is a non secure peripheral.

28 Peripheral usage and associated software[edit]

28.1 Boot time[edit]

The DMAMUX is not used at boot time.

28.2 Runtime[edit]

28.2.1 Overview[edit]

28.2.1.1 On STM32MP13x lines Warning.png[edit]

The DMAMUX1 manages DMA1 and DMA2 requestor line selection, so it can be assigned to the Arm® Cortex®-A7 non-secure context to be controlled in Linux® by the dmaengine framework. The DMAMUX2 manages DMA3 requestor line selection, so it can be assigned to the Arm® Cortex®-A7 secure context to be controlled by a DMAMUX OP-TEE driver, not supported yet by OpenSTLinux.

28.2.1.2 On STM32MP15x lines More info.png[edit]

The DMAMUX manages DMA1 and DMA2 requestor line selection via different registers so it is possible to concurrently access to DMAMUX from Cortex®-A7 non-secure and Cortex®-M4 contexts, as far as each core is only configuring the requestor lines for the DMA instances (DMA1 and/or DMA2) assigned to itself.

Finally, DMAMUX can be allocated to:

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

or

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

28.2.2 Software frameworks[edit]

28.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/DMA DMAMUX OP-TEE DMAMUX driver Linux dmaengine framework
28.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/DMA DMAMUX Linux dmaengine framework STM32Cube DMAMUX driver

28.2.3 Peripheral configuration[edit]

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

28.2.4 Peripheral assignment[edit]

28.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA DMAMUX DMAMUX1 Assignment (single choice)
DMAMUX2 Assignment (single choice)
28.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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


29 Article purpose[edit]

The purpose of this article is to:

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

30 Peripheral overview[edit]

The MDMA 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 (accessible via the following paragraph), 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.

30.1 Features[edit]

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

30.2 Security support[edit]

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.

31 Peripheral usage and associated software[edit]

31.1 Boot time[edit]

The MDMA is used at boot time by the FMC.

31.2 Runtime[edit]

31.2.1 Overview[edit]

As stated in the 'Security support' chapter above, the MDMA is a secure peripheral. This means that its channels have to be allocated to:

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

and

  • the Arm Cortex-A7 secure core to be controlled by a MDMA OP-TEE driver, not supported yet by OpenSTLinux.

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.

31.2.2 Software frameworks[edit]

31.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/DMA MDMA OP-TEE MDMA driver Linux dmaengine framework
31.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/DMA MDMA OP-TEE MDMA driver Linux dmaengine framework

31.2.3 Peripheral configuration[edit]

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

31.2.4 Peripheral assignment[edit]

31.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/DMA MDMA MDMA Shareable (multiple choices supported)
31.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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


| rowspan="1" | Core/Interrupts
| rowspan="1" | EXTI
| EXTI
|
| 
| 
| Shareable (multiple choices supported)
|-

32 Article purpose[edit]

The purpose of this article is to

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

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

33.1 Features[edit]

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

33.2 Security support[edit]

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

34 Peripheral usage and associated software[edit]

34.1 Boot time[edit]

The GIC is configured by the FSBL (see Boot chain overview), mainly to define the routing of each interrupt to the secure or non-secure context at runtime.

34.2 Runtime[edit]

34.2.1 Overview[edit]

The GIC is shared between:

  • the Arm® Cortex®-A7 secure core to be used under OP-TEE with the GIC OP-TEE driver (or TF-A secure monitor if the OP-TEE is not present)
  • the Arm® Cortex®-A7 non-secure core to be used under Linux® with the interrupts framework

34.2.2 Software frameworks[edit]

34.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/Interrupts GIC OP-TEE GIC driver Linux interrupt framework
34.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/Interrupts GIC OP-TEE GIC driver Linux interrupt framework

34.2.3 Peripheral configuration[edit]

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

34.2.4 Peripheral assignment[edit]

34.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Interrupts GIC GIC
34.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Core/Interrupts GIC GIC


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


35 Article purpose[edit]

The purpose of this article is to

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

36 Peripheral overview[edit]

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

On STM32MP13x lines Warning.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 Warning.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 Warning.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:
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
Note:
  • More information is available in the IO speed settings chapter of the "Getting started with..." Application Note (AN for STM32MP13x lines Warning.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 Warning.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 Warning.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!

36.1 Features[edit]

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

36.2 Security support[edit]

36.2.1 On STM32MP13x lines Warning.png[edit]

All banks, so GPIOA to GPIOI, are secure aware.

36.2.2 On STM32MP15x lines More info.png[edit]

The GPIOA to GPIOK peripherals are non-secure.
The GPIOZ peripheral is secure aware.

37 Peripheral usage and associated software[edit]

37.1 Boot time[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 Warning.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.

37.2 Runtime[edit]

37.2.1 Overview[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.

Let's come back to the runtime allocation...

The pins of the secure aware (see Security support) GPIO instance(s) can individually be:

  • set secure and assigned to the Arm® Cortex®-A7 secure for using with OP-TEE

or

  • set non-secure and assigned to the Arm® Cortex®-A7 non-secure for using in Linux® with the IOs pins frameworks

or

  • set non-secure and assigned to the Arm® Cortex®-M4 for using in STM32Cube with GPIO HAL driver, on STM32MP15x lines More info.png only


The pins of the non-secure (see Security support) GPIO instances can individually be:

  • assigned to the Arm® Cortex®-A7 non-secure for using in Linux® with the IOs pins frameworks

or

  • assigned to the Arm® Cortex®-M4 for using in STM32Cube with GPIO HAL driver, on STM32MP15x lines More info.png only

37.2.2 Software frameworks[edit]

37.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/IOs GPIO OP-TEE GPIO driver Linux IOs pins overview
37.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/IOs GPIO OP-TEE GPIO driver Linux IOs pins overview STM32Cube GPIO driver

37.2.3 Peripheral configuration[edit]

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

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:

37.2.4 Peripheral assignment[edit]

37.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/IOs GPIO GPIOA-I Shared (with pin granularity)
37.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Core/IOs GPIO GPIOA-K Shareable (with pin granularity)
GPIOZ Shareable (with pin granularity)

38 How to go further[edit]

Not applicable.

39 References[edit]


40 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 Warning.png BKPSRAM is 8 Kbytes wide.
  • STM32MP15x lines More info.png BKPSRAM is 4 Kbytes wide.

40.1 Features[edit]

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

40.2 Security support[edit]

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

41 Peripheral usage and associated software[edit]

41.1 Boot time[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.

41.2 Runtime[edit]

41.2.1 Overview[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

41.2.2 Software frameworks[edit]

41.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/RAM BKPSRAM FSBL or OP-TEE secure monitor Linux reserved memory
41.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/RAM BKPSRAM FSBL or OP-TEE secure monitor Linux reserved memory

41.2.3 Peripheral configuration[edit]

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

41.2.4 Peripheral assignment[edit]

41.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM BKPSRAM BKPSRAM Assignment (single choice)
41.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

42 References[edit]


43 Article purpose[edit]

The purpose of this article is to:

  • briefly introduce the DDRCTRL and DDRPHYC peripherals and their main features
  • indicate the level of security supported by those hardware blocks
  • explain how they can be allocated to the runtime contexts and linked to the corresponding software components
  • explain, when necessary, how to configure the DDRCTRL and DDRPHYC peripherals.

44 Peripheral overview[edit]

DDRCTRL and DDRPHYC peripherals are used to configure the physical interface to the external DDR memory.

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

44.1 Features[edit]

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

44.2 Security support[edit]

DDRCTRL and DDRPHYC are secure (under ETZPC control).

Access to the DDR memory can be filtered via the TZC controller.

45 Peripheral usage and associated software[edit]

45.1 Boot time[edit]

DDRCTRL and DDRPHYC 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.

45.2 Runtime[edit]

45.2.1 Overview[edit]

DDRCTRL and DDRPHYC 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 Warning.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.

45.2.2 Software frameworks[edit]

45.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/RAM DDR via DDRCTRL TF-A BL2 DDR resident driver in SYSRAM
45.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/RAM DDR via DDRCTRL DDR OP-TEE driver

45.2.3 Peripheral configuration[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).

45.2.4 Peripheral assignment[edit]

45.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM DDR via DDRCTRL DDR
45.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Core/RAM DDR via DDRCTRL DDR

46 References[edit]

MCU SRAM internal memory

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


47 Article purpose[edit]

The purpose of this article is to briefly introduce the SYSRAM internal memory and indicate the level of security supported by this memory.

48 Peripheral overview[edit]

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

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

48.1 Features[edit]

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

48.2 Security support[edit]

The SYSRAM is a secure peripheral (under ETZPC TrustZone memory adapter (TZMA)): it can be split into a secure and a non-secure regions with a 4-Kbyte granularity.

49 Peripheral usage and associated software[edit]

49.1 Boot time[edit]

49.1.1 On STM32MP13x lines Warning.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.

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

49.2 Runtime[edit]

49.2.1 Overview[edit]

In STMicroelectronics distribution, the SYSRAM runtime mapping is the one reached at the end of the boot. It is consequently fully secure and contains a minimal secure monitor (from TF-A) or 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 (from TF-A) 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

49.2.2 Software frameworks[edit]

49.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/RAM SYSRAM OP-TEE Linux reserved memory
49.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/RAM SYSRAM TF-A BL32 or OP-TEE Linux reserved memory

49.2.3 Peripheral configuration[edit]

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

49.2.4 Peripheral assignment[edit]

49.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/RAM SYSRAM SYSRAM Shareable (multiple choices supported)
49.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

50 References[edit]



51 Article purpose[edit]

The purpose of this article is to

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

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

52.1 Features[edit]

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

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 Warning.png, LPTIM3 can be used for RCC HSE clock source monitoring

52.2 Security support[edit]


52.2.1 On STM32MP13x lines Warning.png[edit]

There are 5 instances of LPTIM:

  • LPTIM instances 1, 4 and 5 are non-secure peripheral
  • LPTIM instances 2 and 3 are secure (under ETZPC control)
52.2.2 On STM32MP15x lines More info.png[edit]

The 5 LPTIM instances are a non-secure peripherals.

53 Peripheral usage and associated software[edit]

53.1 Boot time[edit]

The LPTIM is not used at boot time.

53.2 Runtime[edit]

53.2.1 Overview[edit]

53.2.1.1 On STM32MP13x lines Warning.png[edit]

LPTIM instances can be allocated to:

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

or

  • the Arm® Cortex®-A7 non-secure to be used under Linux® with PWM, IIO, Counter or/and Clock events frameworks
53.2.1.2 On STM32MP15x lines More info.png[edit]

LPTIM instances can be allocated to:

  • the Arm® Cortex®-A7 non-secure to be used under Linux® with PWM, IIO, Counter or/and Clock events frameworks,

or

  • the Arm® Cortex®-M4 to be used with STM32Cube MPU Package with LPTIM HAL driver

53.2.2 Software frameworks[edit]

53.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/Timers LPTIM OP-TEE PWM framework,
IIO framework,
Counter framework,
Clock events framework
53.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/Timers LPTIM PWM framework,
IIO framework,
Counter framework,
Clock events framework
STM32Cube LPTIM driver

53.2.3 Peripheral configuration[edit]

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

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

53.2.4 Peripheral assignment[edit]

53.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/Timers LPTIM LPTIM1
LPTIM2 Assignment (single choice)
LPTIM3 Assignment (single choice)
LPTIM3 can be used for HSE monitoring
LPTIM4
LPTIM5 Assignment (single choice)
53.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

54 References[edit]


55 Article purpose[edit]

The purpose of this article is to

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

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

56.1 Features[edit]

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 STM32MP13 reference manuals or STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to know which features are really implemented.


56.2 Security support[edit]


56.2.1 On STM32MP13x lines Warning.png[edit]

There are 14 instances of TIM:

  • TIM instances 1, 2, 3, 4, 5, 6, 7 and 8 are non-secure peripheral
  • TIM instances 12, 13, 14, 15, 16 and 17 are secure (under ETZPC control)
56.2.2 On STM32MP15x lines More info.png[edit]

The 14 instances of TIM are non-secure peripherals.

57 Peripheral usage and associated software[edit]

57.1 Boot time[edit]

The TIM is not used at boot time.

57.2 Runtime[edit]

57.2.1 Overview[edit]

57.2.1.1 On STM32MP13x lines Warning.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), to perform HSI and CSI calibrations[5] in RCC.

TIM13, TIM14, TIM16 and TIM17 can also be allocated to the Arm® Cortex®-A7 secure context, but there is no support for them in OP-TEE yet.
All TIM instances can be allocated to:

  • the Arm® Cortex®-A7 non-secure to be controlled in Linux® by the PWM, the IIO, and/or the Counter frameworks.
Info white.png Information
RCC[6] 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 (#Peripheral assignment)
57.2.1.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), to perform HSI and CSI calibrations[5] in RCC.

All TIM instances can be allocated to:

  • the Arm® Cortex®-A7 non-secure to be controlled in Linux® by the PWM, the IIO, and/or the Counter frameworks.

or

  • the Arm® Cortex®-M4 to be controlled in STM32Cube MPU Package by TIM HAL driver
Info white.png Information
RCC[6] 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 (#Peripheral assignment)

57.2.2 Software frameworks[edit]

57.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/Timers TIM OP-TEE TIM driver PWM framework
IIO framework,
Counter framework
57.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/Timers TIM TF-A TIM driver
OP-TEE TIM driver
PWM framework
IIO framework,
Counter framework
STM32Cube TIM driver

57.2.3 Peripheral configuration[edit]

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

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

57.2.4 Peripheral assignment[edit]

57.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/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[5]
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[5]
TIM16 (APB6 group) Assignment (single choice)
TIM17 (APB6 group) Assignment (single choice)
57.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

58 How to go further[edit]

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

59 References[edit]


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

60.1 Features[edit]

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

60.2 Security support[edit]

IWDG1 is secure-aware (under ETZPC control).
IWDG2 is non-secure.

61 Peripheral usage and associated software[edit]

61.1 Boot time[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.

61.2 Runtime[edit]

61.2.1 Overview[edit]

IWDG1 can be allocated to the Cortex-A7 secure to be used in the secure context by the customer application: this instance is not supported in STMicroelectronics distribution.
IWDG2 can be allocated to the Cortex-A7 non-secure to be used with Linux watchdog framework. 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.

61.2.2 Software frameworks[edit]

61.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Core/Watchdog IWDG OP-TEE Linux watchdog framework
61.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Core/Watchdog IWDG TF-A SP-MIN or OP-TEE Linux watchdog framework

61.2.3 Peripheral configuration[edit]

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

61.2.4 Peripheral assignment[edit]

61.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Core/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
61.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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


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


62 Article purpose[edit]

The purpose of this article is to

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

63 Peripheral overview[edit]

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

63.1 Features[edit]

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 Warning.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 STM32MP13 reference manuals or STM32MP15 reference manuals for the complete hardware feature list, and to the software components (introduced below) to know which features are supported.

63.2 Security support[edit]

63.2.1 On STM32MP13x lines Warning.png[edit]

The OTG is a secure programmable peripheral (under ETZPC control).

63.2.2 On STM32MP15x lines More info.png[edit]

The OTG peripheral is a non-secure peripheral.

64 Peripheral usage and associated software[edit]

64.1 Boot time[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.

64.2 Runtime[edit]

64.2.1 Overview[edit]

The OTG peripheral can be allocated to the Arm® Cortex®-A7 non-secure core to be used under Linux® with USB framework.
On STM32MP13x lines Warning.png only, the OTG peripheral can be allocated to the Arm® Cortex®-A7 secure context but this is not supported in OpenSTLinux.

64.2.2 Software frameworks[edit]

64.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
High speed interface OTG (USB OTG) Linux USB framework
64.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
High speed interface OTG (USB OTG) Linux USB framework

64.2.3 Peripheral configuration[edit]

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

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.

64.2.4 Peripheral assignment[edit]

64.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface OTG (USB OTG) OTG (USB OTG) Assignment (single choice)
64.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

65 References[edit]


66 Article purpose[edit]

The purpose of this article is to

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

67 Peripheral overview[edit]

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

67.1 Features[edit]

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 STM32MP13 reference manuals or STM32MP15 reference manuals for the complete features list, and to the software components, introduced below, to know which features are really implemented.

67.2 Security support[edit]

The USBH peripheral is a non-secure peripheral.

68 Peripheral usage and associated software[edit]

68.1 Boot time[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).

68.2 Runtime[edit]

68.2.1 Overview[edit]

The USBH peripheral can be allocated to the Arm® Cortex®-A7 non-secure core to be used under Linux® with USB framework.

68.2.2 Software frameworks[edit]

68.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
High speed interface USBH (USB Host) Linux USB framework
68.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
High speed interface USBH (USB Host) Linux USB framework

68.2.3 Peripheral configuration[edit]

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

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

68.2.4 Peripheral assignment[edit]

68.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface USBH (USB Host) USBH (USB Host)
68.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

69 References[edit]


70 Article purpose[edit]

The purpose of this article is to

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

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

71.1 Features[edit]

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 STM32MP13 reference manuals or STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to see which features are implemented.

71.2 Security support[edit]

71.2.1 On STM32MP13x lines Warning.png[edit]

The USBPHYC is a secure programmable peripheral (under ETZPC control).

71.2.2 On STM32MP15x lines More info.png[edit]

The USBPHYC peripheral is a non-secure peripheral.

72 Peripheral usage and associated software[edit]

72.1 Boot time[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).

72.2 Runtime[edit]

72.2.1 Overview[edit]

The USBPHYC peripheral can be allocated to the the Arm® Cortex®-A7 non-secure core to be used under Linux® with PHY framework.

The peripheral assignment chapter describes which peripheral instance can be assigned to which context.

72.2.2 Software frameworks[edit]

72.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
High-speed interface USBPHYC (USB HS PHY controller) Linux PHY framework
72.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
High-speed interface USBPHYC (USB HS PHY controller) Linux PHY framework

72.2.3 Peripheral configuration[edit]

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

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

72.2.4 Peripheral assignment[edit]

72.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
High speed interface USBPHYC (USB HS PHY controller) USBPHYC (USB HS PHY controller) Assignment (single choice)
72.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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


73 Article purpose[edit]

The purpose of this article is to:

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

74 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]

74.1 Features[edit]

Here are the main features:

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

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

74.2 Security support[edit]

74.2.1 On STM32MP13x lines Warning.png[edit]

There are five I2C instances:

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

74.2.2 On STM32MP15x lines More info.png[edit]

There are six I2C instances:

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

75 Peripheral usage and associated software[edit]

75.1 Boot time[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.

75.2 Runtime[edit]

75.2.1 Overview[edit]

Secure instances can be allocated to:

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

All I2C instances can be allocated to:

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

On STM32MP15x lines More info.png, all but I2C4&6 instances can be allocated to:

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

75.2.2 Software frameworks[edit]

75.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Low speed interface I2C OP-TEE I2C driver I2C Engine framework
75.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Low speed interface I2C OP-TEE I2C driver I2C Engine framework STM32Cube I2C driver

75.2.3 Peripheral configuration[edit]

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

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

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

75.2.4 Peripheral assignment[edit]

75.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Low speed interface I2C I2C1
I2C2
I2C3 Assignment (single choice)
I2C4 Assignment (single choice)
I2C5 Assignment (single choice)
75.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Low speed interface I2C I2C1 Assignment (single choice)
I2C2 Assignment (single choice)
I2C3 Assignment (single choice)
I2C4 Assignment (single choice).
Used for PMIC control on ST boards.
I2C5 Assignment (single choice)
I2C6 Assignment (single choice)

76 References[edit]


77 Article purpose[edit]

The purpose of this article is to:

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

78 Peripheral overview[edit]

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

78.1 Features[edit]

78.1.1 SPI main features[edit]

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

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

78.1.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 STM32MP13 reference manuals or STM32MP15 reference manuals for the complete list of features, and to the software components, introduced below, to see which features are implemented.

78.2 Security support[edit]

78.2.1 On STM32MP13x lines Warning.png[edit]

There are five SPI instances:

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

78.2.2 On STM32MP15x lines More info.png[edit]

There are six SPI instances:

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

79 Peripheral usage and associated software[edit]

79.1 Boot time[edit]

The SPI is not used at boot time.

79.2 Runtime[edit]

79.2.1 Overview[edit]

The secure instances can be allocated to:

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

All the SPI instances can be allocated to:

  • the Arm® Cortex®-A7 non-secure core to be controlled in Linux® by:
  • the SPI framework for SPI configured in SPI mode
  • the ALSA framework for SPI configured in I2S mode

or, on STM32MP15x lines More info.png only,

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

79.2.2 Software frameworks[edit]

79.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Low speed interface SPI Linux SPI framework SPI configured in SPI mode
Audio SPI Linux ALSA framework SPI configured in I2S mode
Only for SPI supporting I2S feature
79.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Low speed interface SPI Linux SPI framework STM32Cube SPI driver SPI configured in SPI mode
Audio SPI Linux ALSA framework STM32Cube I2S driver SPI configured in I2S mode
Only for SPI supporting I2S feature

79.2.3 Peripheral configuration[edit]

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

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

  • SPI mode:

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

  • I2S mode:

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

79.2.4 Peripheral assignment[edit]

79.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Low speed interface
or
audio
SPI SPI2S1
SPI2S2
SPI2S3
SPI2S4 Assignment (single choice)
SPI5 Assignment (single choice)
79.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Low speed interface
or
audio
SPI SPI2S1 Assignment (single choice)
SPI2S2 Assignment (single choice)
SPI2S3 Assignment (single choice)
SPI4 Assignment (single choice)
SPI5 Assignment (single choice)
SPI6 Assignment (single choice)

80 References[edit]



81 Article purpose[edit]

The purpose of this article is to:

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

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

82.1 Features[edit]

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

82.2 Security support[edit]

82.2.1 On STM32MP13x lines Warning.png[edit]

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

82.2.2 On STM32MP15x lines More info.png[edit]

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

83 Peripheral usage and associated software[edit]

83.1 Boot time[edit]

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

83.2 Runtime[edit]

83.2.1 Overview[edit]

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

Secure USART can be allocated to:

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


All USART and UART instances can be allocated to:

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

or, on STM32MP15x lines More info.png only,

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


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

83.2.2 Software frameworks[edit]

83.2.2.1 On STM32MP13x lines Warning.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux
Low speed interface USART USART OP-TEE driver Linux serial/tty framework
83.2.2.2 On STM32MP15x lines More info.png[edit]
Domain Peripheral Software components Comment
OP-TEE Linux STM32Cube
Low speed interface USART USART OP-TEE driver Linux serial/tty framework STM32Cube USART driver

83.2.3 Peripheral configuration[edit]

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

83.2.4 Peripheral assignment[edit]

83.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Low speed interface USART USART1 Assignment (single choice)
USART2 Assignment (single choice)
USART3
UART4
UART5
USART6
UART7
UART8
83.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Low speed interface USART USART1 Assignment (single choice)
USART2 Assignment (single choice)
USART3 Assignment (single choice)
UART4 Assignment (single choice).
Used for Linux® serial console on ST boards.
UART5 Assignment (single choice)
USART6 Assignment (single choice)
UART7 Assignment (single choice)
UART8 Assignment (single choice)

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

85 References[edit]

  1. Please refer to STM32MP1-Peripheral-USART document on st.com
  2. STM32 USART automatic baud rate detection application note (AN4908)



86 Article purpose[edit]

The purpose of this article is to

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

87 Peripheral overview[edit]

The FMC peripheral includes two memory controllers:

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

87.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, .... .

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 which:

  • 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 supports up to four external devices.

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

87.3 Features[edit]

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

87.4 Security support[edit]

87.4.1 On STM32MP13x lines Warning.png[edit]

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

87.4.2 On STM32MP15x lines More info.png[edit]

The FMC is a non-secure peripheral.

88 Peripheral usage and associated software[edit]

88.1 Boot time[edit]

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

88.2 Runtime[edit]

88.2.1 Overview[edit]

The FMC peripheral can be allocated to:

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

or

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

or

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

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

88.2.2 Software frameworks[edit]

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

88.2.3 Peripheral configuration[edit]

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

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

88.2.4 Peripheral assignment[edit]

88.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Mass storage FMC FMC Assignment (single choice)
88.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

89 How to go further[edit]

90 References[edit]



91 Article purpose[edit]

The purpose of this article is to

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

92 Peripheral overview[edit]

The Quad-SPI interface (QUADSPI peripheral) is used to interface 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 agregate two Flash memories into a virtual single one
  • Dual data rate and memory-mapped modes.

92.1 Features[edit]

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

92.2 Security support[edit]

92.2.1 On STM32MP13x lines Warning.png[edit]

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

92.2.2 On STM32MP15x lines More info.png[edit]

The QUADSPI is a non secure peripheral.

93 Using the peripheral - associated software[edit]

93.1 Boot time[edit]

QUADSPI instance is boot device that support serial boot for Flash programming with STM32CubeProgrammer.

93.2 Runtime[edit]

93.2.1 Overview[edit]

The QUADSPI instances can be allocated to:

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

or

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

or

  • the Arm® Cortex®-M4, on STM32MP15x lines More info.png only, to be controlled in STM32Cube MPU Package by QUADSPI HAL driver

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

93.2.2 Software frameworks[edit]

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

93.2.3 Peripheral configuration[edit]

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

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

93.2.4 Peripheral assignment[edit]

93.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Mass storage QUADSPI QUADSPI Assignment (single choice)
93.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

94 References[edit]



95 Article purpose[edit]

The purpose of this article is to

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

96 Peripheral overview[edit]

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

96.1 Features[edit]

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

96.2 Security support[edit]

96.2.1 On STM32MP13x lines Warning.png[edit]

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

96.2.2 On STM32MP15x lines More info.png[edit]

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

97 Peripheral usage and associated software[edit]

97.1 Boot time[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.

97.2 Runtime[edit]

97.2.1 Overview[edit]

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

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

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

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

97.2.2 Software frameworks[edit]

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

97.2.3 Peripheral configuration[edit]

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

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

97.2.4 Peripheral assignment[edit]

97.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Mass storage SDMMC SDMMC1 Assignment (single choice)
SDMMC2 Assignment (single choice)
97.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

98 References[edit]



99 Article purpose[edit]

The purpose of this article is to:

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

100 Peripheral overview[edit]

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

100.1 Features[edit]

The Ethernet peripheral main features are the following:

  • Compliance with IEEE 802.3 specifications
  • Support for IEEE 1588-2002 and IEEE 1588-2008 standards for precision networked clock synchronization
IEEE 802.3-az for Energy Efficient Ethernet (EEE)
IEEE 802.3x flow control automatic transmission of zero-quanta pause frame on flow control input de-assertion.
IEEE 802.1Q VLAN tag detection for reception frames on STM32MP15x lines More info.png only
AMBA 2.0 for AHB Master/Slave ports and AMBA 3.0 for AXI Master/Slave ports
  • Configurability allowing to support data transfer rates of 10/100/100 Mbps, 10/100 Mbps only or 1000 Mbps only
  • Support for multiple TCP/IP offload functions

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

100.2 Security support[edit]

100.2.1 On STM32MP13x lines Warning.png[edit]

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

100.2.2 On STM32MP15x lines More info.png[edit]

The single instance ETH is a non-secure peripheral.

101 Peripheral usage and associated software[edit]

101.1 Boot time[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.

101.2 Runtime[edit]

101.2.1 Overview[edit]

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

101.2.2 Software frameworks[edit]

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

101.2.3 Peripheral configuration[edit]

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

101.2.4 Peripheral assignment[edit]

101.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Networking ETH ETH1 Assignment (single choice)
ETH2 Assignment (single choice)
101.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Networking ETH ETH Assignment (single choice)

102 References[edit]



103 Article purpose[edit]

The purpose of this article is to:

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

104 Peripheral overview[edit]

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.

104.1 Features[edit]

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

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

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

104.2 Security support[edit]

FDCAN is a non secure peripheral.

105 Peripheral usage and associated software[edit]

105.1 Boot time[edit]

The FDCAN is not used at boot time.

105.2 Runtime[edit]

105.2.1 Overview[edit]

FDCAN instances can be allocated to:

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

or, on STM32MP15x lines More info.png only

105.2.2 Software frameworks[edit]

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

105.2.3 Peripheral configuration[edit]

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

105.2.4 Peripheral assignment[edit]

105.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Networking FDCAN FDCAN1
FDCAN2
105.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

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

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


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

107.1 Features[edit]

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

107.2 Security support[edit]

The DTS is a non secure peripheral.

108 Peripheral usage and associated software[edit]

108.1 Boot time[edit]

DTS is not used at boot time.

108.2 Runtime[edit]

108.2.1 Overview[edit]

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

108.2.2 Software frameworks[edit]

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

108.2.3 Peripheral configuration[edit]

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

108.2.4 Peripheral assignment[edit]

108.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Power & Thermal DTS DTS
108.2.4.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 can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

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

(STM32Cube)
Power & Thermal DTS DTS

109 References[edit]



Technical information related to "PWR internal peripheral" depends on the microprocessor device.
Several articles have been created, one per STM32 MPU device, to manage those differences.
You can find information corresponding to the STM32 MPU you use, by clicking on one of articles below.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 PWR internal peripheral
STM32MP15x STM32MP15 PWR internal peripheral


Technical information related to "RCC internal peripheral" depends on the microprocessor device.
Several articles have been created, one per STM32 MPU device, to manage those differences.
You can find information corresponding to the STM32 MPU you use, by clicking on one of articles below.

STM32 MPU devices Associated articles
STM32MP13x STM32MP13 RCC internal peripheral
STM32MP15x STM32MP15 RCC internal peripheral


110 Article purpose[edit]

The purpose of this article is to

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

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

111.1 Features[edit]

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

111.2 Security support[edit]

The BSEC is a secure peripheral.

112 Peripheral usage and associated software[edit]

112.1 Boot time[edit]

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

112.2 Runtime[edit]

112.2.1 Overview[edit]

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

Info white.png Information
  • BSEC lower OTP access can be made available to the Arm® Cortex®-A7 non-secure.
  • Upper OTP access can be managed as exceptions:
  • on STM32MP13x lines Warning.png, using OP-TEE PTA
  • on STM32MP15x lines More info.png, using TF-A "secure monitor calls" or OP-TEE PTA

Please refer to BSEC device tree configuration for more details.

112.2.2 Software frameworks[edit]

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

112.2.3 Peripheral configuration[edit]

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

112.2.4 Peripheral assignment[edit]

112.2.4.1 On STM32MP13x lines Warning.png[edit]

Click on the right to expand the legend...

STM32MP13IPsOverview.png

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

  • means that the peripheral can be assigned () to the given runtime context.
  • means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
  • is used for system peripherals that cannot be unchecked because they are statically connected in the device.

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

Domain Peripheral Runtime allocation Comment
Instance Cortex-A7
secure
(OP-TEE)
Cortex-A7
non-secure
(Linux)
Security BSEC BSEC
112.2.4.2 On STM32MP15x lines