stm32h7: synchronize cores properly during boot #90668
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reorder the HSEM semaphore ID definitions to be sorted by ascending value. The dummy defines are also changed to be sorted in the same order. The definitions for STM32MP1 are already in an order that follows this order so they don't need to be changed. Signed-off-by: Mathieu Choplain <[email protected]>
github-actions
bot
requested review from
djiatsaf-st,
erwango,
etienne-lms,
FRASTM,
gautierg-st,
GeorgeCGV and
marwaiehm-st
etienne-lms
reviewed
May 27, 2025
mathieuchopstm
force-pushed
the
stm32h7_dual_core_sync_cores
branch
from
bc8bbb5 to
28440f0
Compare
etienne-lms
reviewed
May 27, 2025
JarmouniA
reviewed
May 27, 2025
The fifth HSEM (#define is equal to 4 due to zero-indexing) is used on STM32H7 to synchronize the two cores. Update the comment above the SEMID define to reflect this alternate usage. Also remove the associated define CFG_HW_ENTRY_STOP_MODE_MASK_SEMID, which is unused. Signed-off-by: Mathieu Choplain <[email protected]>
On dual-core STM32H7, the Cortex-M4 core is supposed to wait until the Cortex-M7 initializes the system before starting to execute. CM7 should signal this by locking a specific HSEM, which CM4 should poll until locked. However, the logic on the Cortex-M4 side was reading the "RLR" register of HSEM, which *locks the semaphore on read* - in turn, this makes the CM4 start directly since it sees that the semaphore is locked (by itself). Use proper LL API to read HSEM status - which will read the "R" register instead - to make sure CM4 doesn't begin execution earlier than it should. Suggested-by: hglassdyb Signed-off-by: Mathieu Choplain <[email protected]>
mathieuchopstm
force-pushed
the
stm32h7_dual_core_sync_cores
branch
from
28440f0 to
0362bab
Compare
|
JarmouniA
approved these changes
Jun 4, 2025
etienne-lms
approved these changes
Jun 4, 2025
erwango
approved these changes
Jun 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On dual-core STM32H7, the Cortex-M4 core is supposed to wait until the Cortex-M7 initializes the system before starting to execute. CM7 should signal this by locking a specific HSEM, which CM4 should poll until locked. However, the logic on the Cortex-M4 side was reading the
HSEM_RLRregister to obtain semaphore status, which locks the semaphore on read - in turn, this makes the CM4 start directly since it sees that the semaphore is locked (by itself).Replace raw register read with call to proper LL API, which will read the
HSEM_Rregister instead ofHSEM_RLR, to make sure CM4 doesn't begin execution earlier than it should, and update the comments insoc_m4.candsoc_m7.crelated to this boot process.Fixes #86494 - confirmed working on STM32H747I-DISCO by flashing
samples/basic/blinkyon Cortex-M4 andsamples/hello_worldon Cortex-M7. With patch, the LED can be seen blinking only ifCONFIG_STM32H7_DUAL_CORE=y(andCONFIG_STM32H7_BOOT_M4_AT_INIT=yif theBCM4option byte is disabled) - without patch, the LED can be seen blinking in all scenarios if theBCM4option byte is enabled.First commit tidies
stm32_hsem.h- mostly cosmetic changes, but I also removed the seemingly unusedCFG_HW_ENTRY_STOP_MODE_MASK_SEMIDdefine. This commit can be dropped if preferred.