stm32f4xx_hal_conf.h replacement issue

[DenDeg]

Hello! I start using stm32pio recently and found some frustrating bug (kind of). Platformio ST STM32 building script (platforms/ststm32/builder/frameworks/stm32cube.py) auto-generates _stm32f4xx_halconf.h file from _stm32f4xx_hal_conftemplate.h and places it to _packages/framework-stm32cubef4/Drivers/STM32F4xx_HALDriver/Inc folder. As result _stm32f4xx_halconf.h file generated by STM32CubeMX and placed into user project Inc dir is ignored during building. That means all very important settings like clocks speed, modules params, ethernet params, etc are wrong. So, all clock dependent peripherals (I2C, UART, etc) does not working properly or not working at all. This building script unwanted behavior can be prevented by adding string board_build.stm32cube.custom_config_header = yes to [env] section of platformio.ini file. My suggestion: stm32pio should add this string to generated platformio.ini file by default. At least in commented out form. That unexpected Platformio building script behavior cost me couple hours of my life =)) BTW, thank you for this project =)

[ussserrr]

You can add that line to the platformio_ini_patch_content parameter of the config file stm32pio.ini (at project section), something like this:

...
[project]
cubemx_script_content = config load ${ioc_file_absolute_path}
    generate code ${project_dir_absolute_path}
    exit
platformio_ini_patch_content = [platformio]
    include_dir = Inc
    src_dir = Src
    [env]
    board_build.stm32cube.custom_config_header = yes
board = nucleo_f031k6
...

This will generate the correct platformio.ini config for you:

[env:nucleo_f031k6]
platform = ststm32
board = nucleo_f031k6
framework = stm32cube

[platformio]
include_dir = Inc
src_dir = Src

[env]
board_build.stm32cube.custom_config_header = yes

I don't think such a specific parameter should be added to everyone's configurations. Some of them might be more related to the F4 MCUs, some to even the concrete chips.

[DenDeg]

This is not a F4 MCU's specific issue. My F4 project is just example. In building script (platforms/ststm32/builder/frameworks/stm32cube.py) _generate_hal_configfile() function is called for any MCU family.

# Generate a default stm32xxx_hal_conf.h
if board.get("build.stm32cube.custom_config_header", "no") == "no":
    generate_hal_config_file()

That means Platformio, by default, never uses _stm32xxx_halconf.h file created by STM32CubeMX and copied to project Inc folder. I'm not Python user, so correct me if I'm wrong. BTW, parameter should be added to [env:boardX] section, not general [env].

[env:genericSTM32F417VG]
board_build.stm32cube.custom_config_header = yes 

[ussserrr]

OK, it's pretty strange indeed. Why this option is not enabled in PlatformIO by default then? Also, it has no mention in the docs at all. Google has only 2 (!) results for the custom_config_header query, including this issue.

[DenDeg]

Honestly, I don't know. =) STM32Cube is a relatively new platform. Also, I'm pretty sure it's not popular platform. You want to use STM32CubeMX for relatively complex MCU's like STM32F417 or STM32H747, not for Blue pill. But people rarely use this MCU's in DIY projects because of its complexity and high price. Arduino libraries also not available for this platform. So, because of platform unpopularity, bugs can be sitting here for years undetected, manuals can be outdated. Anyway, I'm pretty sure this little nuance is worth to be mentioned in stm32pio manual.

[ussserrr]

OK, I hear you. Thanks for great explanation!

[ussserrr]

Hello, I understand this issue might be not relevant for you anymore but can you by any means validate the solution? I've added specified line to the default PlatformIO configuration, build process is still OK, but is there any real impact from the applied patch, I cannot verify. For example, this issue states that also some actual framework files should be deleted for this option to take effect. I guess a 100% confirmation would be to flash the compiled firmware to real MCU that defines some time-sensitive task?

Important! Please use dev branch of stm32pio, only it has this feature atm.

[ussserrr]

OK, I'd verified this feature with Nucleo F401RE board. All is working fine, although in my tests I've had no different results either with or without mentioned option set. I've changing HCLK and therefore all dependent clocks, see screenshot. In the code, I've read frequency value back via HAL_RCC_GetHCLKFreq(), and it has changed accordingly in both cases. Maybe I should've use some other periphery to see any difference. But I guess, it is safe to leave this option set by default for all new projects.

[randomwalk10]

Hello! I start using stm32pio recently and found some frustrating bug (kind of). Platformio ST STM32 building script (platforms/ststm32/builder/frameworks/stm32cube.py) auto-generates _stm32f4xx_halconf.h file from _stm32f4xx_hal_conftemplate.h and places it to _packages/framework-stm32cubef4/Drivers/STM32F4xx_HALDriver/Inc folder. As result _stm32f4xx_halconf.h file generated by STM32CubeMX and placed into user project Inc dir is ignored during building. That means all very important settings like clocks speed, modules params, ethernet params, etc are wrong. So, all clock dependent peripherals (I2C, UART, etc) does not working properly or not working at all. This building script unwanted behavior can be prevented by adding string board_build.stm32cube.custom_config_header = yes to [env] section of platformio.ini file. My suggestion: stm32pio should add this string to generated platformio.ini file by default. At least in commented out form. That unexpected Platformio building script behavior cost me couple hours of my life =)) BTW, thank you for this project =)

thank you. this solved my problem. surprised that until today(2022) this is still a common problem not explained by the official tutorial.