FreeRTOSConfig.h Core-Specific Issue in Core-Agnostic Library for STM32H755

[rtalan]

FreeRTOSConfig.h Core-Specific Issue in Core-Agnostic Library for STM32H755

Description:

I am developing a core-agnostic library for an STM32H755-based project, where the library will be linked into both the CM4 and CM7 projects. The library makes use of FreeRTOS, and I’m encountering an issue when including the `FreeRTOS.h` file in the library.

Each core (CM4 and CM7) has its own `FreeRTOSConfig.h` file, which is specific to that core and is included by `FreeRTOS.h`. The problem arises because my library is being built independently and doesn’t know at build time which core it will be linked into.

The `FreeRTOSConfig.h` file varies between the CM4 and CM7 cores, so when I include `FreeRTOS.h` in the library, there’s no clear way to handle the core-specific `FreeRTOSConfig.h` for each project. This creates a challenge because the library build cannot define core-specific information.

My goal is to have a single version of the library that can be linked into both the CM4 and CM7 projects, without having to compile separate versions of the library for each core. Is there a recommended approach for managing `FreeRTOSConfig.h` in a core-agnostic library, or is building separate libraries for each core the only viable solution?

Key Points:

• The library needs to be core-agnostic and used in both CM4 and CM7 projects.
• Each core has its own `FreeRTOSConfig.h`, included by `FreeRTOS.h`.
• The library build doesn’t know which core (CM4 or CM7) it will be linked into.
• How can I structure my library or build process to handle this core-specific dependency?

Any suggestions on how to approach this problem would be greatly appreciated!

[SofLit · Accepted solution]

Hello,

The issue is not very clear to me but according to the examples already provided in STM32CubeH7, FreeRTOSConfig.h file is specific for each core.

For example, in this example https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/STM32H747I-EVAL/Applications/FreeRTOS/FreeRTOS_HwSemaphoreCoreSync

You can find a FreeRTOSConfig.h file in the path \FreeRTOS_HwSemaphoreCoreSync\CM7\Inc and in \FreeRTOS_HwSemaphoreCoreSync\CM4\Inc 

And in the include path each project has its own paths:

and there is another folder named Common for common files for both cores.

I don't know if I have answered your question.

[rtalan]

@SofLit 

Thank you for your reply.

I understand that each core has its own FreeRTOSConfig.h. My library will be using FreeRTOS and this single library is intended to be used on both cores. So the issue is how do I compile MyLibrary.a for both cores if each core has its own FreeRTOSConfig.h?

Now I understand that FreeRTOS is running on each core and can not communicate across cores. So my idea of starting and stopping tasks across cores is not doable directly with FreeRTOS.

It sounds like communicating FreeRTOS task starts and suspends across cores needs to be accomplished in a different manner.

My intention was to start and resume/stop FreeRTOS tasks via events (event_groups?) across cores.

How would you approach this?

Can I store the events in mailboxes for cross core communication?

Can you point me to an STM tutorial?

Thank you for your time.

[Pavel A.]

So the "core-agnostic" library looked like a easy thing but proves to be complicated. Perhaps abandon the idea and just make two separate libraries?

[SofLit]

Hello @rtalan ,

I don't recommend your approach, as you could face issues. See my reply here.

Simply compile and generate the library for each core.

Do you think there will be an added value with your approach?

[rtalan]

---

Do you think there will be an added value with your approach?

---

In studying event groups I thought it would be simpler to place events in a mailbox and have code from each core check the event (xWaitEventGroupWaitBits) and wait (xWaitForAllBits) for certain bits to be set. And then act accordingly.

I'm starting to understand FreeRTOS a little better as well as IPC between cores. I am studying the two STM GitHub examples you suggested.

I have marked that reply from you as a solution.

Thanks again for your time. It is always appreciated.