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

STM32H7 dual core devices #844

Draft
wants to merge 9 commits into
base: develop
Choose a base branch
from

Conversation

chris-durand
Copy link
Member

@chris-durand chris-durand commented Apr 10, 2022

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:

  1. Unassign all D2 domain peripherals from Cortex-M7
  2. Activate hardware semaphore 0 event notification on the Cortex-M4
  3. Enable deep-sleep on Cortex-M4
  4. Send Cortex-M4 core to CSTOP state with WFE instruction
  5. The D2 clock domain will enter DSTOP state with the CM4 stopped and no D2 peripherals assigned to the running core
  6. Wait for the D2 domain clocks to be disabled on the Cortex-M7
  7. Initialize platform on Cortex-M7
  8. Lock and unlock hardware semaphore 0 on Cortex-M7 to wake up the M4 core and the D2 clock domain
  9. Clear hardware semaphore interrupt flag on Cortex-M4 and continue boot

The 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.

  • Update device files
  • Enable H7 dual core devices
  • Correctly adapt memory maps in STM32 core module for each core
    • Use one flash bank for each core's application
    • Place Cortex-M4 stack in D2 domain SRAM1
    • Correct initialization of memories (only do it once from one core)
    • Assign memories to cores via lbuild options
    • Shared SRAM for communication between cores
  • Fix device files for size "g" devices
  • Examples
    • blink
    • more
  • make scons debug work for the second core

For the Cortex-M7 core:
- "flash" region is set to flash bank 0.

For the Cortex-M4 core:
- "flash" region is set to flash bank 1.
  The default boot address coincides with the start
  of flash bank 1 (0x08100 0000) for all device sizes.
- Main stack is placed into D2 domain SRAM1 local to
  the core.

Non-default boot addresses configured via option
bytes are not supported yet.
@salkinium
Copy link
Member

Just so this isn't lost: In an IRL discussion we had the idea to build a separate static library that would deal with the communication and place its memory content into D3 SRAM in both linkerscripts. This would allow arbitrary communication mechanisms that are always synchronized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants