Is ST Cube IDE a piece of buggy crap?

[paulca]

I hope somebody does what I suggest and confirms the hash is indeed the same, rather than going on about untrusted sources

But did you verify certutil? 

[gmb42]

certutil isn't the best the tool for this (verifying an Authenticode signature).

If you're been doing anything MS based from the last two decades, then the PowerShell command

Code: [Select]

Get-AuthenticodeSignature <path\to\file> would suffice.

If you need to go further back, i.e. for an archived item pre-PS, then look at the properties of the file on the "Digital Signatures" tab, then "Details".

[peter-h]

But did you verify certutil?

No; could not get it to run (see screenshot).

[paulca]

I hope somebody does what I suggest and confirms the hash is indeed the same, rather than going on about untrusted sources

No idea on Windows.

On Linux I can just do:

Code: [Select]

paul@UM560XT:~$ cat /mnt/storage/general-storage/software/st-stm32cubeide_1.13.1_17479_20230728_0839_amd64.deb_bundle.sh | sha256sum
dafe704e78edc4517736b4e958b45ccd433d738cd59a1a57060bffa6096beafb  -

There are more elegant methods if your download site offers links to the hashes on a 3rd party.  I don't use them, don't do dev ops, but most Linux deps repos provide mirrors for the md5/sha hashes which can be automatically downloaded and verified locally. 

[peter-h]

There are more elegant methods if your download site offers links to the hashes on a 3rd party.  I don't use them, don't do dev ops, but most Linux deps repos provide mirrors for the md5/sha hashes which can be automatically downloaded and verified locally.

Sure, but the reality is that STM have not set up such a web page. So why doesn't someone here download e.g. that 1.14.1 and confirm the SHA256 hash?

===========

On another old topic

This method works for me for stopping the "random file popup" annoying bug
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/m-p/835352/highlight/true#M38407

It works to stop the startup...s file only however. That file pops up when you do a project build (F11). It does not prevent other files popping up when you do e.g. a restart with


Those other files are whatever piece of code the CPU was running when the above button was pressed. Mostly it is a particular piece of FreeRTOS code (in my case) and in principle you could do the same "suppression exercise" on that.

[tru]

I confirm the same hash of 1.14.1 (downloaded from ST site):
SHA-256: 56F9A6C77145B09F3C0C85DE66316B9EEE57AD8B25985AC2A71B2C8732D4FDD5

[dkonigs]

Just chiming in after another few pages of rants that never stop :-)

I noticed that ST recently started distributing GCC 14.3.

When rebuilding my code with it, I noticed that the exact same code and compiler/linker flags produces a larger binary on GCC 14.3 than it did on GCC 13.3.

Does anyone know what actually changed in GCC 14 to cause this?  Any new defaults/behaviors I now need to tweak?

[peter-h]

I don't know what GCC 14 does differently but this is always the problem, which is why changing the Cube IDE version is completely pointless. It just creates work... and that's before you get to regression-test the whole product and every bit of its functionality

And if your company is somehow required to use the latest tools, then they just waste their time with this stuff, at most new versions.

It is fairly normal to implement optimisation options slightly differently, not to mention actual code generation, so you will not get the same binary with different GCC versions.

[dkonigs]

I don't know what GCC 14 does differently but this is always the problem, which is why changing the Cube IDE version is completely pointless. It just creates work... and that's before you get to regression-test the whole product and every bit of its functionality

I attempted to dig into this a little bit, and I have some suspicions.

GCC 14 does do things a bit differently than GCC 13 when it comes to how functions get inlined by the optimizer.  This creates small differences between the output of the two, but really doesn't explain the big code size difference.

But what does appear to explain the difference, is an increase in a bunch of libc stuff.  In other words, all the core library functions got a little bit bigger and don't seem to be optimized back down.

(Sure, I can knock down code size with some extra compiler flags, but if I apply the same flags to both GCC 13 and GCC 14 the resulting delta between the 13 and 14 builds is still kinda the same.)

[paulca]

If, in a parallel world, STM32 did not release with the latest tool chains in each release, you would get a CubeIDE which you would, if starting a new project, immediately have to upgrade.  Anyone who has tried to upgrade an eclipse instance in place with live projects, only does it once.

IDE independence or IDE agnostic is the "enterprise" approach, but CubeIDE does infest itself into your project if you want to use it's full features.  Basically, if you remove CubeIDE from the picture you are left with a project folder which "might" build if you install all the right tool chains in the right places but likely it will be an effort to port it out of the IDE.

The name for what CubeIDE is rather a "Platform". 

Fixing versions is a valid alternative.  You start a project with Cube 1.2.3 and you stay on 1.2.3 as long as you can.  It does require you stay abridged on the updates in the newer releases for "gotchas" "bug" and "security fixes" that impact you.  When one of these surfaces, where a regulatory or customer invariant requires you to address something fixed in a later release...  then things can get messy.

[peter-h]

Indeed, one does not have to upgrade the editor or the tools. GCC is pretty mature now and it is hard to imagine a scenario where a later compiler would be needed.

Just come across a weird one: these warnings are generated (or stuck from a previous build) even if the code is commented-out



I got rid of them by cut/paste of the offending line(s).

For some reason I have not had this before.

[Siwastaja]

Just come across a weird one: these warnings are generated (or stuck from a previous build) even if the code is commented-out

Did you try closing the IDE and opening it again? Bugs like that are common in almost all IDEs. Just had to "reboot" VS code today because it tried to parse // comments as code - while still coloring those as comments, except a few words in the middle. It's one of the mysteries of the human kind - why IDEs are buggy crap, much more than e.g. compilers, web browsers etc.

