STM32CubeIDE 2.0 release - early heads-up!

[mattias norlander]

Starting from the release in November 2025, STM32CubeIDE and STM32CubeMX will be available exclusively in their standalone versions.

STM32CubeMX will no longer be integrated inside STM32CubeIDE. Instead, the two tools will be interoperable in the same way as with IAR EWARM, Keil MDK-ARM, and STM32Cube for VS Code.

The current integration of these two tools may seem compelling in the early prototyping phases of a project. But the integration leads to heavy/poor performance, stability issues across OSes and monolithic updates. It is time for STM32CubeIDE to go back to its roots and focus on Edit / Compile / debug.

What the STM32CubeIDE (2.0) evolution will bring to you: 

• Greater flexibility in code development thanks to purpose-built, standalone tools. 
  • Updateability: Offering the possibility to use any version of STM32CubeIDE with any version of STM32CubeMX. Separating STM32CubeMX and STM32CubeIDE allows developers to update each tool independently, lowering risks and increasing flexibility. 
  • Project type flexibility: Allowing STM32CubeIDE users to also leverage STM32CubeMX-generated Makefile projects, and CMake projects for additional project flexibility. 
  • Harmonized workflows: Interoperability instead of integration harmonizes the workflows between STM32CubeMX and all IDEs.  

• Better usability and performance for faster project completion: 
  • Faster tool launch and lower PC resource requirements. 
  • Increased stability, particularly on Linux and macOS system. 
  • No log-in required inside STM32CubeIDE. 

Next steps: what is the impact for STM32 developers?  

• STM32CubeIDE 2.0 will be available as an installer package from st.com.
• Previous versions of STM32CubeIDE and STM32CubeMX will still be available to download from st.com. 
• Updating existing installations will require adding a new Eclipse P2 update site to eliminate unintended/unaware updates.
• ST will continue providing technical support on old versions.

• On-going STM32 projects will not be impacted by this update. 
  • However, opening an existing project with a newer version of STM32CubeMX may update your project, depending on STM32Cube firmware used. This issue is not related to the STM32CubeIDE and STM32CubeMX tool split. 
  • Double-clicking on the ioc-file from inside STM32CubeIDE, will launch the standalone STM32CubeMX tool if you already have the tool installed. 

We are confident that this update will bring significant long-term benefits to your development process. Our support team is here to assist you during this transition.

Please feel free to reach out with any questions!

[mail239955_stm1_stmicro_com]

I'm not STM and it seems STM is not using VS Codium. Furthermore repackaging the VS Code binaries doesn't seem enough to influence the code base or the project as a whole. Judging from the sponsors no one is going to have any influence or resource to influence the code base of VS Studio nor the project.

Redis is the kind of program you can fork successfully, Chrome... not so much if you want to actually influence the code base (there is chromium... but eg Chromium will get manifest v3). VSCodium seems to share the same scope and fate.

It's not a problem of technical merits of VS Code. I'd prefer to relay as less as possible on software that depends on the whims of a single company.

It would be nice as for the Linux kernel to see chip manufacturers cooperate in a foundation or sponsor an IDE.

What I've seen is chip manufacturers package their own version of Eclipse + plug-ins + eventually some proprietary binary, many times they don't just publish their plug-in, they repackage Eclipse and then years later they move to VS Code. Still better than when the only tools available were for Windows... but neither of this is a really smooth experience and in fact I've mostly stuck with Eclipse + Embedded CDT.

After years of writing code for STM32XX I just got curious of their new IDE release and learned that they will move to a customized packaged VS Code. VS Code may have some compelling feature...

Could be better... could be worse. I'm not sure but Atmel/Microchip did the same but they are providing just a Windows prepackaged customized version of VS Code.

[PHolt.1]

I stopped updating Cube IDE at v 1.14.1.

Why? Later versions bring nothing useful unless you are using newer CPUs.

And the most immediately annoying thing - the "random" file opening during debug - is not listed as fixed in 1.19.x according to the latest errata. But not even during debug... whenever I load a new code into the CPU, I get a tab with the startupxxx.s opening and getting focus (so any keystrokes go into that file!) so I have to close the file, taking care to not Save it.

