Associate

Solved

IDE Version 2.0.0 - why remove MX ?

Forum|Forum|5 months ago
December 8, 2025
33 replies
8391 views

Why, oh why have you separated IDE and MX such that .ioc files can no longer be opened in IDE?

I cannot imagine any benefits and it makes the IDE significantly worse, such that I've felt compelled to revert to version 1.19.0 ( go to Help -> About STM32CubeIDE -> Installation Details -> Installation History -> select version -> Revert)

I couldn't find any other means of feeding back my strong dislike of this change other than a post like this. I hope version 2.1.0 comes out soon and re-integrates MX and IDE!

STM32CubeIDE

Best answer by mattias norlander

Hi,

The main reason is the cost this integration brings inside our organization. MX is released 3 times per year in-sync with silicon launches. But, internally, a new version of MX is integrated into CubeIDE every week. Every week end-to-end test campaigns are executed to validate the progress of upcoming STM32 product launches. Amazing amount of R&D-hours are spent on just integrating and validating MX+IDE.

The end-users benefits from this integration are mainly: Download a single tools and no need to ALT-TAB between MX and IDE.

Meanwhile the integration brings cost and risks:

Mixing apples and pears: Over time most STM32 developers learns that working with stand-alone MX and IDE is a good insurance to mitigate tool related update risks and thereby frustration and project delays. Have a look at the CubeMX release history, many patch releases has been provided to fix code generation issues. The IDE features are rarely suffering from regressions. The IDE release cycle is completely hostage to MX.
MCU roadmap: ST has an aggressive MCU roadmap ahead of us. Tightly integrated tools like CubeIDE 1.X in combination with aggressive MCU roadmap is both a huge risk. Due to MX integration there is a real risk that CubeIDE is not ready in-time for an STM32 product launch. In any other IDE, target support is the simple part.
Integration cost: All R&D-effort spent on integration/validation could have been spent on feature and bug fixes.
2x IDEs: Developers are more and more asking for VS Code and we need to split our R&D-bandwidth across two IDEs (Eclipse + VS Code).
Technical risks: The integration of Java/Swing and Java/SWT has been an exciting journey full of GUI surprises across our releases. Unclear how long this integration bridge will be maintained (not under ST control).

We have spoken to many customers in-advance of splitting these tools. Both small and large companies. The split is a bit more appealing to larger companies, and a bit less to small companies and beginners. IAR, Keil, VS Code, and CLion users are already exercising these workflows. And many CubeIDE users already realized that using MX and IDE in stand-alone mode allow them individual tool updates/freeze providing a good "risk approach" towards STM32 development.

The saved R&D bandwidth can help us secure that we can offer 2x IDEs in-sync with new STM32 product launches. Hopefully we can even fix a bug or two in the category of edit/compile/debug. That would be cool!

If I am correctly informed, CubeMX 6.16.0 contained some code generation bugs. Therefore, a bug fix release of MX will follow. In the integrated CubeIDE 1.X world, this would have forced a re-integration, re-validation and re-delivery of CubeIDE as well. Causing ST R&D-team a few weeks of delays or lost focus. Which could have been spent on real value-add! By splitting the tools we will hopefully not have to provide a patch release on CubeIDE as a consequence of CubeMX issues. That would be an amazing long-term win! ;)

We are not aiming to re-integrate CubeMX into CubeIDE.
We must get back on the track where our R&D-dollars are spent on tool innovation, not tool maintenance.
We understand that this will hurt some developers, and for this we are sorry! The "interoperability journey" between stand-alone tools can still be improved.

Kind regards, Mattias

Show previous replies

mattias norlander

ST Employee

@Andrew Neil, indeed the split leads to 2x tools to download and install. The fix is however not to integrate everything into one installer. If we have a single installer including everything, a single bug in any of the integrated tools would require an update of the huge installer. And again, how many % actually needs that update?

The solution is to have a look at how other more modern programming languages are sourcing libraries and tools. The trend in modern programming languages is to leverage package managers and project manifest files to solve both the initial getting-started friction but also the updateability of individual tools and the of locking of the tool environment per project in larger teams.

Arm Keil Studio is a good example of a new IDE environment which is tackling these getting-started issues in a good way leveraging vcpkg as package manager. Have a look at this project tool manifest file:

https://learn.arm.com/learning-paths/embedded-and-microcontrollers/vcpkg-tool-installation/config_creation/

In the link above you will see that the vcpkg-configuration.json mainly lists CLI build tools.
But nothing prevents this type of package manager to set dependencies on CubeMonitor, CubeProgrammer, TouchGFXDesigner, etc...

This is how modern programming languages offer stream-lined workflows... and a kick-ass getting-started experience! And they do it without jeopardizing silicon vendor maintainability, end-user updatability and end-user reproducibility. It is a win-win-win.

We are not there yet... But we have the basic bricks to get there. Our response to vcpkg is the cube bundle manager, which has been introduced with our VS Code extensions. It has the potential to solve all these issues, but it will take a bit of time. In the future we can imagine that a beginner arriving at the doorstep of STM32 world can start by just cloning an ST example project on a machine containing ZERO ST Cube tools. The example can bring a small bat-file (example_install.bat?). Executing the bat-file can download/install CubeIDE, CubeProg, CubeMonitor, TGFXDesigner, ... on his machine by a single click while this guy is enjoying a cup of coffee. We are not there yet. But this is the potential.

"Thumbs up" if this sounds like a compelling future vision?! :)

Andrew Neil

Super User

I wasn't suggesting that there be just 1 installer to install everything;

rather, a facility to bundle bundle together a set of required tools, download them together, and then install them together

Which does sound like the "Package" idea ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

mattias norlander

ST Employee

Ahh. Then I think we are on the same page here! :)

L

Leon3

Associate II

I read this link about the reasons for splitting. When I understand correctly, the main reason is that in fact two products need to be maintained and this is where, thinking out of the box, I see another solution.

Why not use a single product, the MX plugin. By doing so this plugin can be used for CubeIDE and for the stand alone product. All that needs to be created is a container application using the same plugin.

When I understand correctly, CubeMX is a stand alone application which is a different product from the CubeIDE plugin. By moving to changing CubeMX to a basic container for the same plugin this solves a lot I think.

mattias norlander

ST Employee

Hi @Leon3 ,

Thanks for sharing ideas. Not sure I follow fully. My reply may thereby completely miss your point... I will share anyway :)

If I understand your idea, that would be to ensure that CubeMX (regardless if stand-lone or inside CubeIDE) is delivered as a plug-in inside a "container". The problem is that CubeMX was developed more than 10 years ago in Java/Swing framework. The CubeIDE project started after that based on Java/Eclipse/CDT/SWT. Two frameworks which are not compatible. We use a lot duck tape to "integrate" them together... Since they are relying on two different frameworks, the marriage is challenging... Re-implementing MX in Java/Eclipse/SWT would cost a lot.

As a side-note, ST has another IDE targeting our Automotive MCUs called Stellar Studio:

https://community.st.com/t5/automotive-mcus/stellarstudio-8-0-0-officially-pushed-compliant-for-java21-and/td-p/833937

In Stellar Studio, the "MX" equivalent tool was developed as an Eclipse plug-ins. This solves the "integration issues" of not having two heterogenous GUI/widget frameworks. That was a deliberate design-choice from the start. They even provide target support packages / SDKs using Eclipse P2 update mechanism. The way an Eclipse-based IDE should work. In CubeIDE, we cannot leverage these update mechanisms, because CubeMX is in-charge of bringing target support, drivers/middleware/etc in a way which is not maintainable or updateable at all without heavy release work.

... I keep repeating myself walking into the same rant again with slightly different words.
Thanks for brining this idea to the table (if I understood it well, if not please elaborate in a PM). We are always interested in ideas!

K

Kiboxxx

Visitor II

OK to sum things up: ST wants to cut costs. End of story.

mƎALLEm

Technical Moderator

Nothing to do with costs...

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.

B

ben2ben

Explorer

lets not hire more engineer to fix this

lets just remove it. Management at its peak!

Andrew Neil

Super User

It's not removed - it's just separated.

It doesn't seem unreasonable to do this so that the engineers can do actual useful stuff, rather than just deal with the added complications which integration brings - to little benefit..

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Andrew Neil

Super User

There's a vote here in favour of the split !

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

F

fpgiovanini

Associate II

Why, instead of improving and making the user's life easier, is the goal to make it more difficult,
susceptible to errors, and with senseless changes?

Besides the uncontable software bugs, an update every 3 months.

Give me a break.

V

vybor

Associate III

Separation IDE and MX is bad idea.

Anyway, developer should have option to select integrated or separated tools.

Eclipse has good module structure and no problem to add addition plugins.

T

tom9900

Associate

这两天我在安装stm32CubeIDE,版本2.0.0，发现里面没有MX,以为安装有问题，原来是版本的问题

Translation:

Over the past couple of days, I've been installing STM32Cube IDE, version 2.0.0, and noticed that MX was missing. I initially thought there was an issue with the installation, but it turns out it was a version compatibility problem.

V

vybor

Associate III

ST throw out single competition advantage. Without integrated Device Configuration Tool remain no reason to use CubeIDE.

On other side, ST code generator generate bad code. One can use it as start point to write own code only. To see used registers of perifery device without reading manuals.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded