cancel
Showing results for 
Search instead for 
Did you mean: 

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

Bags
Associate III

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.

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Bags
Associate III

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.

 

 

 

 

View solution in original post

2 REPLIES 2
TDK
Super User

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\

 

If you feel a post has answered your question, please click "Accept as Solution".
Bags
Associate III

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.