[mail239955_stm1_stmicro_com]

I use CubeMX and find it useful.

I had some experience with other manufacturers "customized" IDE but now that the architectures I play with are reasonably standard I haven't been compelled to use "customized" IDE but I'm a big fan of the "integrated" part of IDEs and I just downloaded and installed CubeIDE to get a taste.

At a first look the main difference is that you've to configure debugger and run configuration in eclipse while you find them pre-configured in ST customization.
Any other customization compared to Embedded CDT that could come useful?

I can find application notes and docs in CubeMX, no need to find them in CubeIDE as well.

I can say separating CubeIDE from CubeMX does seem a good choice.

You wrote "Later versions bring nothing useful unless you are using newer CPUs."
How? Isn't support for newer CPU the responsibility of CubeMX?

[PHolt.1]

Yes; Cube MX needs constant updating, for new chips. But once you start on a project, you fix the chip type so no need to change the development software. And ST are not fixing any of the obvious bugs.

[mattias norlander]

---

@mail239955_stm1_stmicro_com wrote:

You wrote "Later versions bring nothing useful unless you are using newer CPUs."
How? Isn't support for newer CPU the responsibility of CubeMX?

---

CubeMX supports "MCUs" with driver/middleware code and graphical configuration.

But we also have to care about compiler support for new cortex-m cores by providing reasonably up-to-date GCC versions. For each new MCU we also have to support flash loading, and visualization of peripheral registers. These are concerns related to CubeIDE, not CubeMX. Some new MCUs bring new security features, this may impact both MX/IDE...

As mentioned in other threads, we are moving towards a more "data-driven" architecture, where flash loaders, peripheral register files and compilers are all smaller cloud-delivered packages (consider P2 in Eclipse). We are making this leap with VS Code only for now. As a result new MCU support will not require a new ST pre-integrated IDE version to be installed. Just a few small patches...

You also had a point about being locked into a silicon vendor IDE vs instead relying on some open framework Eclipse + Embedded CDT which is vendor neutral and driven by the Eclipse foundation. I completely agree with you. Consequently we are trying to de-couple the GUI from the CLI tools and from embedded software code. In a nutshell we want to deliver an ecosystem where our code can configured/built/debugged depending on a limited set of CLI tools. Strap whatever GUI (IDE/editor) on top of that as you want! Our reference, for the foreseeable future, is VS Code. But as you said, we are not in the driver seat of VS Code...

Thanks for your feedback, feel free to comment further and precise more if important points were missed.

[mail239955_stm1_stmicro_com]

Thanks, I did really appreciate your reply and some of your targets are very good news for me.

I'm not familiar with P2 and my first instinctual interpretation of "cloud" is "you can not self host". I can just hope is "Eclipse Marketplace on steroids".

I've finally started to use STM32CubeIDE... and it is Eclipse, just with stuff packaged in.
I do understand the pain of "distributing" and providing customer care for software with many components and dependencies so I'm not surprised you decided to package everything (I didn't check but from what you wrote I've to assume gcc, gdb, openocd...[**]) in STM32CubeIDE instead of providing a plugin... but it is such a pain.

People might say that in the embedded space "containerization" should be the least of the concerns, after all everything get compiled to a single binary but again having to update 3 IDEs + 1, keeping 3 copies of gcc etc... cloning IDEs config or having to switch between them because you have a multi-language project is such a pain.

And I don't think it's even your differentiator as a silicon vendor, because a lot concerns are common to other vendors (eg. gcc arm support).

I don't think STM32CubeIDE is going to improve my workflow too much vs Eclipse + Embedded CDT, somehow I hope it won't so I'll go back to something that is not only vendor neutral but also I can customize once and use in broader scenario with less duplication...
I still have to discover what STM32CubeIDE could offer more vs Eclipse + Embedded CDT, you mentioned «flash loading, and visualization of peripheral registers and new security features». I've to admit I'm not the smartest nor the most successful of embedded programmers but if things were working[*] I don't think they would enhance my productivity much.

