STM32MP13 peripherals overview

Applicable for

STM32MP13x lines

---

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

1. Internal peripherals overview

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

Several runtime contexts exist on STM32MP13 device, corresponding to the Arm Cortex-A7 security modes:

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

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

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

STM32MP13 internal peripherals overview

2. Internal peripherals assignment

Click on the right to expand the legend...

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

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

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

3. Article purpose

The purpose of this article is to:

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

4. Peripheral overview

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

The STM32MP13x SoCs have two ADC blocks, except for the STM32MP131 SoC which has only one ADC block. There is one physical ADC per block:

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

Each ADC supports two contexts to manage conversions:

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

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

5. Peripheral usage

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

5.1. Boot time assignment

5.1.1. On STM32MP13x lines 

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

Click on to expand or collapse the legend...

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

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

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

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

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

5.2. Runtime assignment

5.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Analog	ADC	ADC1	☐	☐	Assignment (single choice)
		ADC2	☐	☐	Assignment (single choice) ADC2 can be used for system supplies monitoring

6. Software frameworks and drivers

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

• Linux^®: IIO framework
• OP-TEE: OP-TEE ADC driver
• U-Boot: U-Boot ADC driver

7. How to assign and configure the peripheral

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

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

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

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

8. How to go further

See application notes:

• How to get the best ADC accuracy in STM32.

10. Article purpose

The purpose of this article is to:

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

11. Peripheral overview

The VREFBUF peripheral is an internal voltage regulator.

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

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

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

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

12. Peripheral usage

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

12.1. Boot time assignment

12.1.1. On STM32MP13x lines 

The VREFBUF is usually not used at boot time. But it may be needed by the SSBL (see Boot chain overview), to supply the internal ADC for example.

Click on to expand or collapse the legend...

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

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

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

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

12.2. Runtime assignment

12.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

Information

As soon as one VREFBUF client peripheral (ADC1 or ADC2) is set secure, the VREFBUF should be set secure with ETZPC configuration. In OpenSTlinux, VREFBUF is only managed by OP-TEE exported through SCMI even if all ADC are non-secured.

13. Software frameworks and drivers

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

• Linux^®: regulator framework
• OP-TEE: OP-TEE SCMI

14. How to assign and configure the peripheral

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

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

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

• For the Linux kernel configuration, please refer to device internal regulator. An example can be found also in ADC DT configuration examples

14.1. DT configuration example

In OP-TEE device tree:

 &etzpc {
 	st,decprot = <
 		DECPROT(STM32MP1_ETZPC_VREFBUF_ID, DECPROT_S_RW, DECPROT_UNLOCK)
 	>;
 };
 &scmi_regu {
 	scmi_vrefbuf: voltd-vrefbuf {
 		reg = <VOLTD_SCMI_VREFBUF>;
 		voltd-supply = <&vrefbuf>;
 	};
 };
 &vrefbuf {
 	vdda-supply = <&vdd>;
 	status = "okay";
 };

In Linux device tree:

 &adc_1 {
 ...
 	vref-supply = <&scmi_vrefbuf>;
 	status = "okay";
 };

 &scmi_regu {
 	scmi_vrefbuf: voltd-vrefbuf {
 		reg = <VOLTD_SCMI_VREFBUF>;
 		regulator-name = "vrefbuf";
 		regulator-min-microvolt = <2500000>;
 		regulator-max-microvolt = <2500000>;
 	};
 };

15. References

STM32MP13 RTC internal peripheral

STM32MP13 SYSCFG internal peripheral

16. Article purpose

The purpose of this article is to:

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

17. Peripheral overview

The SRAM peripheral is 32-Kbyte wide, split into three separate banks:

• SRAM1 (16 Kbytes)
• SRAM2 (8 Kbytes)
• SRAM3 (8 Kbytes)

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

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

18. Peripheral usage

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

18.1. Boot time assignment

18.1.1. On STM32MP13x lines 

The ROM code uses:

• the SRAM1 and SRAM2 to store internal data
• the SRAM3 to store the FSBL header

This ROM code mapping strategy aims to leave the whole SYSRAM internal memory free for FSBL binary loading then execution.

The TF-A BL2 uses:

• the SRAM1 to store boot NAND 4kB scratch buffer
• the SRAM2 to store MbedTLS in case of secure boot
• the SRAM3 to store fw-config DT

Click on to expand or collapse the legend...

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

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

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

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A7 secure (ROM code)	Cortex-A7 secure (TF-A BL2)	Cortex-A7 non-secure (U-Boot)
Core/RAM	SRAM	Any instance	✓	☑	☐	SRAM first used by ROM code, then TF-A BL2. After assignment free to user

18.2. Runtime assignment

18.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

Domain	Peripheral	Runtime allocation			Comment
		Instance	Cortex-A7 secure (OP-TEE)	Cortex-A7 non-secure (Linux)
Core/RAM	SRAM	SRAM1	☐	☐	Assignment (between A7 S and A7 NS)
		SRAM2	☐	☐	Assignment (between A7 S and A7 NS)
		SRAM3	☐	☐	Assignment (between A7 S and A7 NS)

19. Software frameworks and drivers

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

• Linux^®: reserved memory, that is used by the dmaengine (for DMA buffers management)
• OP-TEE: OP-TEE
• TF-A BL2: TF-A BL2

20. How to assign and configure the peripheral

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

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

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

21. Article purpose

The purpose of this article is to:

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

22. Peripheral overview

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

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

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

The PWR peripheral provides 3 output hardware lines named PWR_ON, PWR_LP and PWR_CPU_ON:

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

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

23. Peripheral usage

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

23.1. Boot time assignment

23.1.1. On STM32MP13x lines 

The PWR is closely configured together with RCC by all the boot components: the ROM code, the FSBL, the SSBL. Its configuration is carried by the device tree.

Click on to expand or collapse the legend...

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

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

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

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

23.2. Runtime assignment

23.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

24. Software frameworks and drivers

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

• Linux^®: power management, regulator framework with SCMI regulators
• OP-TEE:
  • core/arch/arm/plat-stm32mp1/drivers/stm32mp1_pwr.c
  • core/arch/arm/plat-stm32mp1/drivers/stm32mp1_pwr_irq.c
  • core/arch/arm/plat-stm32mp1/pm/low_power.c
  • core/drivers/regulator/stm32mp1_regulator_iod.c

25. How to assign and configure the peripheral

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

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

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

• PWR wake-up pins configuration in OP-TEE

26. How to go further

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

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

STM32MP13 RCC internal peripheral

STM32MP13 ETZPC internal peripheral STM32MP13 HASH internal peripheral

27. Article purpose

The purpose of this article is to:

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

28. Peripheral overview

The DDRMCE (DDR Memory Cipher Engine) peripheral allows to define one AES encrypted region in DDR memory.

Information

Functions and registers names declared in the embedded software are using "MCE" / "mce" acronym instead of the longest "DDRMCE" / "ddrmce" ones, so take care about this for any research in the code.

The DDRMCE 128-bit master key is provisioned during boot processing, in order to use AES block ciphering feature. It must be fully saved in BKPSRAM for low power sequences.

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

29. Peripheral usage

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

29.1. Boot time assignment

29.1.1. On STM32MP13x lines 

The DDRMCE peripheral, part of the DDR subsystem, is configured inside TF-A BL2 to setup the security of a DDR region thanks to TF-A FW Configuration. This should be done before accessing DDR region if encryption is required.

Click on to expand or collapse the legend...

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

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

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

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

29.2. Runtime assignment

29.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

30. Software frameworks and drivers

All system bus traffic going through an encrypted region is managed on-the-fly by the DDRMCE, automatically decrypting reads and encrypting writes: see the memory mapping.

31. How to assign and configure the peripheral

The DDRMCE configuration is generated via STM32CubeMX tool, according to the region characteristics (address, length, type). This configuration is applied during boot time by the FSBL (see Boot chain overview): TF-A.

33. Article purpose

The purpose of this article is to:

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

34. Peripheral overview

The PKA (public key accelerator) peripheral is used to ease computation of cryptographic public key primitives, specifically those related to RSA, Diffie-Hellmann or ECC (elliptic curve cryptography) over GF(p) (Galois fields).

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

35. Peripheral usage

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

35.1. Boot time assignment

35.1.1. On STM32MP13x lines 

The PKA peripheral is a boot device, it is used for signature verification on secure boot processing.

