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.
Add support for STM32 dual-core devices which contain both a Cortex-M7 and a Cortex-M4 core. Contrary to the RP2040 dual-cores these STM32 devices have heterogeneous cores which require individual application programs.
The blink example is working with the Cortex-M7 core blinking two LEDs and the Cortex-M4 application controlling the other.
With the default option byte settings both cores boot simultaneously. On boot the Cortex-M7 core initializes the clocks. The M4 core waits until the initialization is completed and subsequently starts executing its application.
Correct initialization of memories is not implemented yet. In the current state the CM4 core will zero out all SRAMs that are already in use by the other core. The only reason the blink example runs is that all data from the CM7 is kept in DTCM inaccessible to the CM4 core.
The boot process implemented here is much simpler to what ST recommends.
ST does the following arcane procedure:
CSTOP
state withWFE
instructionDSTOP
state with the CM4 stopped and no D2 peripherals assigned to the running coreThe downside of ST's tedious method would be that D2 clock domain SRAMs are not powered while the Cortex-M7 startup code is running and thus, can't be initialized by the Cortex-M7 before the other core is booted.
I have decided to simplify the whole procedure by not sending the Cortex-M4 to sleep and to just busy-wait on that core until the system is initialized. This is implemented with the hardware semaphore as well. The Cortex-M4 delays boot until the semaphore is locked. The other core will lock and unlock it after initialization is done and the Cortex-M4 continues to boot.
lbuild
optionsscons debug
work for the second core