STMCubeMX does such a good work I even wrote a python program to "import" STMCubeMX into "plain Eclipse" + Embedded CDT and one to flash/protect/memory dump... STM32 MCU via openocd/serial.

Let me repeat it: I do understand the pain of software distribution... but wouldn't it be better to:

* make STMCubeMX more IDE agnostic/neutral

* distribute STMCubeIDE as a plugin

* oh I'd love you so much if you had a repo where you'd eventually distribute some binaries if STRICTLY needed.
I just saw that STM32CubeIDE upgraded STLink firmware... but I can't see why you should distribute your version of gcc, gdb, openocd (the debian udev seems to be outdated and overlapping, I bet Debian and openocd devs will love you for helping them making their software better and you'd make it more portable).

[*] ./plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.13.3.rel1.linux64_1.0.0.202410170706/tools/bin/arm-none-eabi-gdb --version
error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

I do know why this doesn't work... newer gdb in debian comes with support for multiarch... so there is no gcc-arm-none-eab-gdb so there is no dependency on libncurses5... and probably I'm running a working newer version of arm gcc and gdb if I only could simply check.

[**] yes you did

[mail239955_stm1_stmicro_com]

... not to mention you could help Embedded CDT development. I really never used the "packages" but they may offer the «visualization of peripheral» functionality

https://eclipse-embed-cdt.github.io/debug/peripheral-registers/

[mattias norlander]

I agree with your philosophical view on dev tools. And like you, I think Embedded CDT is a great initiative. If we could start over on the Eclipse track today, I think STM32CubeIDE would be delivered as a componentized set of plug-ins on top of the Embedded CDT plug-ins. Managing pre-integrated installers with tons of duplicated bricks hurts customer and ST.

That said, we are today moving resources to accelerate on VS Code. Most of the pain points you describe with STM32CubeIDE are addressed in our VS Code solution. On the other hand, our VS Code extensions lacks both the mileage and the advanced debug feature-set of STM32CubeIDE... It will come. Step-by-step.

[mail239955_stm1_stmicro_com]

There should be something that makes silicon vendors copy over and over the same mistakes as when everybody was tweaking his semi-private fork of gcc/gdb.

Many vendors moved from Eclipse to VS Code and I do understand the motivations (eg. intellisense, better integration with AI) but I see it as a temporary infatuation.

Total lack of control on the code base is one of the reasons but also they will face duplication of efforts.

Plus I hate Java, but I hate JS more.

I hope for the best.

Right now I fired up STM32CubeIDE to start a new project but due to the problem I faced with gdb/ncurses, I'll probably find a way to import it in Eclipse + Embedded CDT.

I'll miss the opportunity to see if «flash loading, and visualization of peripheral registers and new security features» support do make a difference.

I hope to find the docs to instruct openocd to protect the flash content for the G serie if anything has to be changed and I think I'll be fine.

Thank you.

[mail239955_stm1_stmicro_com]

Hi,

I still haven't had the time to examine carefully the difference between .cproject of Embedded CDT and STM32CubeIDE... I saw some things that could be handy in STM32CubeIDE inspired by Embedded CDT and vice versa and if I'll have enough time I plan to look at the python program I wrote more than 7 years ago to convert STM32CubeMX projects to Embedded CDT.

BTW an old version is here https://github.com/Ivan-SB/lib2eclipse

But the fact that your included toolchain requires ncurses5 is a real pain now.

Unfortunately STM32CubeIDE try to be too smart and when I try to add a local toolchain it complain there is no arm-none-eabi-gdb since debian moved to a multiarch gdb. This could probably be resolved by a symlink but it's not very nice to tweak with system stuff as root and I don't know if it is going to be maintainable.

You'd make adding a local toolchain more smart or less smart.

Embedded CDT uses OpenOCD and the debugger configuration is set in the GDB OpenOCD Debug option menu.

The equivalent setting would be in STM32 C/C++ Application -> project Debug. But there is no option where to chose the gdb binary.

thanks