Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32H747: Cortex-M4 core starting without waiting for semaphore #86494

Open
hglassdyb opened this issue Feb 28, 2025 · 0 comments
Open

STM32H747: Cortex-M4 core starting without waiting for semaphore #86494

hglassdyb opened this issue Feb 28, 2025 · 0 comments
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32

Comments

@hglassdyb
Copy link

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 (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) {
                        ;
                }
@hglassdyb hglassdyb added the bug The issue is a bug, or the PR is fixing a bug label Feb 28, 2025
@JarmouniA JarmouniA added the platform: STM32 ST Micro STM32 label Feb 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32
Projects
None yet
Development

No branches or pull requests

3 participants