Click on to expand or collapse the legend...

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

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

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

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A7 secure (ROM code)	Cortex-A7 secure (TF-A BL2)	Cortex-A7 non-secure (U-Boot)
Security	PKA	PKA	✓	☑	⬚	Assignment is mandatory only for secure boot

35.1.2. On STM32MP2 series

Click on to expand or collapse the legend...

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

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

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Security	PKA	PKA	✓	☑	⬚	Assignment is mandatory only for secure boot

35.2. Runtime assignment

35.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

35.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 internal peripherals

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

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

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

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

36. Software frameworks and drivers

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

• OP-TEE: PKA driver through the ECC framework
• TF-A BL2: TF-A Crypto Library

37. How to assign and configure the peripheral

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

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

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

STM32MP13 RNG internal peripheral

38. Article purpose

The purpose of this article is to:

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

39. Peripheral overview

The SAES peripheral provides hardware acceleration to encrypt or decrypt data using the AES algorithms. It supports two key sizes (128 bits and 256 bits) and different chaining modes. It incorporates protections against differential power analysis (DPA) and the related side-channel attacks.

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

40. Peripheral usage

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

40.1. Boot time assignment

40.1.1. On STM32MP13x lines 

The SAES instance is used to decrypt the firmware.

Click on to expand or collapse the legend...

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

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

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

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

40.1.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

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

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

Domain	Peripheral	Boot time allocation				Comment
		Instance	Cortex-A35 secure (ROM code)	Cortex-A35 secure (TF-A BL2)	Cortex-A35 non-secure (U-Boot)
Security	SAES	SAES	☐	☑	⬚	ROM code allocation is managed with the bit 8 in OTP 16

40.2. Runtime assignment

40.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

40.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 internal peripherals

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

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

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

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

41. Software frameworks and drivers

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

• Linux^®: crypto framework
• OP-TEE: SAES driver and Cryptographic Provider API (CP API)
• TF-A BL2: SAES driver

42. How to assign and configure the peripheral

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

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

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

43. References

STM32MP13 TAMP internal peripheral

ETM internal peripheral

Applicable for

STM32MP13x lines, STM32MP25x lines

---

44. Article purpose

The purpose of this article is to:

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

45. Peripheral overview

The DCMIPP (digital camera memory interface pixel processor) peripheral is used to receive video data from an external parallel camera sensor device, or from any other digital video equipment supporting a parallel interface.

The DCMIPP hardware block can receive various frame data formats such as: RAW8, RGB565, YUV422 and other formats, as well as compressed data such as JPEG.

Moreover, on STM32MP25x lines :

• the DCMIPP is also connected to the CSI internal peripheral that provides an interface to communicate with MIPI^® CSI-compliant camera sensors: the DCMIPP is able to get pixels from the parallel or MIPI^® CSI interface.
• the DCMIPP embeds 3 dedicated pixel pipelines named "dump", "main" and "auxiliary": camera sensor data go into these pixel pipelines before they are sent to memory for further processing or display purposes.

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

46. Peripheral usage

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

46.1. Boot time assignment

46.1.1. On STM32MP1 series

The DCMIPP peripheral is not used at boot time.

46.1.2. On STM32MP2 series

Click on to expand or collapse the legend...

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

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

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

46.2. Runtime assignment

46.2.1. On STM32MP13x lines 

Click on to expand or collapse the legend...

STM32MP13 internal peripherals

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

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

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

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

46.2.2. On STM32MP25x lines 

Click on to expand or collapse the legend...

STM32MP25 internal peripherals

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

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

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

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

47. Software frameworks and drivers

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

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

48. How to assign and configure the peripheral

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

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

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

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

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

Cortex^®

Operating system

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

Central processing unit

Direct memory access

Voltage reference buffer (STM32 specific)

Low-power timer (STM32 specific)

External interrupt

Board support package

Second stage boot loader

Open portable trusted execution environment

Linux^® is a registered trademark of Linus Torvalds.

Read only memory

Trusted firmware for Arm^® Cortex^®-A

Boot loader stage 2

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

Hardware abstraction layer

Device tree

Extended trustzone protection controller

System control and management interface

First stage boot loader

Random access memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Low power (MIPI^® Alliance DSI standard)

Doubledata rate (memory domain)

Advanced encryption standard

Elliptic curve cryptography

Error correction capability

Differential power analysis

Digital Camera memory interface pixel processor

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

Multi Speed Internal oscillator (STM32 clock source)