You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 (please complete the following information):
OS: Arch Linux
Toolchain: Zephyr SDK 0.17.0
Zephyr 4.0.0
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) {
;
}
The text was updated successfully, but these errors were encountered:
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
CONFIG_STM32H7_DUAL_CORE=n
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 (please complete the following information):
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.The text was updated successfully, but these errors were encountered: