Skip to main content
Associate III
May 9, 2024
Question

Best Practices for Sharing HAL Code Across Multiple Libraries in a Multi-Core STM32 Project

  • May 9, 2024
  • 6 replies
  • 2768 views

Hello STM Community,

I am working on an STM32 project that utilizes both the CM7 and CM4 cores. I have structured my project to include a static library named Utilities, where I'm facing some challenges with accessing the HAL functionality.

Project Structure:

 

 

Utilities
├── .settings
├── Debug
├── Inc
│ └── SOS.hpp
└── Src
 └── SOS.cpp

 

 

In SOS.cpp, I implemented a function to flash an LED in an SOS pattern using HAL functions:

 

 

#include "../Inc/SOS.hpp"
#include <cstdint>

namespace STM::Utilities {
 void SOS::Run() {
 const uint32_t shortDelay = 200; // Short flash duration
 const uint32_t longDelay = 500; // Long flash duration
 const uint32_t endDelay = 1000; // Pause duration between signals

 auto flashLED = [](bool longFlash) {
 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
 HAL_Delay(longFlash ? longDelay : shortDelay);
 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);
 HAL_Delay(shortDelay);
 };

 while (true) { // Continuously send SOS signals
 for (int i = 0; i < 3; ++i) flashLED(false); // Three short flashes
 for (int i = 0; i < 3; ++i) flashLED(true); // Three long flashes
 for (int i = 0; i < 3; ++i) flashLED(false); // Three short flashes
 HAL_Delay(endDelay);
 }
 }
}

 

 

Issue: Clearly I'm encountering compiler errors related to the HAL function calls and the GPIO port/pin definitions. The HAL functionality is accessible within the separate CM7 and CM4 core projects, but not directly within my Utilities library. Of course the CubeMX generated main.c would stay in place but I'd like to be able to operate on those resources from my libraries.

Question: I anticipate the need to create additional static libraries similar to Utilities. To maintain modularity and avoid redundancy, I prefer not to duplicate the HAL code in each library (I don't even know if that is possible). Instead, I'd like to set up a shared HAL library that can be accessed by all other libraries. Could anyone guide me on how to achieve this? Specifically, I'm looking for the best practices to manage and share HAL dependencies in a multi-core STM32 project without embedding the HAL code into each static library.

OR

Is there another mechanism for accessing the HAL from a static library that I am not aware of?

 

Thank you for any insights or examples you can provide!

This topic has been closed for replies.

6 replies

mƎALLEm
ST Technical Moderator
May 9, 2024

Hello,

What kind of compilation error you’re facing?

Could you please provide the trace of that error?

The HAL itself is shared between cm4 and cm7 source codes in CubeHal examples. So I don’t see a constraint to share the HAL between the two unless I didn’t catch very well your problem.

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
rtalanAuthor
Associate III
May 9, 2024

@mƎALLEm ,

Thank you for your prompt reply.


Here are the compilation errors. I have read "UM2609 Section 2.1.2.2, Creating a new STM32 static library project." My library has no visibility on on those functions or definition for the port or pins. I see how they are used in my dual core executable. But giving my library visibility on them is my problem. Further below I will include screen shots of my C/C++ Build Settings. Maybe I'm missing something there.

 

11:06:42 **** Build of configuration Debug for project Utilities ****
make -j8 all 
arm-none-eabi-g++ "../Src/SOS.cpp" -mcpu=cortex-m7 -std=gnu++14 -g3 -c -I"C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/STM32H7xx_HAL_Driver/Inc" -I"C:/Users/rtala/Projects/UAVProjects/HardwareAgnostic/Modules/Utilities/SOS/include" -I"C:/Users/rtala/Projects/UAVProjects/HardwareAgnostic/Modules/Common/Interfaces/include" -O0 -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti -fno-use-cxa-atexit -Wall -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Src/SOS.d" -MT"Src/SOS.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Src/SOS.o"
../Src/SOS.cpp: In lambda function:
../Src/SOS.cpp:31:43: error: 'GPIOK' was not declared in this scope
 31 | HAL_GPIO_WritePin(GPIOK, GPIO_PIN_5, GPIO_PIN_SET); // Turn on the LED
 | ^~~~~
../Src/SOS.cpp:31:50: error: 'GPIO_PIN_5' was not declared in this scope
 31 | HAL_GPIO_WritePin(GPIOK, GPIO_PIN_5, GPIO_PIN_SET); // Turn on the LED
 | ^~~~~~~~~~
../Src/SOS.cpp:31:62: error: 'GPIO_PIN_SET' was not declared in this scope
 31 | HAL_GPIO_WritePin(GPIOK, GPIO_PIN_5, GPIO_PIN_SET); // Turn on the LED
 | ^~~~~~~~~~~~
../Src/SOS.cpp:31:25: error: 'HAL_GPIO_WritePin' was not declared in this scope
 31 | HAL_GPIO_WritePin(GPIOK, GPIO_PIN_5, GPIO_PIN_SET); // Turn on the LED
 | ^~~~~~~~~~~~~~~~~
../Src/SOS.cpp:32:25: error: 'HAL_Delay' was not declared in this scope
 32 | HAL_Delay(longFlash ? longDelay : shortDelay); // Delay depends on flash type
 | ^~~~~~~~~
../Src/SOS.cpp:33:62: error: 'GPIO_PIN_RESET' was not declared in this scope
 33 | HAL_GPIO_WritePin(GPIOK, GPIO_PIN_5, GPIO_PIN_RESET); // Turn off the LED
 | ^~~~~~~~~~~~~~
../Src/SOS.cpp: In member function 'virtual void STM::Utilities::SOS::Run()':
../Src/SOS.cpp:42:25: error: 'HAL_Delay' was not declared in this scope
 42 | HAL_Delay(endDelay); // Delay before repeating the SOS
 | ^~~~~~~~~
make: *** [Src/subdir.mk:19: Src/SOS.o] Error 1
"make -j8 all" terminated with exit code 2. Build might be incomplete.

11:06:42 Build Failed. 8 errors, 0 warnings. (took 193ms)

 

Here is my project structure and include build settings.

rtalan_0-1715266917050.pngrtalan_1-1715267342661.png

I have tried including stm32h7xx_hal_gpio.h and stm32h747xx.h in SOS.cpp to get visibility on those definitions but that generates a ton of new compilation errors that look like this.

 

C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h747xx.h:2211:3: error: '__IO' does not name a type
 2211 | __IO uint32_t AXI_INI7_READ_QOS; /*!< AXI interconnect - INI 7 read QoS register, Address offset: 0x48100 */
 | ^~~~
C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h747xx.h:2212:3: error: '__IO' does not name a type
 2212 | __IO uint32_t AXI_INI7_WRITE_QOS; /*!< AXI interconnect - INI 7 write QoS register, Address offset: 0x48104 */
 | ^~~~
C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h747xx.h:2213:3: error: '__IO' does not name a type
 2213 | __IO uint32_t AXI_INI7_FN_MOD; /*!< AXI interconnect - INI 7 issuing functionality modification register, Address offset: 0x48108 */
 | ^~~~

 

The more I look at the problem I think it might be the need to specifically include certain stm*.h header files or some sort of special setup in my library project. If that is the case can you point me to the documentation that explains that or a sample project?

 

Thanks again for your time,

rtalan

 

mƎALLEm
ST Technical Moderator
May 9, 2024

Hello,

Instead of including stm32h7xx_hal_XXX.h or stm32h747xx.h, did you include stm32h7xx_hal.h:

#include "stm32h7xx_hal.h"
To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.