STM32CubeIDE 2.0 release - early heads-up!

mattias norlander · ‎2025-06-09

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!

nico23 · ‎2025-06-16

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 · ‎2025-06-16

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 · ‎2025-06-16

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. · ‎2025-06-16

@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 · ‎2025-06-18

@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! :)

Grant Bt · ‎2025-06-18

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.

Pavel A. · ‎2025-06-18

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

Kraal · ‎2025-06-18

@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 · ‎2025-06-19

@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