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

[rtalan]

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!

[SofLit]

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.

[rtalan]

@SofLit ,

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.

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

[SofLit]

Hello,

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

#include "stm32h7xx_hal.h"

[rtalan]

@SofLit ,

I'm making progress. I changed my include to stm32h7xx_hal.h and got an error about selecting a target in stm32h7xx.h. There was a Tip in stm32h7xx.h that suggested adding a preprocessor directive to avoid modifying the header file. So I added STM32H747xx to the preprocessor directives:

 Now I am down to a slew of the SAME error (error: '__IO' does not name a type) that occurs for a myriad of stm32*.h header files.

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         */
      |   ^~~~
In file included from C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/CM7/Core/Inc/stm32h7xx_hal_conf.h:255:
C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_dma.h:144:3: error: '__IO' does not name a type
  144 |   __IO HAL_DMA_StateTypeDef       State;                                                            /*!< DMA transfer state                            */
      |   ^~~~
C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_dma.h:160:2: error: '__IO' does not name a type
  160 |  __IO uint32_t                    ErrorCode;                                                        /*!< DMA Error code                                */
      |  ^~~~
In file included from C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/CM7/Core/Inc/stm32h7xx_hal_conf.h:259:
C:/Users/rtala/Projects/UAVProjects/PlatformSpecific/STM32H747XI/UAVProjectSTM32H7/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_mdma.h:123:3: error: '__IO' does not name a type
  123 |   __IO uint32_t CTCR;     /*!< New CTCR register configuration for the given MDMA linked list node   */

Other than UM2609 I have not been able to find any documentation that would explain what I am trying to do. 

I feel like I'm getting closer.

rtalan

[SofLit]

Add also USE_HAL_DRIVER to the preprocessor directives.

[rtalan]

Hello @SofLit ,

Adding CORE_CM7 to the preprocessor definitions and making a copy of stm32h7xx_hal_conf.h from the CM7 project and adding it to my library project resulted in a clean compile. Though I don't know if it actually works because I'm having unrelated issues and have not been able to test it yet.

My concern is manually copying stm32h7xx_hal_conf.h from an unrelated project into my library project.

1. Is that the correct course of action?
2. Is there a project setting that properly adds stm32h7xx_hal_conf.h to my project?
3. Will stm32h7xx_hal_conf.h need to change in the future?

@SofLit if you tell me that is an acceptable solution I will close this issue as solved.

rtalan