[peter-h]

No I just did a cut/paste of each offending line. Good point though.

The answer is probably obvious; Java 
I have never seen a solid product written in Java.

But Cube IDE works 99.9%. I have spent a vast amount of time on it over past 5 years or so... Cube MX I can't speak for (and that does need updates for new chips).

[paulca]

Don't know if it helps,but lately I have shifted between and around new and old IDEs so much I can no longer recall which ones have which annoyances.

Literally the past 4 months has involved, Eclipse, VSCode, InteliJ, Rider, Visual Studio and others.

There is no paradise.  Stop looking save your soul.

[betocool]

Wait...

Wasn't STM32 going to stop the whole CubeIDE development and jump into VS Code + extensions + CMake?

Where's all that?

Cheers,

Alberto

[peter-h]

IMHO dropping Cube IDE would be a really stupid move, because so many users have an investment in it.

[dkonigs]

FWIW, I've recently started downloading the "STM32CubeCLT" package to my systems as well.  Its just the compiler tools by themselves, and is a little bit easier to deal with when you want to have multiple versions around and want to reference them from a build system (or a different IDE).

Right now I've got v1.20.0 (GCC 13) and v1.21.0 (GCC 14) installed.  They also now both come with Clang for ARM, though I haven't yet compared its output.

The only thing really stopping me from moving from GCC 13->14 for my own projects right now is that inexplicable code size increase, which I'd really like a good explanation for.  Right now my guess is that something in libc/newlib got a lot bigger, and I'm not sure if it was intentional or due to a misplaced newlib-nano build setting.  I can probably tolerate the size change in some projects, but others (like bootloaders) are already pretty tight.  Maybe I need to do some of my own experimentation with custom newlib-nano builds to see where this real difference is.

[paulca]

A quick google suggests the inlin'ing thresholds of the optimizer may have changed.  That means it will select more functions for inlining to increase performance at the cost of binary size.

There are tuning parameters.  You can check the binary size with different compiler flags and O levels to see what changes. 

[Kjelt]

Wait...
Wasn't STM32 going to stop the whole CubeIDE development and jump into VS Code + extensions + CMake?
Where's all that?

I did not follow so perhaps someone can elaborate or make a quick summary of what is now available but it looks like they do both ?

https://www.st.com/content/st_com/en/campaigns/stm32-vs-code-extension-z11.html

[peter-h]

I wonder what that is. Cube IDE is fine for editing.

It is the debugging which can get flakey, and they say Cube is better for that

[Kjelt]

I wonder what that is. Cube IDE is fine for editing.

Haven't used it in years, but can you now if you rightclick on any function/definition etc. get all these possibilities ?
Then it would be equally usefull imo.

[langwadt]

I wonder what that is. Cube IDE is fine for editing.

Haven't used it in years, but can you now if you rightclick on any function/definition etc. get all these possibilities ?
Then it would be equally usefull imo.

(Attachment Link)

all there except the chat

[betocool]

Wait...
Wasn't STM32 going to stop the whole CubeIDE development and jump into VS Code + extensions + CMake?
Where's all that?

I did not follow so perhaps someone can elaborate or make a quick summary of what is now available but it looks like they do both ?

https://www.st.com/content/st_com/en/campaigns/stm32-vs-code-extension-z11.html

What it says there. I configured VS Code as the editor but the project resides in STM32Cube. I really only use the "Compile" and "Run" buttons on Cube IDE.

Cheers,

Alberto

[peter-h]

AIUI you can use any editor outside Cube IDE.

Cube has a config option to check for updated files, which IME "mostly" works, so external editing is fine. I still do a Project/Clean Project when importing a load of edited stuff, plus an index rebuild, just in case.

The long term hassle with Cube IDE has been losing the debugger interface, especially when left in running mode (with or without breakpoints). People have advised spending 3+ digits on a Segger but then you lose the integration. I found a huge debugger interface reliability improvement by using the OpenOCD debugger mode (with STINK V3) rather than the GDB Server mode

[dkonigs]

I noticed that ST recently started distributing GCC 14.3.

When rebuilding my code with it, I noticed that the exact same code and compiler/linker flags produces a larger binary on GCC 14.3 than it did on GCC 13.3.

Another random Google search, and I think I may have actually found a possible answer to this question :-)

This post, which isn't exactly for CubeIDE or CubeCLT directly, but also references the GCC 14 update:
https://community.st.com/t5/developer-news/stm32cubeide-for-visual-studio-code-what-s-new-in-december-2025/ba-p/847010

It contains the text:

GNU tools for STM32 - GCC-14

• Newlib is rebuilt with -O2 optimization, trading some code size for better runtime performance, aligning with upstream Arm toolchains.

In other words, they did build the C library differently and that's what has increased code size.  This comes in line with what I observed myself when trying to compare symbol sizes between GCC13 and GCC14 builds of my own current project.  But it also explains why my code size also grew the one time I attempted compiling it with the official ARM GCC compiler just for curious comparison.

I do kinda wish they gave us a choice as to which build of newlib to use.  And while I probably could kludge something myself here, I'd rather not use a customized toolchain if I can avoid it.

Fortunately, if I do decide to move to GCC 14, I currently can spare the flash space for my main firmware.  My bootloader code, though, would need some changes to add headroom.  (It just barely fits in its space as it is, though I know if a few tweaks I can do to shrink it if I absolutely have to.)

Edit: Of course this all led me to the discovery that I was inadvertently linking the full newlib instead of newlib-nano.  After figuring out the linker magic to finally fix all of that and get everything building correctly, I think the real issue is now resolved.