What’s new in STM32CubeIDE 2.0.0

[mattias norlander]

Article updated on December 11, 2025. 

STM32CubeIDE 2.0.0 is now available. Here is a summary of the main updates for developers. 

• Support for new products: STM32WBA, STM32N6, STM32H5, and STM32WL3x series are now supported in STM32CubeIDE 2.0.0 

• Expanded board support: now compatible with NUCLEO-WL3RKB1 and NUCLEO-WL3KB3 boards. 

• Login changes: the login requirement has been removed. An optional update notification service will be introduced in a future release. 

• Toolchain improvements: easier installation and use of the ST LLVM-based toolchain for Arm, directly through the STM32CubeIDE GUI. 
• STM32CubeMX is no longer integrated within STM32CubeIDE: it is now available exclusively as a standalone tool.  
  
  

Why separate STM32CubeMX and STM32CubeIDE?

• The integration of STM32CubeMX within STM32CubeIDE was not widely valued by users, yet it required significant development and validation resources. 

• Developers expressed a stronger demand for enhanced debugging features and robust support for VS Code as a free IDE option. 

• There is a clear call for more responsive IDEs and faster update cycles.  

Separating STM32CubeMX from STM32CubeIDE is expected to bring greater scalability, flexibility, and performance across STM32Cube tools. This transition will help support a growing MCU and MPU portfolios and the broader STM32 ecosystem. 

What does this tool split mean for developers?

Both STM32CubeIDE and STM32CubeMX will be available and maintained as standalone products. We will ensure ongoing support for new devices.  

Developers can now update and freeze versions of STM32CubeMX and STM32CubeIDE independently, allowing for greater flexibility. Developers should ensure that STM32CubeMX standalone is associated with .ioc files to avoid conflicts with older STM32CubeIDE versions.  

The video below outlines the recommended workflow for using STM32CubeMX and STM32CubeIDE together. 

What’s next

• CubeIDE will keep supporting current and future STM32 devices.
• Our main focus will shift to improving STM32CubeIDE for VS Code.
• The existing STM32CubeIDE still offers better debugging features.
• Version 2.0.0 makes maintenance of the current IDE simpler and more efficient.
  
  

As always, your feedback is essential in shaping the future of STM32CubeIDE(s). Please share your ideas and questions on the community forum.

First published on Nov 19, 2025

[Wood.Andy]

@wxsatguy 

 

Don't even think of integrating that AI cr@p with something that is used for developing embedded code, if you are not capable of doing it without 'help' then either learn - I know it is a new concept to some - or do something else.

 

Microchip - they really need to develop an IDE first that actually works according to @sksouri 

 

 

 

 

[JAP]

I shake my head seeing that ST is now shifting focus to VS code. I find that platform an absolute mess for professional development with microcontrollers. I see VC code as a glorified text editor and not a IDE which is needed for embedded work.

[KieranSmith]

This is in no way an improvement! It just makes it more complicated to get everything configured an running. I mean you need install a whole other piece of software (that must only be run from the command line), configure the software to work together for every project, then whenever you make a slight change (1 single setting) you must open stm32cubeMX, make the change, generate the code, open stm32cubeIDE, press refresh, then build and compile. I mean you couldn't even remove the requirement to press the refresh button because "it wasn't finished in time for 2.0"). This is so much more annoying to do anything, and so much more difficult to configure. I don't understand why anyone would possibly wants this change. I mean sure its faster and smaller, but its slower to do anything because you have to do stuff separately in cubeMX, and its not a small program because now you have to install 2 programs. Mind bogglingly *** decision, only good things is that maybe I can revert the update... I tried though and stm32cube crashed.

[Niclas Hedhman]

ST has rather quietly released STM32CubeMX2, which seems to be the replacement of STM32CubeMX for new MCU families, starting with STM32C5.

@lbthomsen tries to make sense of the added confusion, unbiaded review of this new pile of disaster that is coming our way; https://www.youtube.com/watch?v=61r83TTzDfk

[Wood.Andy]

@Niclas Hedhman

STM32CubeMX2

Kept that quiet didn't they?

If you already in a hole I thought people generally stopped digging...

 

I just downloaded MX2...

Slow is just one of the words I would use to describe it.

I am sure others with have more ;)

 

[Harvey White]

Several comments:  

I stayed at 1.19 for a long while.  I'm considering upgrading.

