Last edited 11 months ago

RCC internal peripheral

Applicable for STM32MP13x lines, STM32MP15x lines

1. Article purpose[edit source]

The purpose of this article is to:

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

2. Peripheral overview[edit source]

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

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

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

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

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

3. Peripheral usage[edit source]

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.

3.1. Boot time assignment[edit source]

3.1.1. On STM32MP1 series[edit source]

The RCC security level differs for each boot chain:

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

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

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

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


Click on the right to expand the legend...

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

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

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

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

3.2. Runtime assignment[edit source]

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


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

Click on the right to expand the legend...

STM32MP13 internal peripherals

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

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

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

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

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

Click on the right to expand the legend...

STM32MP15 internal peripherals

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

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

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

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

(STM32Cube)
Power & Thermal RCC RCC

4. Software frameworks and drivers[edit source]

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

5. How to assign and configure the peripheral[edit source]

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.

6. How to go further[edit source]

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

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

7. References[edit source]