1. Article purpose[edit | edit source]
The purpose of this article is to:
- briefly introduce the IPCC peripheral and its main features,
- indicate the peripheral instances assignment at boot time and their assignment at runtime (including whether instances can be allocated to secure contexts),
- list the software frameworks and drivers managing the peripheral,
- explain how to configure the peripheral.
2. Peripheral overview[edit | edit source]
The IPCC (inter-processor communication controller) peripheral is used to exchange data between two processors. It provides a non blocking signaling mechanism to post and retrieve information in an atomic way. Note that shared memory buffers are allocated in the MCU SRAM, which is not part of the IPCC block.
The IPCC peripheral provides a hardware support to manage inter-processor communication between two processor instances. Each processor owns specific register bank and interrupts.
The IPCC provides the signaling for six bidirectional channels.
Each channel is divided into two subchannels that offer a unidirectional signaling from the "sender" processor to the "receiver" processor:
- P1_TO_P2 subchannel
- P2_TO_P1 subchannel
A subchannel consists in:
- One flag that toggles between occupied and free: the flag is set to occupied by the "sender" processor and cleared by the "receiver" processor.
- Two associated interrupts (shared with the other channels):
- RXO: RX channel occupied, connected to the "receiver" processor.
- TXF: TX channel free, connected to the "sender" processor.
- Two associated interrupt masks multiplexing channel IRQs.
The IPCC supports the following channel operating modes:
- Simplex communication mode:
- Only one subchannel is used.
- Unidirectional messages: once the "sender" processor has posted the communication data in the memory, it sets the channel status flag to occupied. The "receiver" processor clears the flag when the message is treated.
- Half-duplex communication mode:
- Only one subchannel is used.
- Bidirectional messages: once the "sender" processor has posted the communication data in the memory, it sets the channel status flag to occupied. The "receiver" processor clears the flag when the message is treated and the response is available in shared memory.
- Full-duplex communication mode:
- The subchannels are used in Asynchronous mode.
- Any processor can post asynchronously a message by setting the subchannel status flag to occupied. The "receiver" processor clears the flag when the message is treated. This mode can be considered as a combination of two simplex modes on a given channel.
Refer to the reference manuals[1][2] 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 | 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. Processor interface assignment[edit | edit source]
3.1.1. On STM32MP15x lines 
[edit | edit source]
STMicroelectronics distribution uses the IPCC peripheral for inter-processor communication with the following configuration:
- The IPCC processor 1 interface (PROC1)is assigned to the Arm® Cortex®-A7, non-secure context.
- The IPCC processor 2 interface (PROC2) is assigned to the Arm® Cortex®-M4 context.
3.1.2. On STM32MP25x lines [edit | edit source]
- The IPCC1 peripheral is dedicated for the communication between the Arm® Cortex®-A35 and the Arm® Cortex®-M33. The interfaces are assigned in hardware to the Cortexes :
- The processor 1 interface (PROC1) is assigned by hardware to the Arm® Cortex®-A35, secure and non-secure context.
- The processor 2 interface (PROC2) is assigned by hardware to the Arm® Cortex®-M33, secure and non-secure context.
- The IPCC2 peripheral is dedicated for the communication between the Arm® Cortex®-A35 or the Arm® Cortex®-M33 and the Arm® Cortex®-M0+.
- The processor 1 interface (PROC1) is assigned by hardware to the Arm® Cortex®-M0+.
- The processor 2 interface (PROC2) is assignable to the Arm® Cortex®-A35 or the Arm® Cortex®-M33, secure and non-secure context.
3.2. Boot time assignment[edit | edit source]
3.2.1. On STM32MP15x lines [edit | edit source]
The IPCC peripheral is not used at boot time.
3.2.2. On STM32MP25x lines [edit | edit source]
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) | |||
| Coprocessor | IPCC 
|
IPCC1 | ⬚ | ⬚ | Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature | |
| IPCC2 | ⬚ | ⬚ | Shareable at internal peripheral level thanks to the RIF: see the boot time allocation per feature | |||
The below table shows the possible boot time allocations for the features of the IPCC1 instance.
| Feature | Boot time allocation
|
Comment | ||
|---|---|---|---|---|
| Cortex-A35 secure (ROM code) |
Cortex-A35 secure (TF-A BL2) |
Cortex-A35 non-secure (U-Boot) | ||
| PROC1 channel 1 | ⬚ | ⬚ | ||
| PROC1 channel 2 | ⬚ | ⬚ | ||
| PROC1 channel 3 | ⬚ | ⬚ | ||
| PROC1 channel 4 | ⬚ | ⬚ | ||
| PROC1 channel 5 | ⬚ | ⬚ | ||
| PROC1 channel 6 | ⬚ | ⬚ | ||
| PROC1 channel 7 | ⬚ | ⬚ | ||
| PROC1 channel 8 | ⬚ | ⬚ | ||
| PROC1 channel 9 | ⬚ | ⬚ | ||
| PROC1 channel 10 | ⬚ | ⬚ | ||
| PROC1 channel 11 | ⬚ | ⬚ | ||
| PROC1 channel 12 | ⬚ | ⬚ | ||
| PROC1 channel 13 | ⬚ | ⬚ | ||
| PROC1 channel 14 | ⬚ | ⬚ | ||
| PROC1 channel 15 | ⬚ | ⬚ | ||
| PROC1 channel 16 | ⬚ | ⬚ | ||
| PROC2 channel 1 | ||||
| PROC2 channel 2 | ||||
| PROC2 channel 3 | ||||
| PROC2 channel 4 | ||||
| PROC2 channel 5 | ||||
| PROC2 channel 6 | ||||
| PROC2 channel 7 | ||||
| PROC2 channel 8 | ||||
| PROC2 channel 9 | ||||
| PROC2 channel 10 | ||||
| PROC2 channel 11 | ||||
| PROC2 channel 12 | ||||
| PROC2 channel 13 | ||||
| PROC2 channel 14 | ||||
| PROC2 channel 15 | ||||
| PROC2 channel 16 | ||||
The below table shows the possible boot time allocations for the features of the IPCC2 instance.
| Feature | Boot time allocation
|
Comment | ||
|---|---|---|---|---|
| Cortex-A35 secure (ROM code) |
Cortex-A35 secure (TF-A BL2) |
Cortex-A35 non-secure (U-Boot) | ||
| PROC1 channel 1 | ||||
| PROC1 channel 2 | ||||
| PROC1 channel 3 | ||||
| PROC1 channel 4 | ||||
| PROC2 channel 1 | ⬚ | ⬚ | ||
| PROC2 channel 2 | ⬚ | ⬚ | ||
| PROC2 channel 3 | ⬚ | ⬚ | ||
| PROC2 channel 4 | ⬚ | ⬚ | ||
3.3. Runtime assignment[edit | edit source]
It does not make sense to allocate the IPCC to a single runtime execution context. It is consequently enabled by default for both cores in the STM32CubeMX.
3.3.1. On STM32MP15x lines [edit | edit source]
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 runtime context.
- ☑ means that the peripheral is assigned by default to the given runtime context and that the peripheral is mandatory for the STM32 MPU Embedded Software distribution.
- ⬚ means that the peripheral can be assigned to the given runtime context, but this configuration is not supported in STM32 MPU Embedded Software distribution.
- ✓ is used for system peripherals that cannot be unchecked because they are hardware connected in the device.
Refer to How to assign an internal peripheral to an execution context for more information on how to assign peripherals manually or via STM32CubeMX.
The present chapter describes STMicroelectronics recommendations or choice of implementation. Additional possiblities might be described in STM32MP15 reference manuals.
| Domain | Peripheral | Runtime allocation | Comment
| |||
|---|---|---|---|---|---|---|
| Instance | Cortex-A7 secure (OP-TEE) |
Cortex-A7 non-secure (Linux) |
Cortex-M4 (STM32Cube) | |||
| Coprocessor | IPCC | IPCC | ☑ | ☑ | Shared (none or both) | |
| Processor interface | Context | Comment | ||
|---|---|---|---|---|
| Cortex-A7 non-secure (Linux) |
Cortex-M4 (STM32Cube) | |||
| PROC1 channel 1 | ☑ | RPMsg transfer from Cortex-M to Cortex-A
Full-duplex communication:
| ||
| PROC1 channel 2 | ☑ | RPMsg transfer from Cortex-A to Cortex-M
Full-duplex communication:
| ||
| PROC1 channel 3 | ☑ | Simplex communication used by the remote framework to request the Cortex-M4 to shutdown. | ||
| PROC1 channel 4 | ☐ | |||
| PROC1 channel 5 | ☐ | |||
| PROC1 channel 6 | ☐ | |||
| PROC2 channel 1 | ☑ | RPMsg transfer from Cortex-M to Cortex-A
Full-duplex communication:
| ||
| PROC2 channel 2 | ☑ | RPMsg transfer from Cortex-A to Cortex-M
Full-duplex communication:
| ||
| PROC2 channel 3 | ☑ | Simplex communication used by the remote framework to request the Cortex-M4 to shutdown. | ||
| PROC2 channel 4 | ☐ | |||
| PROC2 channel 5 | ☐ | |||
| PROC2 channel 6 | ☐ | |||
3.3.2. On STM32MP25x lines [edit | edit source]
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 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) | |||
| Coprocessor | IPCC
|
IPCC1 | ☐OP-TEE | ☐ | ☐ | ☐ | Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature | |
| IPCC2 | ☐OP-TEE | ☐ | ☐ | ☐ | ☐ | Shareable at internal peripheral level thanks to the RIF: see the runtime allocation per feature | ||
The below table shows the possible runtime allocations for the features of the IPCC1 instance.
| Feature | Runtime allocation
|
Comment | ||||
|---|---|---|---|---|---|---|
| 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) | ||
| PROC1 channel 1 | ☐OP-TEE | ☑ | RPMsg transfer from Cortex-M to Cortex-A
Full-duplex communication:
| |||
| PROC1 channel 2 | ☐OP-TEE | ☑ | RPMsg transfer from Cortex-A to Cortex-M
Full-duplex communication:
| |||
| PROC1 channel 3 | ☐OP-TEE | ☑ | Simplex communication used by the remoteproc framework to request the Cortex-M33 to shutdown. | |||
| PROC1 channel 4 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 5 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 6 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 7 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 8 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 9 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 10 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 11 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 12 | ☐OP-TEE | ☐ | ||||
| PROC1 channel 13 | ☐OP-TEE | ☐ | Allocated to secure world but not used. | |||
| PROC1 channel 14 | ☐OP-TEE | ☐ | Allocated to secure world but not used. | |||
| PROC1 channel 15 | ☐OP-TEE | ☐ | Allocated to secure world but not used. | |||
| PROC1 channel 16 | ☐OP-TEE | ☐ | Allocated to secure world but not used. | |||
| PROC2 channel 1 | ☐ | ☑ | RPMsg transfer from Cortex-M to Cortex-A
Full-duplex communication:
| |||
| PROC2 channel 2 | ☐ | ☑ | RPMsg transfer from Cortex-A to Cortex-M
Full-duplex communication:
| |||
| PROC2 channel 3 | ☐ | ☑ | Simplex communication used by the remoteproc framework to request the Cortex-M33 to shutdown. | |||
| PROC2 channel 4 | ☐ | ☐ | ||||
| PROC2 channel 5 | ☐ | ☐ | ||||
| PROC2 channel 6 | ☐ | ☐ | ||||
| PROC2 channel 7 | ☐ | ☐ | ||||
| PROC2 channel 8 | ☐ | ☐ | ||||
| PROC2 channel 9 | ☐ | ☐ | ||||
| PROC2 channel 10 | ☐ | ☐ | ||||
| PROC2 channel 11 | ☐ | ☐ | ||||
| PROC2 channel 12 | ☐ | ☐ | ||||
| PROC2 channel 13 | ☐ | ☐ | ||||
| PROC2 channel 14 | ☐ | ☐ | ||||
| PROC2 channel 15 | ☐ | ☐ | ||||
| PROC2 channel 16 | ☐ | ☐ | ||||
The below table shows the possible runtime allocations for the features of the IPCC2 instance.
| Feature | Runtime allocation
|
Comment | ||||
|---|---|---|---|---|---|---|
| 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) | ||
| PROC1 channel 1 | ☐ | |||||
| PROC1 channel 2 | ☐ | |||||
| PROC1 channel 3 | ☐ | |||||
| PROC1 channel 4 | ☐ | |||||
| PROC2 channel 1 | ☐OP-TEE | ☐ | ☐ | ☐ | ||
| PROC2 channel 2 | ☐OP-TEE | ☐ | ☐ | ☐ | ||
| PROC2 channel 3 | ☐OP-TEE | ☐ | ☐ | ☐ | ||
| PROC2 channel 4 | ☐OP-TEE | ☐ | ☐ | ☐ | ||
4. Software frameworks and drivers[edit | edit source]
Below are listed the software frameworks and drivers managing the IPCC peripheral for the embedded software components listed in the above tables.
- Linux®: mailbox framework
- STM32Cube: IPCC HAL driver and header file of IPCC HAL module
5. How to assign and configure the peripheral[edit | 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.The IPCC peripheral is shared between the Arm Cortex-A and Cortex-M contexts. A particular attention must therefore be paid to have a complementary configuration on both contexts.
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.