STM32CubeIDE - How to rebuild Drivers\STM32F1xx_HAL_Driver sources if a file is missing

[Bags]

I'm planning on moving from STM32F103 for more speed, so in advance of getting a board I thought I would try building an app for the STM32G431... so I found an small example project online that was using an OpAmp feature.

Having got that compiled ok in STM32CubeIDE I backported my app source code into the project (which went ok), but compiling it was missing some definitions for HAL UART structures.

Looking at "Drivers/STM32G4xx_HAL_Driver" in my original project and comparing it with "Drivers/STM32G4xx_HAL_Driver" in the new project I see that its missing some files like "stm32g4xx_hal_uart.h".

 

Is it possible to force STM32CubeIDE to regenerate the Drivers subfolder from scratch?

I always find switching a STM32CubeIDE project between different MCUs a harder job than it should be, e.g. it would be nice if there was a combo box listing MCUs in the project properties.

 

 

[TDK]

STM32CubeMX will regenerate code if you've started your project using an IOC.

Otherwise, you'll have to copy driver files over manually. They should be located at:

C:\Users\%USERNAME%\STM32Cube\Repository\STM32Cube_FW_F0_V1.11.5\Drivers\STM32F0xx_HAL_Driver\

 

[Bags]

Wow that was a really painful process, and I mean it took hours!..... and I still have some unresolved #defs to fix.

Iin the end I ended up doing the following...

Upgrading STM32CubeIDE to latest version, then upgrading STM32CubeMX as well.

Then in MX, installing the STM32G431 MCU package.

Once I got all that back up and running again, I used MX to generate a new empty project.

Ported across my app source codes into that new project, then discovered ST have removed the .ioc graphical editor from the IDE... you now have to now configure STM32CubeIDE to launch STM32CubeMX for editing .ioc files.

NOTE - you have to then close the STM32CubeIDE because it holds a lock on the open .ioc file causing MX to sit around waiting before it can finish launching.

After that I could then edit the new .ioc in MX to reflect the h/w config I needed for my app. NOTE - After generating code STM32CubeMX then prompts with a dialog saying "open folder", "open project" or "close" - The "open project" button does nothing!

You can then relaunch STM32CubeIDE (optionally closing STM32CubeMX), to then continue dev work as usual.

Moral of the story... You can't use a STM32 project that uses a processor that you haven't used before without first using MX to install the appropriate MCU package.... and its quicker to start from scratch than modify and existing project when changing processors.

 

 

 

 

The missing HAL UART files are not an error—STM32CubeIDE only generates UART/USART driver files when the UART peripheral is enabled in the project’s .ioc file. CubeIDE itself cannot regenerate the Drivers folder unless CubeMX is used, so the correct approach is to open the .ioc file, enable the required UART, and regenerate the code. If the project was based on an example that lacks a proper .ioc configuration, the safest solution is to create a fresh STM32G431 CubeMX project, enable all needed peripherals, generate the code, and then move your application source files into it.I handled this by transferring my source files into the new project (for example, using dropbox or Xender for quick file sharing, though any method works). This avoids missing driver issues and is generally more reliable, since STM32CubeIDE does not fully support changing MCUs within an existing project.