Unbiased Review of the new and "improved"(?) STM32CubeMX2

[Niclas Hedhman]

 

@lbthomsen of STM32World has published a review of the new STM32CubeMX2, what is good (not so much), indifferent and BAD (a lot). He tries to get it working, browse through the features, and has a lot of opinion on this matter.  https://www.youtube.com/watch?v=61r83TTzDfk

End of the day, IF you plan to use future STM32 families (starting with STM32C5) you have no choice than to use CubeMX2 AND the very painful migration from HAL to HAL2 (not compatible, maybe some future tool can assist in such migration). Even if migration is possible, then you will have the pleasure to support multiple versions of YOUR code on old vs new MCU families. Have FUN.

For the people without perfect vision (like myself), embrace yourself for 4 pixels font sizes, and contrast-free dark-white-on-white-backgrounds text. Lovely! At least there is plenty of white space around the text that can sooth your soul.

Now is the best time for experienced STM32 shops to leave HAL, CubeMX and go Bare Metal ;)

[unsigned_char_array]

I don't understand how companies can still release software in 2026 that has unreadable fonts on high resolution monitors. Are their test engineers running the programs on VGA resolution monitors or something?

[lbthomsen]

No it' the opposite - force the developers to use relatively small low resolution monitors and they will make effective use of screen realestate.  Give them plenty of screen, plenty of storage and plenty of ram and they will use it.

 

//Lars...

[unsigned_char_array]

Obviously it needs to be tested on various screen resolutions, screen sizes and aspect ratios. And with various scaling settings (including fractional scaling).

[Ozone]

I had my reasons to stick with mostly the SPL as template, and bare metal / direct register access otherwise.

[Brenden_PLUS]

Haven't done a deep dive on this but it seems pretty wild that that they would break one of the best features of stm32 chip which is there HAL abstraction layer.  So i would be very interested to know for what reason they wanted or needed to do this?

 

Guide for migration

* https://www.st.com/en/development-tools/hal2-migrator.html

 

 

Don't care to much mostly because i switched to using zephyr RTOS.  Which stm32 chips have great support for.  

[Emil Damkjaer PETERSEN]

Hi,

 

Thank you for your feedback on the user experience. We intend to address these issues to improve your experience in future releases. The following changes are planned for upcoming releases:

 

• Make text easier to read, including on small screens.
  • We are aware of the issue with small font sizes and are working on a solution.

 

• Address contrast issues.
• Please provide specific information about the affected areas, including whether the issue occurs in dark mode.

 

• Resolve scaling issues.
• We are aware that the user interface can appear distorted on smaller resolutions. We plan to add features to make the user interface more responsive and scalable.

 

• Improve zoom and panning functionality.
• The zoom and panning functions can be unclear depending on the cursor location. We are working to make navigation easier.

 

•  Installation issues on Linux
• Ware have identified the problem, and will see what is possible in terms of a solution

 

If any issues are missing from this list, please inform us. We value your feedback.

For the migration from HAL1 to HAL2, we understand that it may have been perceived as a painful experience, and this is certainly not what we want for our users.

We would really appreciate your feedback on the areas that were challenging for you, so we can improve the migration support that we offer.

 

It is also worth noting that the HAL2 update is designed to require minimal investment for porting, both through the changes made to the APIs and through the supporting tools and guides. Furthermore, we have continuously worked with external companies, partners, and customers to ensure that the migration effort is acceptable and straightforward. For additional validation, consulting companies that were not involved in building the migration tools and guides were contracted and provided the following statement:

“STM32 HAL2 makes developing with the STM32C5 and other family members faster and more efficient. It is much lighter, closer to hardware functions, and porting our code to other STM32 MCUs is extremely easy.”

 

To help with the migration, we have created the STM32Cube HAL1 to HAL2 migration tool and guide:
https://www.st.com/en/development-tools/hal2-migrator.html

It consists of:

