STM32CubeMX Deletes Folders when Generating Code

[Richard Lowe]

I know why engineers have round red marks on their foreheads now. Slamming their head in the desk repeatedly.

I have a STM32H757I-Eval board that I am trying to setup with TouchGFX. I'm using STM32CubeIDE. Because of a bug, you cannot generate the template under root because TouchGFX will not find the root .project file.

So, generating the project with the virtual folders and file links. The issue is that the CM7 project has several link deleted on re-generation of the project.

1. Make a change in CubeMX.
2. Generate code
3. Middlewares folder missing in CM7 project
4. STM32h7xx_HAL_Driver folder missing in CM7 project

I can copy and paste the folders from the CM4 project and fix the 172 compile errors but this isn't a long term fix.

Any ideas on what I could change to fix this?

[Pavel A.]

Choose to use links to shared library files instead of copying to the project folder (in Project manager tab)

​

[Richard Lowe]

Tried that. Completely mangled the project to where it couldn't find any of the references.

It even deleted all my original BSP files. Thank you git.

[Piranha]

You are trying to regenerate it with a CubeMX, which brakes something with every new version. And on top of that you are using Eclipse (CubeIDE), which is famous for making the development process into fighting with the tool.

Edited by moderation team to adhere to community guidelines

[Richard Lowe]

In the back of my mind, I've come to the same conclusion. I had hoped that it was just me and that I don't use it as it was intended. Sad, I really love the idea and have high hopes that ST can get it together.

[Piranha]

The whole C code generation idea is fundamentally absurd.

1. With the tool evolving, everyone will ask and more and more features will be added. With an every new feature the complexity of the tool and code generation scripts rises, often exponentially. That means the further they go, the harder the effort will become.
2. Even with all of that effort, the resulting code one can get is effectively a static initialization code. In an any non-trivial project the initialization code takes 5% or less of an effort. If one cannot develop that, there is no chance of developing the other 95% of the code, which is specific to the project and cannot be generated even theoretically.
3. Real life projects often need some dynamic reconfiguration. Again, one cannot generate it, because the generated code is static.
4. For some uses of peripherals one will have to develop a custom drivers anyway. For example, to implement a decent stepper motor pulse generator based on a hardware timer. Or to implement a communication with a Trinamic stepper driver chip through their UART protocol. In both cases one has to develop a custom drivers. Trying to use a generic HAL for such non-generic purposes can only make things worse and harder.

Edited by moderation team to adhere to community guidelines