STM32H747: Cortex-M4 core starting without waiting for semaphore #86494
Description
Describe the bug
At the boot time, the CM4 core is supposed to wait for the CM7 to initialize the system before starting the application. To do this synchronization, the CM7 locks one of the hardware semaphores HSEM once it is ready to start the CM4.
However, the CM4 doesn't wait properly for the semaphore before starting. It can even start with CONFIG_STM32H7_DUAL_CORE=n.
To Reproduce
- Make sure to enable both cores in the option bytes (BCM4 and BCM7)
- Build an application for both CM4 and CM7 cores
- Build the CM7 app with
CONFIG_STM32H7_DUAL_CORE=n - Flash both applications
The CM4 will boot anyway.
Expected behavior
The CM4 should only start when the CM7 locks the semaphore.
Impact
Can potentially crash the system depending on what is done on each core.
Logs and console output
N/A
Environment:
- OS: Arch Linux
- Toolchain: Zephyr SDK 0.17.0
- Zephyr 4.0.0
- STM32H747AII6
Additional context
N/A
Possible fix
The semaphore is read from the CM4 side by polling the HSEM->RLR register.
If I understood this correctly, this will read and lock the semaphore if the access is authorized.
Therefore, the CM4 will think the CM7 finished the system initialization and will start booting.
The semaphore should be checked by using the HSEM->R register, which will not affect the value of the semaphore when accessing it. If I use the modifications below, the CM4 will behave as expected.
diff --git a/soc/st/stm32/stm32h7x/soc_m4.c b/soc/st/stm32/stm32h7x/soc_m4.c
index 96762f89b81..0dda673abf6 100644
--- a/soc/st/stm32/stm32h7x/soc_m4.c
+++ b/soc/st/stm32/stm32h7x/soc_m4.c
@@ -47,7 +47,7 @@ void soc_early_init_hook(void)
* (system clock config, external memory configuration.. ).
* End of system initialization is reached when CM7 takes HSEM.
*/
- while ((HSEM->RLR[CFG_HW_ENTRY_STOP_MODE_SEMID] & HSEM_R_LOCK)
+ while ((HSEM->R[CFG_HW_ENTRY_STOP_MODE_SEMID] & HSEM_R_LOCK)
!= HSEM_R_LOCK) {
;
}