• A tool that can analyze your application code and identify the HAL1 API calls that need to be migrated, along with links to documentation explaining how to migrate each specific API call
• A migration user guide, examples, and a checklist designed to assist you throughout the migration process

 

For more insight into why we have introduced HAL2, I encourage you to have a look at the post https://community.st.com/t5/developer-news/stm32cube-ecosystem-for-stm32c5-series/bc-p/887410/highlight/true#M417.

 

Best Regards,

Emil

[Niclas Hedhman]

---

@Emil Damkjaer PETERSEN wrote:

• Address contrast issues.
• Please provide specific information about the affected areas, including whether the issue occurs in dark mode.

 

• Resolve scaling issues.
• We are aware that the user interface can appear distorted on smaller resolutions. We plan to add features to make the user interface more responsive and scalable.

 

• Improve zoom and panning functionality.
• The zoom and panning functions can be unclear depending on the cursor location. We are working to make navigation easier.

 

•  Installation issues on Linux
• Ware have identified the problem, and will see what is possible in terms of a solution

 

If any issues are missing from this list, please inform us. We value your feedback.

For the migration from HAL1 to HAL2, we understand that it may have been perceived as a painful experience, and this is certainly not what we want for our users.

We would really appreciate your feedback on the areas that were challenging for you, so we can improve the migration support that we offer.

 

---

Contrast; The web world is obsessed with low contrast web pages, fonts with tiny lines and similar "good looking" nonsense. Without regard to people (and we are a huge percentage) with non-perfect vision, where these "good looking" only means that we need to strain the eyes, zoom in much more than would be necessary and in general be quite annoyed by it.
The Pin Assignment is laughable, and no idea who somebody could approve to release that. The Clock tree at least has some numbers in black, but most other text is smaller and "softer" contrast and I need to zoom in a lot. In dark mode the white is "bluring"

Isn't ST large enough to have expertise on Section 508 (Accessibility Regulation)? When I was in charge of a small product (12 devs in the whole company), we still had someone who knew Section 508 in detail.

And I don't even consider myself "impaired". A regular guy, with glasses, a bit of astigmatism and somewhat poor night vision. But "dark-white-on-white-background" is horrible.

 

Panning; When panning the clock tree with the "Pan tool" it works somewhat ok. Panning with the middle-mouse-button and for me it moves to the right all by itself when the button is pressed.
Panning with the "Pan Tool"; For clock tree, no issues. In Pin Assignment, there is a massive delay between mouse and what happens on screen. Lag is in the order of half a second, maybe more.

Panning/Zooming in general; Go look at CAD packages, and learn. Be consistent, but it could be as simple as;
Scroll wheel -> Zoom
Alt + Scroll -> Pan right/left
Ctrl + Scroll -> Pan up/down
Right Button -> Pan freely

(taken from KiCAD)

Installation; as mentioned in the video, why does the installer need those dependencies? Again it seems to be "web mindset", and a "Oh, let's just do it in HTML".  Request; make a non-UI installer for Linux. An installer that only asks for a location and to view license(s) is meaningless for Linux users.

"Minimal investment" -> So ST offers to do that for $5000 for every customer, right?  I thought not. I am even considering a "HAL2AbstractionLayer" for people to keep using their old HAL-based code, and it will work with HAL2 MCUs. In FACT, why hasn't ST done this? Since it is "Minimal Investment", it should be a piece of cake.

 

[TDK]

Just as a comparison for readability. Here are two chips side by side on the same monitor. The STM32CubeMX text is large and legible. The STM32CubeMX2 text is TINY. Probably half-size. And this is true even though the left chip has more pins!

Also, as @Niclas Hedhman mentions, the bizarre white on slightly darker white color scheme is apparent. There appear to be 4 different shades of white to light gray in the image. The left one looks like a chip. The right one looks like the beginning stages of a UI project. In particular the "shadow" effect behind the chip makes it looks like a powerpoint slide more than a usable tool. I don't need lightning bolt symbols, I need readable text.

