Associate

Solved

IDE Version 2.0.0 - why remove MX ?

Forum|Forum|9 months ago
December 8, 2025
57 replies
9100 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

Thanks for your feedback @vybor!

CubeMX was developed 5 years before the CubeIDE was even started. CubeMX is a Java/Swing based application. It is not an Eclipse/RCP applicatoin and consequently not at all a module which can be easily fit into the Eclipse/CDT based CubeIDE. The MX integration into Eclipse is a nightmare. Over the year we have improved the stability, UX and performance a lot. But it is still a bunch of duck-tape keeping the beast together.

Meanwhile new EU/Global CRA legislation is emerging in the world putting more pressure on software companies to manage cyber resilience and vulnerabilities. The more software bricks integrated into one monlithic package the higher risk/cost.

But let me instead try to reply to your points (the way I interpret them, sorry if I missunderstood):

Yes, Eclipse has good plug-in structure we know the framework well and some of our developers have the rank of Eclipse/CDT contributors (up-stream merge permission in the community source tree). Trust me, we know Eclipse. We know the main contributors behind and we meet with them on a regular basis. CubeMX is however not an Eclipse/RCP application.
RAM usage etc... I guess you are hinting at the "performance and stability" rationale behind the split? 80% of our user base is on Windows, based on your screenshots, I assume that you are too. Good for you! Thanks to the larger CubeIDE user share on Windows we have over the years received and fixed more bug reports on Windows. Meanwhile the Linux user base is more fragmented... They are using various distributions, versions and window managers... The number of combinations to support?! We have no chance to validate all that. Nor setup environments to fix those bugs. And Eclipse/CDT is normally running fine on top of most Linux distributions. It is often the CubeMX/IDE integration bridge (the duck-tape) that is bringing the bad performance/stability (we have looked for options).
Screenshot with multiple windows. If CubeMX was an Eclipse plug-in, we could probably allow users to open multiple ioc-file at the same time in one single Eclipse window instead of the awkward work-around of opening a bunch of "new windows". You can do it. But it raises the questions: "If you are willing to go that far, why is it so painful to have one or several stand-alone MX tools opened?" (question is sincere)
I also saw your post in another thread: "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.", source.
No doubt that generated code is not necessary optimized for footprint or speed, but more as a simple getting started. And furthermore, over the years CubeMX releases have lead to some code generation regressions requiring patch releases (also forcing patch releases of CubeIDE due to the MX integration). This is why I always recommend users to use CubeMX as a copy-paste tool. Use it for prototyping. When starting the real projects focused on firmware or application code development, copy the driver and init code you need across into an empty project skeleton relying on a GNU Makefile or CMake file structure. This cuts your project dependency both vs CubeMX but also vs CubeIDE and its native .cproject files (.cproject file locks you into the STM32CubeIDE tool). Yes, by following my suggestion, you lose a bit of beginner-friendly "GUIs", but you also gain in terms of tool flexibility, tool independence and you prepare your project for efficient CI-system integration. Five years from now, when you are tired of CubeIDE/Eclipse, you can easily migrate to any IDE of your choice because you chose Make/CMake instead of native CubeIDE .cproject format.

I am not bashing against CubeIDE nor CubeMX. They are great tools. I consider them great tools. But they need to be used in the right way at the right time.

I have written many replies on the topic of the "MX/DE split"... :) Feel free to click on my profile and go through the different latest replies to see more of the rationale behind... None of the arguments will, isolated, convince anyone that the split was necessary. But when you combine get the picture it is evident that we should never have engaged on the "integration" form the start.

Furthermore, there will be more tools coming in the future, and integrating them all into CubeIDE will not scale at all.

Thanks for sharing your opinions. I am not sure if any of these arguments will reason with you. But maybe the arguments will reason with someone else reading this thread...

Kind regards, Mattias

V

vybor

Associate III

Eclipse 4 allows use any graphic library for GUI (Swing, SWT, JavaFX). Not big problem to convert standalone GUI app to set of Eclipse plugins. Eclipse development may be more simple due to uderlying OSGi platform with a lot of fuctionality. One don't have to invent wheel.

OSGi platforms in ERP / electronic commerce deploys hundreds of bundles from many subsystems. These system serves thousands of requests from thousands of clients per second. You make problem from deploing two. CubeIDE/CubeMX is very little system with no load.

Eclipse based application runs in 2005 on computer with Pentium 3 and 2 GB of RAM. Now om my home PC 32 GB of RAM.

As to resource consumption, integrated IDE/MX application consume less memory than two separate application. First case require one JVM, second require two JVM. And second app loads a lot of common plugins second time. Communication of two subsystems in one process (address space) is much more efficient than between two processes.

Separation is bad solution from any point of view.

Pavel A.

@vybor Please consider that CubeMX isn't used exclusively with CubeIDE (Eclipse). Many customers migrate to VS Code or use other IDEs (IAR, Keil, Segger...). All these users don't benefit from integration of CubeMX at all.

We started with the standalone CubeMX long before the [integrated] CubeIDE, with other Eclipses: Atollic and SW4STM32, Keil, IAR and what not. It worked very well then, and we don't miss the separation in version 2.x.

Few remaining wrinkles should be easy to fix (for one, the default project mode in CubeMX is IAR, so the user must remember to select CubeIDE every time. Impossible to make the project C++ right at the creation)

Suggest you to get two monitors, keep CubeMX on one and the editor/IDE on another. Enjoy.

V

vybor

Associate III

