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. 

 

Update 2025-12-15: Adding link to CubeIDE 2.0.0 video tutorial

  

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!

[nico23]

Hopefully with the v2 the Live Expressions in the debug will be fixed 

https://community.st.com/t5/stm32cubeide-mcus/live-expressions-bug/m-p/647393#M24955

[Kraal]

I appreciate this new direction for the development of the CubeIDE, personnally I prefer Eclipse over VS Code, mostly because I have less experience with VS Code and find it less tidy.

However, how does it combine with https://community.st.com/t5/developer-news/new-strategic-directions-for-stm32cube/ba-p/799537 ?

In this news, it is said that VS Code + STM32 Extension is aimed to be the defacto IDE to use. Which is understandable since ST can concentrate on the compiler+linker part and let MS deal with the IDE part.

 

Best regards.

[bramble]

Hi @mattias norlander ,

Thank you for this info - it seems a sensible change.

I wonder if in the new MX we may be given clearer information about the validity of settings? For example, here's a typical situation were a warning has been raised:

 

I sometimes find these warnings give sufficient info to know how to resolve the issue. However, they're often false alarms that can be safely ignored, and when they are important I think the clues given in the pop-up are not always very helpful. I'm sure that to implement robust and always perfect warnings is not always easy - but I think that improvements in this area would be widely appreciated.

Thanks

[Pavel A.]

@mattias norlander 

> Double-clicking on the ioc-file from inside STM32CubeIDE, will launch the standalone STM32CubeMX tool if you already have the tool installed. 

What if several CubeMX versions are installed side by side? Maybe, let the user chose one? (not the version installed latest)? 

/* Would be nice, but more work: pick the required CubeMX version from the ioc file and keep a list of CubeMX paths for every version. If the path for this version is not known, ask user */

 

[mattias norlander]

---

@Pavel A. wrote:

@mattias norlander 

What if several CubeMX versions are installed side by side? Maybe, let the user chose one? (not the version installed latest)? 

---

I agree that this would be nice, it was part of the initial request. If we can solve that for the November release is another story... We may have to address that later. Another challenge is that when using MX stand-alone IDE does not understand that the file tree is updated. We are analyzing how-to update the File explorer after an MX stand-alone code generation has finished...

 

@nico23 , we are working on Live expressions. Stay tuned... First version will have some limitations vs CubeIDE. I cannot comment on the status of the particular bug you are referring from CubeIDE with respect to VS Code...

 

@bramble , I would say that that is a pure CUbeMX issue. I think that reporting this in a separate thread might give it better visibility possibly leading to higher prio to fix. This  thread is more CubeIDE related. Two different dev-teams.

 

@Kraal , we are shifting our focus towards VS Code. Bandwidth is not end-less which means CubeIDE will get less focus. At some point STM32CubeIDE/Eclipse will be retired and VS Code is our foreseen future. This is not happening today, nor tomorrow. Additionally, the "IDE market" is completely fragmented. Many strong opinions as too which is the preferred tool. Meanwhile as ST we can not invest in all IDE frameworks...
CubeIDE will remain but the focus in VS Code. We will not push CubeIDE users towards VS Code before it is feature on par with VS Code both in terms of beginner-friendliness and debug. And we are not there yet.

More communication on this topic will be provided continuously as we make progress and as we learn based on your feedback. VS Code will be update much more frequently vs CubeIDE, we can address your feedback in a much more agile way than with CubeIDE.

 

Feel free to keep asking questions! :)

[mail239955_stm1_stmicro_com]

I do understand that «the "IDE market" is completely fragmented» and the seamless Integration part is very hard to achieve having to support several products but even if Microsoft has become way more friendly to open source, VS Code is not "really" open source as it should. eg. Eclipse is a foundation.

As many I program in several languages and many projects exploit the strength of more then one.
I find plug-ins better than "customized" IDE.

I never feel comfortable when I'm not in control of the cost of switching to another product and I hope STM is aware of the differences in licensing and controlling bodies and it is ready to help transitioning to other IDE smoothly if necessary.

It would never be to early, since VS Code is being "customized" by several companies, to push MS to make VS Code more similar to Eclipse in terms of licensing and governing body.

thanks

 

[Grant Bt]

Hi. I have a request for the MCU Selector. It would be great if it wasn't a modal dialog box (excuse my terminology if incorrect), if for no other reason than I would like to be able to minimize it!  In Windows the form only has an 'X' on it so you can only Close. There is no option to minimize from the task bar either, so it demands focus aside from using Alt-Tab type application switching (or Win-D to show the Desktop).

There are other ways of preventing the user from going back to the parent (CubeMX) and launching another instance.

[mattias norlander]

---

@Grant Bt wrote:

I have a request for the MCU Selector. It would be great if it wasn't a modal dialog box (excuse my terminology if incorrect), ...

