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!

[MarcV]

I really don't see the problem... I initially learned to use MX and IDE as two separate programs and only recently discovered that MX could actually be run inside the IDE, which does make things a bit easier. But running MX as a separate program is nearly as easy, except that you now have to push the "generate code" button to regenerate the framework (and make sure to select CubeIDE as the target environment).

Or am I missing something here? :thinking_face:

[unsigned_char_array]

---

@cjay wrote:

I teach using STM Cube IDE and Discovery boards, this step has invalidated *years* of teaching material and raised the bar to entry for students. 

If this carries on and I have to ultimately move to VSCode I might as well get ahead of the curve, save money and give them RPi Pico instead.

---

I've been using STM32CubeIDE and STM32CubeMX as separate tools for years now. I prefer to keep my tools separate. Also because I can use them on separate screens. I archive STM32CubeMX installers and firmware packs and STM32CubeIDE installers. This way I don't need an internet connection to reproduce a build later on.

Nothing is invalidated. The same settings of the integrated STM32CubeMX can be used. It's just in a separate tool. Same buttons.

[mail239955_stm1_stmicro_com]

I just noticed a strange thing just upgrading.

In the newer IDE, MX is not included anymore.

I have a documentation directory in my project. It contains sample code that doesn't have to be compiled or in general doesn't have to be indexed etc... by Eclipse/CubeIDE.
So I "Exclude from build" them.

I had to change the MCU configuration and I had to use the separate MX tool.

This happened just today and I still haven't had the time to really understand what's really happened and I'm not sure the new CubeIDE has to be blamed.

There's a chance that CubeMX should be more aware of what it finds in already started projects.

We all know the usual problems of software engineering... separating stuff makes them more reusable, integrating them makes them easier to use for one task.

I could guess why separating them makes sense now since they are moving to VSCode...

[goga1978]

Hi. How can I create a new project with an ioc file now?
The project is created but without an IOC file?!
HELP.

[Panagiotisg]

Just tried the new 2.0 version and I'm really struggling with the standalone CubeMX window. The constant alt-tabbing breaks my workflow completely. Is there any setting to integrate it back as a tab like in 1.19?

If not, I think I'll stick to 1.19 for now. This change feels like a big step backwards.

[Pavel A.]

@Panagiotisg Could you tell, why switching applications (windows) is harder than switching tabs in Eclipse? Is it just a matter of habit? If you have two monitors, would be more convenient to keep the Eclipse and CubeMX on different monitors?

[MarcV]

You can save your MX project. This does not happen automatically when you generate your project source code.

[Panagiotisg]

Yes, it is certainly partly a matter of habit. Having two monitors would definitely make it much easier, but that is not the only issue. The actual process of setting up and working with two separate applications simultaneously is inherently difficult in itself.

[Jorgie]

I only have one monitor which is a 34" Ultra-wide QHD VA 100Hz Curved Business Monitor.

The issue is that they have removed the integration of CubeMX from CubeIDE to better integrate into VSCode, without understanding the impact on their current user base.

For the last two years I have been able to change settings in the IOC file, via the integrated CubeMX, and see the immediate effects in CubeIDE. 

Now I have to maintain situational awareness across two separate applications.

The developers should have been able to maintain the current integration between the two applications without breaking the VSCode implementation. '

Just because you can should not mean you should make the changes.