[TDK]

Another comparison:

In STM32CubeMX, it takes 2 mouse clicks to assign a pin as a GPIO output. Click the pin, click "GPIO_Output". Done. The clicks are even right next to each other. And you can see the pin is an output, as well as additional configurations when you hover over it. Easy.

In STM32CubeMX2, to assign a pin as an output:

• Click the pin.
• On the right side of the screen, click "GPIO"
• Click the Gear button next to GPIO to see options. This changes the view from Pinout to GPIO.
• In the middle of the screen, first find the pin you were working on, then click "Mode" and then select "Output".
• Click "Pinout" to return to the pinout view.

6 clicks!! And it shows you all pins so you have to remember which one you want to change. And even after all of that, there is no way to see at a glance on the pinout view that the GPIO is an output. How is a tooltip that explains that you can drag and drop signals more important than whether the pin is an input or an output?

Assigning pins as input and output has to be among the most common scenarios ever. Yet the new STM32CubeMX2 is comparatively awful at doing it and presenting that information.

[Niclas Hedhman]

Here I must defend CubeMX2, though.

Right click and you get this pop-up;

 

And can select GPIO with a second click. Edit Label is an extra "hover" (click not needed). I can live with that.

[TDK]

You can select "GPIO", yes, but you still need to configure it as output, hence the additional 4 clicks.

[MorkBeck]

Hi
Thank you for your feedback. We appreciate your input and have recorded the user experience concerns you raised. We are actively reviewing these points and will address them as resources allow. We recognize that some tasks currently require multiple steps, and we will prioritize improvements in this area as development progresses.

Please continue to share your suggestions. This is the initial release of the application, and we are committed to enhancing the user experience in future updates.

[v_dimitrov]

@MorkBeck 

Hello, 

I'd like to point out that in MX2 - the MCU choice filtering is very limited compared to the remarkable system used in MX1. Should you choose to remove the C5 and other MX2-supported MCUs from MX1 - the product choosing and comparison process would become hell. Please think about implementing the same system in MX2 as a redundancy. 

The new tool has great potential in my opinion, you could also add GPIO configuration in the detailed view, albeit not the full set of settings in order to address the above user concerns.

[MorkBeck]

@v_dimitrov 

Hello,

Instead of adding the finder functionality to STM32CubeMX2, we have determined that users typically know which microcontroller unit (MCU) they will use when they access the MCU selector screen. If you need assistance selecting the appropriate STM32 device for your product, you can use the updated MCU portfolio available here: 

https://www.st.com/content/st_com/en/stm32-mcu-developer-zone/mcu-portfolio.html 

[TDK]

> Instead of adding the finder functionality to STM32CubeMX2, we have determined that users typically know which microcontroller unit (MCU) they will use when they access the MCU selector screen.

If users knew which MCU they will use, they don't need an MCU selector at all. This is tenuous logic at best.

If you continue with the MX/MX2 split and segregating new MCUs to be MX2-nly, it will cause an inconsistent software system and a reluctance by users to switch to a new/unknown software with far fewer features. This will cause newer chips to be less readily adopted.

[MorkBeck]

Hello @v_dimitrov 

On the https://www.st.com/content/st_com/en/stm32-mcu-developer-zone/mcu-portfolio.html page, you can add a column with the price. The price column is not displayed by default.

 

You can also select a single CAN filter.

The online tool should fulfill all your needs. If it does not, let me know. I will report any issues to the team responsible for the page.

[Sara BEN HADJ YAHYA]

Hi, and thank you for your feedback,

As a complement to @Emil Damkjaer PETERSEN's reply, I’d like to confirm that we have internal trackers open for the topics you raised: improving text contrast and font weight across all views for better readability, and improving panning and zooming behavior.

Internal ticket numbers: CDM0060898 and CDM0060899.

I will keep you posted on their progress and on any updates that make it into upcoming releases.

Thank you again for your valuable feedback.

Sara