---

I think modal dialogs is a thing of the past and by most people seen as bad UX today... May I ask you to drop this request  in the CubeMX forum instead to state your case? I have pinged my colleague reponsible for MCUFinder/MX. But, it is better to keep MX topics where MX topics belongs... Better visibility/chance for up-votes by other MX users etc...

Kind regards, Mattias

[Pavel A.]

@mattias norlander 

> We are analyzing how-to update the File explorer after an MX stand-alone code generation has finished...

There was another related request, if you've noticed: how to force refresh of a managed project if a pre-build script changes source files (adds/deletes/renames, tree changes as well).

Eclipse has "Refresh policy" that currently applies at post-build. Looks like a pre-build policy is needed? Or does Eclipse already handle this automatically?

 

 

[mattias norlander]

---

@Pavel A. wrote:

how to force refresh of a managed project if a pre-build script changes source files (adds/deletes/renames, tree changes as well).

---

The proposal makes sense. I have added a ticket for it, the reference is: 212551. No commitment made. We will first have a look at the Eclipse community to see if this is already requested/worked on by someone else.

[Kraal]

@mattias norlander Thank you for the info.

As a feedback, I would like ST to keep the "create empty project" that exists today in the pre-release "STM32Cube for VSCode" extension in the future releases. I don't need LL nor HAL in my projects, so this option is the way to go for me.

I prefer to ask for this now before it is too late and the option has been removed.

[mattias norlander]

---

@Kraal wrote:

As a feedback, I would like ST to keep the "create empty project" that exists today in the pre-release "STM32Cube for VSCode" extension in the future releases. I don't need LL nor HAL in my projects, so this option is the way to go for me.

---

The pre-release does already today bring the Empty project. The CMake templates are different vs the ones in the 2.x version you are using. We are playing a lot with the CMake templates and we expect to bring some major updates at some point based on feedback/lessons learned. The main constraint in pre-release is that we don't provide dual-core/TrustZone(S/NS) empty projects. Only for simple single-core devices...

I would recommend anyone today using VS Code 2.x with simple single-core STM32 MCUs to switch to the pre-release. No dependency on CubeCLT, easier to install, easier to update, a bit more features, live data soon coming, ... If feeling uncertain, the pre-release can be tested in a sandbox with the so called VS Code profile feature. This allow you to revert back the VS Code environment (I assume the project is under version control for code base roll-back).

[Kraal]

---

@mattias norlander wrote:

I would recommend anyone today using VS Code 2.x with simple single-core STM32 MCUs to switch to the pre-release. No dependency on CubeCLT, easier to install, easier to update, a bit more features, live data soon coming, ... If feeling uncertain, the pre-release can be tested in a sandbox with the so called VS Code profile feature. This allow you to revert back the VS Code environment (I assume the project is under version control for code base roll-back).

---

I am using the pre-release version, and with the profile feature of VS Code it is good.

I was just emphasizing that the Empty project should stay even after the pre-release takes over and becomes the official release.

[seyit]

Will custom toolchain support be extended in the new version of CubeIDE? It would have been nice to see LLVM and Clang support included.

[mattias norlander]

---

@seyit wrote:

Will custom toolchain support be extended in the new version of CubeIDE? It would have been nice to see LLVM and Clang support included.

---

In CubeIDE this would be a quite heavy investment if we go for normal CDT managed projects with full build GUI support... Furthermore, developers will then ask for example projects with CubeIDE and LLVM. The effort to port 10 000 example projects is significant. That setup is not maintainable.

Instead we can enable this using CMake project types. Nothing is stopping you today to do this. But there is also no documentation available to support you on this journey... Documentation to help developers to manually setup LLVM will be the first step. Then we will assess the situation based on feedback. Stay tuned. :)

Today CubeIDE is also bundling GCC. How many developers will use LLVM tomorrow? Would it justify adding another 700MByte of weight to the CubeIDE installer... Probably not for the average user. Consequently we need to find other delivery mechanisms for a LLVM toolchain.

Do you think documentation on setting this up could be a good first step? This would be based on using CMake projects with limited GUI support... 

[seyit]

Thanks for the detailed explanation! I totally understand the complexity and cost of integrating full LLVM support into CubeIDE, especially considering the legacy of thousands of example projects and the size impact of bundling a second toolchain.

That said, I believe having documentation for setting up a custom LLVM-based toolchain using CMake projects would be a great first step. Even limited GUI support is acceptable for more advanced users who want to experiment or migrate to a Clang-based workflow.

Personally, I'm exploring Clang for its diagnostics and tooling ecosystem, and I know many embedded developers are also starting to appreciate its benefits. If there's a clean, documented path to using it within CubeIDE(even unofficially) it could help gather valuable feedback from the community.

[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?

[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.

[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.