1. I understand the need (or desire) to decouple MXIDE and MX.  Makes sense in a development way.
   1. Having MX as a plugin (separately updateable) makes excellent sense
   2. I do think it should work exactly the way the existing .IOC editor is working for best workflow.  Open up the file, look at the tab, edit, and go from there.  Switching programs is highly awkward.
2. VS code.  Now that's a conundrum.....
   1. Microsoft Copilot.
      1. I turn it off.  Microsoft has absolutely no business looking at my code, thank you.  That's one reason I am unhappy with Microsoft.  I may end up going completely to Linux because of Microsoft data collection for "user enhancement".  I think I have most of it turned off
   2. That said, I've not heard a reason why VSCODE is somehow wonderful. 
   3. Considering that, I wonder if you've heard of the program OpenSCAD?  I use it for 3D modeling (it's programming and parametrically based).  The advantage it has is how it treats editors. It does have its own editor, however.  If you pick a different editor, you can tell the OpenSCAD program to monitor the included file for a change.  Save the file in your editor, then OpenSCAD updates the model.
      1. If VSCODE is that wonderful an editor, then perhaps treat it the same way.  You can also use  Notepad++ if you like it.  Might be nice to pick one editor that does syntax highlighting, and then stick with that.  
      2. This approach is perhaps well suited to multiple monitors and split screens.
   4.  
3. So depending on how well 2.x works, I may stick to the eclipse path.  I don't see the VS code option as being all that attractive.  
   1. I don't remember seeing the "here's why it's wonderful" explanation.  It's like your favorite hamburger chain switching from Coke to Pepsi (or vice versa).
4. As a side note, the way I build a project is often based on an existing IOC file (after the first one). I, too, have wished a way to spawn projects off an IOC file, and then go from there. 
   1.  Once the basic hardware drivers are done via the cubemx process, I overwrite the existing main.c file with a generic (and doctored) main.c file.  Since all the modifications are in the user section (can we PLEASE have user defined user sections), regenerating the processor specific code.
   2. I then take my entire ecosystem and add it by specifying another source location.  I add in configuration files as needed, and the project is pretty well configured.
   3. IF this is a good way of configuration, perhaps there might be a few added tools to facilitate this.  That's a future project, perhaps

 

[liteyear]

ST has rather quietly released STM32CubeMX2, which seems to be the replacement of STM32CubeMX for new MCU families, starting with STM32C5.

@lbthomsen tries to make sense of the added confusion, unbiaded review of this new pile of disaster that is coming our way

---

Sweet Jesus. The X post must be seconds away:

"Tacit knowledge is dead! I just recreated a decades old program with AI, and it has 45% more annoying spinny animations. It's horribly slow to do extremely simple things, and the text is too small to read, but at this exponential rate it'll be so much better in the future. I also ignored all those pesky experts who have spent years of detailed effort honing workflows that actually utilise the software - they'll be left behind!"

 

[Niclas Hedhman]

@Harvey White 

I have used, partly because FreeCAD at that time had the topology bug, but more importantly it is a lot more understandable by my brain. And Yes, I did use a different editor.

And many in the STM32 community seem to be trying out alternative workflows to CubeIDE.

Now, with CubeMX2 the .ioc file no longer exist. It has become an .ioc2, is not present in the project directory, but one level up, and has become a "file container" with inner files being of any format, such as JSON, YAML and INI formats (I haven't checked it in full). And this will further reduce the reason to stick with CubeIDE just a little bit.

And you won't be able to escape CubeMX2 if you are interested in any new MCU families. AND vice versa, you can't give up CubeMX because old MCU families are not planned to be supported in CubeMX2.

Personally, I would recommend people to define a workflow based on CMake, as CubeMX supports it and CubeMX2 more or less demands it. Whether that is with VS Code, CLion, vim/neovim or CubeIDE is a lot less important and highly subjective.

[Harvey White]

I use CubeMX for getting the dirty work of configuring the peripherals configured.  I did enough of that on AVR, 6502 and the like,

Apparently, the old HAL drivers may or may not ever be upgraded to all the new features.  MX2 apparently generates HAL2 files, but only for the latest processor they're trying to push. (haven't looked yet)

What I want is configuration similar to what CubeMX does (different UI), so I can spend less time figuring out what goes to what and why.  

Then I spend more time actually programming and creating stuff....

My entire programming system uses a series of #ifdef statements to enable and drop out subsystems.  Display?  Console?  Mesh Networking?  QSPI memory?  Graphics?  all #ifdef enabled.

#ifdef logic is quite limited, C++ logic isn't.

I think I have another project.

I can get it working in 1.19 if I ignore all the improvements in 2.0