Stm32cube stm32XXX_hal_conf.h / Include search path

[Rainer1]

Hi,

I run into a few issues convertion a cubeMX project for platformIO.
These projects use a project specific “stm32g0xx_hal_conf.h” to enable the HAL drivers.

As already described in :

How to use custom xx_hal.conf.h

I noticed that during compilation a new xx_hal_conf file (in my case stm32h7xx_hal_conf.h) is generated from xx_hal_conf_template.h. This generated file is then used by the compiler. However, I would like to use my own version of this file they provide via STM32CubeMX. How to do it? I tried to add include to main.h before #include “stm32h7xx_hal.h”, but it results in compilation errors: In file included from /home/ppiorkow/.platformio/packages/framework-stm32cube@src-e6db69caf5e38938341a02a8…

Platformio copies the file “stm32g0xx_hal_conf_template.h” to “stm32g0xx_hal_conf.h” inside the folder "C:\Users\XXXXX.platformio\packages\framework-stm32cubeg0\Drivers\STM32G0xx_HAL_Driver\Inc".
What is the sense of this behaviour ?
(The framework for the G0xx has an issue with the usb driver for usb less devices and this behaviour makes it difficult to disable the driver for only one project)

Where can I find an information which folders inside C:\Users\XXXXX.platformio\packages\framework-stm32cubeXX" are already included in the header search path ?
Thanks and regards
Rainer

[maxgerhardt]

The information you’re linking to is outdated since the last two releases of the STM32 platform, per Custom HAL configuration support · Issue #437 · platformio/platform-ststm32 · GitHub.

So just add

build.stm32cube.custom_config_header = yes
build_flags = -I include/

to your platformio.ini and the stm32g0xx_hal_conf.h file will be used if you put it inside include/.

[Rainer1]

Thanks for the response. The correct parameter is:

board_build.stm32cube.custom_config_header = yes

and the file stm32g0xx_hal_conf.h in the folder “C:\Users\XXXXX.platformio\packages\framework-stm32cubeg0\Drivers\STM32G0xx_HAL_Driver\Inc” must be deleted. Otherwise it will be still used.

[copperbot-d]

Hello,

I recently bump into this issue as well, while playing with stm32pio script.
As explain above, I had to add board_build.stm32cube.custom_config_header = yes into the pio.ini, but it gave me compilations errors (missing types defines).

To resolve this, I had to manually activate ALL modules in the “Module Selection” in the xx_hal_conf.h.

I “suppose” PIO tries to compile all by default, instead of doing a selective approach like STM32Cube. So if a module is not defined, it will give you an error.

To resolve this, either try to activate all modules directly in your STM32CubeMx .ioc project, or manually activate all modules after the code generation, as above.