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!

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

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

[Pavel A.]

Maybe one can make a [quick] wrapper around clang that pretends to be a gcc toolchain (provides the gcc command). The wrapper will translate the compiler & linker options and fix needed #defines. Many clang options are compatible with gcc. But you'll have to provide the C runtime library (newlib).

This hack can't be recommended generally, just to let you going.

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

[mattias norlander]

Hi seyit,

• For STM32Cube for VS Code users, I recommend keeping your eyes open this evening... There is a pending extension update (on the pre-release) which may bring some nice surprises on this topic ;)
• For STM32CubeIDE users there is a plan for an LLVM document. I hope it will be available in a month.

Thanks for sharing your justification as to why you explore Clang!