Building Core-Agnostic Library with stm32h755xx.h in Dual-Core STM32H755 Project

[rtalan]

Description:

I am developing a library for an STM32H755-based project, where the library is responsible for controlling LEDs via `HAL_GPIO_WritePin()`. The library needs to be core-agnostic and should work when linked into both the CM4 and CM7 projects. However, I’m encountering an issue with the inclusion of the `stm32h755xx.h` header file. stm32h755xx.h is included by stm32h7xx.h when STM32H755xx is defined in stm32h7xx.h which is a requirement.

The `stm32h755xx.h` file requires either the `CORE_CM4` or `CORE_CM7` preprocessor directive to be defined, as it contains core-specific definitions and includes (`core_cm4.h` or `core_cm7.h`). Since the library is being built independently, it does not know ahead of time whether it will be used in the CM4 or CM7 project. The core definition (`CORE_CM4` or `CORE_CM7`) is specified in the main project but is not known during the library build.

My goal is to have a single library build that can be linked into both the CM4 and CM7 projects without needing to compile separate versions for each core. Is there a recommended way to structure the build so that the library can remain core-agnostic while satisfying the requirement of `stm32h755xx.h`? Any suggestions on how to resolve this issue would be appreciated.

Key Points:

• The library will be linked into both CM4 and CM7 projects.
• The library itself is core-agnostic, with no specific core-dependent code.
• stm32h755xx.h requires either CORE_CM4 or CORE_CM7 to be defined.
• The library build process doesn’t know in advance which core it will be linked to.
• I intend to use this approach with other core-agnostic libraries, for example, a servo library that will be writing to PWM pins.

How can I structure my library or build process to resolve this core-specific dependency while maintaining a single core-agnostic library?

[Tesla DeLorean]

Compile for a CM4 core instruction set

Pass in peripheral addresses via pointers

Keep things generic, and check what it's trying to pull-in / import. Use objdump or fromelf to review objects/libraries

[rtalan]

Just to be clear, if I compile for the CM4 core the library will still work on the CM7 core. Is that correct?

[SofLit · Accepted solution]

Hello,

Almost the same question as here.

You can refer to any H7 Dual core examples.

Lest' say a very simple project toggling a LED using EXTI from here. 

For example the HAL and the BSP are common to the two cores as well as system_stm32h7xx.c file. But some files are specific to one core. 

This is how structured in CubeIDE. In fact there are two subprojects (GPIO_EXTI_CM4 and GPIO_EXTI_CM7)  under a parent project (GPIO_EXTI).

Each subproject has its own configs, paths, flags, etc ..

If you have your own library that is common to the two core, physically (on your drive) it will be available in one place, but you need to include it in CM4 and CM7 if it's used by both.

You need to refer to one of the projects in STM32CubeH7 package or you can start  a project using CubeMx and it will make it for you.

Hope it helps.

[SofLit]

---

@rtalan wrote:

Just to be clear, if I compile for the CM4 core the library will still work on the CM7 core. Is that correct?

---

Not sure.. it depends on the content of the library. There are some aspect to take care of. Theoretically, the instructions generated for CM4 could be executed on CM7 but in some cases due the some specificities of CM7 you can face issues (usage of memory barriers etc ..)