Strange position. Instead of attract users to use ST tool CubeIDE company stimulate them to switch to tools of other vendors. Without integrated Device Configuration Tool there is no reason to use CubeIDE. As standalone IDE Keil is better. ST can close CubeIDE project.

CubeIDE 1.x has one competitive advantage - integrated Device Configuration Tool wich make iterative development easy. ST kill it by own hands. I press Ctrl-S buttons in Device Configuration Tool window and have updated files in CubeIDE window. No more movements. Yes, I have two monitors and after IDE start I create new window and have CubeIDE on first monitor and Device Configuration Tool on second.

ST has strange approach to write code - a lot of unnecessary code and data movement. Look at initialisation code from CubeMX, it is terrible.

Andrew Neil

Super User

Hey @vybor - please can we keep this thread to the topic of separating CubeMX from CubeIDE ?

You already have a separate thread for your gripes about the generated code.

@vybor wrote:
Without integrated Device Configuration Tool there is no reason to use CubeIDE.

I disagree.

CubeIDE remains a good IDE - comparable to any other chipmaker's free offering.

@vybor wrote:
As standalone IDE Keil is better. .

I find that questionable, but you're welcome to use it if you wish!

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.

J

JeronymJ

Associate II

Split from CubeIDE 2.0 does not open .ioc files - which is solved - to keep discussion of the pros & cons in one place.

It used to be separate years ago. So going back in time to make it worse again? ...
Terrible dicission and no reasonable explanation.

I am downgrading back. to previous version and hope you in ST get reasonable again.

McClean

Associate

Oh.. i dont believe it! The version 2.0 suxx. How can st ruin a fine solution without any need?

V

vybor

Associate III

ST software team is deceiving customers. Two separate applications require more resources than one integrated.

Separated solution require one more JVM and load some common resources second time. ST needs new software team. Any way, it's not serious to worried about two hundred dollars to add 32 GB of RAM to developer workstation.

fred bar

Senior

I would not go that far. The software team does what product managers plan to do. Problem is not how it is done, which would be on their shoulders. Problem is the direction the product is headed to, which is above them.
Anyhow, i always felt eclipse was a bad choice, VC is not a better choice. If only they used netbeans at the beginning, and now switched to a being a jetbrains clion plugin, we would all be in much better hands and using much better technical solutions.

V

vybor

Associate III

Cube is sample of total negligence.

Look at MCU/MPU selector. It is student's work.

When main window had started user even don't start select a MPU. Nevertheless, table in right-botton side contains

all the MCUs. It is wastefull use of resources.

All MCUs has prefix STM32. User have to type useless 5 symbols. After each new symbol request is made and two

lists is updated and filled with new items. Very long at begining. Now one use long lists for scrolling while searching. If items not fit in visible area, user enter next symbol to narrow presented list.

Presented MCUs product info is useles, when developer starts CubeMX to develop product, he know about target MCU much more than presented in CubeMX selection window. All this functionallity can be safelly removed.

Now there is bad selection process

1 user enter s - app handle request and filled two list with all 4876 MCUs. Useles info, too long to scroll.

2 user enter t - the same

3 user enter m - the same

4 user enter 3 - the same

5 user enter 2 - the same

6 user enter H - 387 MCUs are found. too long to scroll.

7 user enter 5 - 131 MCUs are found. too long to scroll.

8 user enter 0 - 13 MCUs are found. At this step there is convenient list to select from

In good GUI search proccess must start from step 6. 3 symbols to enter. Now one have to enter 8.

V

vybor

Associate III

Problem of CubuMX is terrible product architecture.

It not use OSGi possibilities. It is old home made product. It is a mess of plain jars with old classpath headache.

Dynamic OSGi platform is exelent base for product like CubeMX. It has functional to add, update and remove separate bundles. No need to invent wheel and spend money and time.

Bad interface, when parameters are edited in tiny window, which must be scrolled, a big area is occupied by useless at the time pinout view. GUI must be redesigned to be more dynamic.

ST had several years to make CubeMX good and stable Eclipse RCP application which can be used as standalone app to be used with any IDE. And can be used in CubeIDE without problem.

ST used OSGi very badly, export and import directives in manifests do not use version ranges. It is amateur level.

V

vybor

Associate III

OSGi is exelent base if used right.

CubeMX does not use OSGi. It is not Eclipse RCP application.

CubeIDE is badly made Eclipse RCP application.

JetBrain use Java for C/C++ IDE and it is work fine.

Look at MANIFEST.mf files in CubeIDE. They are terribly bad.

Eclipse 4 does not impose any restrictions on the graphics library used.

OSGi is one of the best and usefull Java specification.

Andrew Neil

Super User

Note that STM32CubeIDE 2.1.0 has now been released

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

This is more adequately described as "The Cheese has moved!".

Stolen from this post by @Pavel A.

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.

J

JakeRezac

Visitor II

Split from old thread CubeIDE 2.0.0 and 2.1.0 weird behavior... Im frustrated - which is now solved.

As directed in that thread, this is now the place for discussions on the rationale behind the change.

Why is the Integrated Development Environment being split into multiple programs that are no longer integrated?

Andrew Neil

Super User

@JakeRezac wrote:
Why is the Integrated Development Environment being split ?

You're a bit late to that debate - it has now been split for 6 months!

Please review this thread for the reasons behind the change.

And note that we now (since March) have CubeMX2 ...

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.

Show more replies

Sign up

Click below to sign in

Login to the community

Click below to sign in