STM32CubeMX2 + NUCLEO-C562RE - you need AI?

[KPort]

Finally was able to test STM32CubeMX2 with a NUCLEO-C562RE board.
Simple LED blinking project, and here's what I found out.

Project bloat:
STM32CubeMX2: 26.2 MB of generated data and when compiled 41.1 MB (NUCLEO-C562RE)
STM32CubeMX: 4.6 MB generated and compiled 15.7 MB (NUCLEO-C031C6, same functionality)

The old STM32CubeMX included only the HAL libraries actually used.
The new one dumps everything in.
That's a 5.7x increase for a blink LED.

Missing Release configuration:
Generated CMake project contains only Debug configuration - No Release.
Interesting, because the official "MOOC STM32CubeMX2" video at 4:53 clearly shows both configurations.
Either something changed or the video is misleading.

Creating Release configuration manually requires editing multiple CMake files, including inside the cmake folder — supposedly overwritten on regeneration (in practice, changed only at project creation).
Not trivial if you're not a CMake expert.
I did it once manually, but then ended up using Claude Code AI to do it quickly again.

Linker files buried deep:
The .ld linker files are now hidden under several directory layers (previously at project root).
If you need separate linker configurations for Debug and Release — different memory layouts, for instance — good luck doing that without solid CMake knowledge.
Again, I had to ask AI for help. It's doable, but shouldn't be this complicated.

Bottom line:
The tools work.
If you don't have some CMake experience, will add extra friction.
But basic tasks like Release builds and linker customization shouldn't require AI assistance.

The new interface is fine, just needs getting used to — many settings have moved around.
But a designer tool should better handle these common workflows, not make them this complicated.

Suggestions:
Generate both Debug and Release configurations by default
Include only required HAL driver files
Make linker file customization more accessible

[Andrew Neil]

---

@KPort wrote:

STM32CubeMX2: 26.2 MB of generated data and when compiled 41.1 MB (NUCLEO-C562RE)
STM32CubeMX: 4.6 MB generated and compiled 15.7 MB (NUCLEO-C031C6, same functionality)

---

What, exactly, are you referring to here?

A C031C6 only has 32K flash - so the compiled image can't be 15.7 MB - surely?!

[KPort]

Andrew, I was not measuring the compiled MCU image size.
I was measuring the disk space occupied after STM32CubeMX/MX2 file generation (before compilation) and after compiling for the first time.
That is, how much disk space was occupied in the generated projects.
Conclusion: STM32CubeMX2 creates LOTS of extra and totally unnecessary files.

[LCE]

@KPort Interesting!

Now that you're at it...

Have you compared the resulting image size? Does HAL 2 already blow up simple projects ?

Although this comparison would make more sense with the exactly same MCU.

[AScha.3]

Not the image - total amount of project directory (i suppose).

[Andrew Neil]

I see.

In MX1 there was an option whether to copy all HAL files, or just the required ones.

Also, MX1 would download the entire FW pack the first time you used a part from that pack;  it just didn't put it all into the Project - it had a separate local "repository"

[TDK]

My tests showed that, yes, it does compile significantly smaller. Mostly because the clock setup functions are not as general as they are in HAL/CubeMX. Can't do a 1:1 comparison of course. If your bootloader configures the clock and it's no longer in the default state when the application tries to configure it, it may fail with HAL2/MX2 code.

[KPort]

With MX1 you kind of pay one-time cost for using the HAL.
It loads the whole library once and then in the generated project uses only what is needed.
In my tests the downloaded STM32C031 HAL library occupies 375 MB.
It is located in: C:\Users\<name>\STM32Cube\Repository\STM32Cube_FW_C0_V1.4.0\*.

With MX2 I'm seeing also some downloaded libraries in C:\Users\<name>\AppData\Local\stm32cube\packs\...
So with MX2 it seems to keep some central copy of the downloaded HAL libraries AND copy it all to the generated project.
Suppose there was a good reason to make it this way, but still it adds lots of extra files in the projects (thinking of version control etc).

[Cartu38 OpenDev]

@KPort 
"Suppose there was a good reason to make it this way" ... yes you're ending with self contain project as result what's a win according to me. Now you can share with colleagues, perform a complete source control.

"it adds lots of extra files in the projects" may possibly be optimized but in any case linking process will act at build time so your final binary is going to be the best in any case - confirmed by @TDK -... what's key to me.

[Andrew Neil]

---

@Cartu38 OpenDev wrote:

"Suppose there was a good reason to make it this way" ... yes you're ending with self contain project as result what's a win according to me. Now you can share with colleagues, perform a complete source control.

---

But MX1 gave you a self-contained project: all the files it did use - and only those files - it copied into the Project.