How to handle framework file templates for stm32f7xx

Development Platforms
1

I am running into a problem with the stm32cube framework and the generated board specific template files for the disco_f746ng. Specifically the f7/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_hal_conf_template.h. When working with the disco_f746ng, the ethernet interface is incorrectly named DP83848_PHY_ADDRESS instead of LAN8742A_PHY_ADDRESS.

The stm32f7xx_hal_conf.h file being generated from the template is incorrect for the board type. I have tried using my own local stm32f7xx_hal_conf.h file as generated by STM32CubeMX, but the only way I could do that was to completely remove the “framework = stm32cube” line from my env block and include all the library files by STM32CubeMX. This leads to other problems like not being able to find _init reference when linking. What is the best way to handle this?

I ultimately would like to have a configuration that I can auto generate through STM32CubeMX, and compile through platformio without having to massage it into a state that it can be compiled. I would like to be able to use the most recent firmware releases from ST through STM32CubeMX. The current state of the stm32cube framework does not seem to mesh well with how easily platformio claims to work. Granted, I am very new to platformio, VS Code, and MCU coding in general, but it has to be easier than this.

-Freeman

2

You can update these files in ~/.platformio/packages/framework-stm32cube

3

I just ran into this same issue, as reported on GitHub.

The directory is now called ~/.platformio/packages/framework-stm32cubef7, but I don’t understand how editing this will help. The Nucleo has a LAN8742A PHY, not the DP83848 that is in the STM32Cube headers - it differs in some subtle ways, enough to require different #defines to get it working with LwIP.

Given that the default does not cover all STM32 boards, and that there is no mention of LAN8742A in the stm32cubef7 files, one solution would be to remove that conf file (as mentioned on GitHub), and add it back in the project, where it can be modified as needed. Right now, the one in ~/.platformio always takes precedence, and prevents such an approach

4

Update, solved by Valerii Koval on GitHub - the trick is to add this config line to platformio.ini:

board_build.stm32cube.custom_config_header = yes

I think the people at PlatformIO are clairvoyant - they solve problems before you run into them :slight_smile: