STM32Cube Ecosystem for STM32C5 series

[Maxime_MARCHETTO1]

With the introduction of the STM32C5 series, we’re rolling out a next‑gen STM32Cube foundation designed to boost your productivity and unlock even more performance from STM32 MCUs.

You keep the STM32Cube ecosystem you know – same concepts, same user flow – but under the hood we’re rebuilding key layers to scale with upcoming STM32 series and developer expectations.

• Core focus areas:
• STM32 HAL2 (new optimized hardware abstraction layer)
• STM32CubeMX2 (revamped init & code generation)
• STM32CubeIDE for VS Code (new free IDE option)
  

All new STM32 series starting with STM32C5 will benefit from this upgraded foundation.
All existing STM32 series remain fully supported by current STM32Cube components, which will continue to be maintained over time.

Why a new foundation for STM32Cube?

The first STM32Cube architecture dates back to 2014 and has continuously evolved to follow the growth of the STM32 portfolio. We’ve now hit a point where architectural upgrades bring more value than incremental patches.

This new core architecture is built to:

• Implement long‑requested developer enhancements and fixes
• Enable more advanced features and roll them out consistently across devices
• Shorten release cycles and improve reactivity to your feedback
• Support an even faster STM32 roadmap with a stronger, more scalable foundation
  
  

What’s New in the STM32Cube Ecosystem?

STM32 HAL2 – Optimized Hardware Abstraction

We’re introducing an optimized hardware abstraction layer, called STM32 HAL2:

• Same concepts and programming model as the current HAL
• Reduced footprint and enhanced quality to get more from your STM32 MCU
• Built on top of STM32 LL to enable faster and finer code optimization, when you need it

For details, see the embedded software developer news: STM32Cube embedded software for STM32C5 series

STM32CubeMX2 – Faster Init, Smarter Code Generation

STM32CubeMX2 is a new evolution of the STM32CubeMX initialization and code generation tool:

• Same pinout, clock, peripheral, and middleware configuration flows
• Improved UI/UX to speed up everyday operations
• New code preview features to:
• Quickly inspect generated code
• Access reference code snippets you can copy directly into your projects

More information in the STM32CubeMX2 dev news: Introducing STM32CubeMX2, a new flavor of STM32CubeMX tool

STM32CubeIDE for VS Code – STM32 in Your Favorite Editor

STM32CubeIDE for VS Code adds a new, free IDE option for STM32 development:

• Built on the Visual Studio Code framework
• Adds STM32‑specific build and debug tooling on top of VS Code
• Lets you tap into the VS Code extension ecosystem, including AI code assistance plugins

Discover more in the STM32CubeIDE for VS Code dev news: STM32CubeIDE for Visual Studio Code

Documentation, Examples & Developer Workflow

The upgraded STM32Cube ecosystem also improves how you find, learn, and reuse STM32 content:

• New STM32 example library web tool
  Quickly search and access production‑ready reference code for STM32.
• STM32 Sidekick – AI‑powered STM32 assistant
  Helps you:
• Locate relevant technical content faster
• Surface documentation you might otherwise miss
  
  
• New web‑based documentation
• Easier navigation across technical references
• Smoother getting‑started experience with the STM32Cube ecosystem

Ready to get started?

Low-cost, easy-to-use development kits are available to start prototyping:

• STM32C5 Nucleo-144 development board (NUCLEO-C5A3ZG) offers a rejuvenated style and layout, designed to quickly evaluate and start development with the STM32C5A3ZGT6 microcontroller in an LQFP144 package.
• NUCLEO-C542RC and NUCLEO-562RE (Nucleo-64) provide Arduino® UNO R3 and ST morpho headers, plus an onboard STLINK debugger for easy prototyping and programming.
  
  

STM32C5 enables entry-level graphics capabilities with a Nucleo-compatible display kit from Riverdi or a 1.5-inch Knob Display from TSD featuring STM32C5. These displays are fully supported in the TouchGFX framework, and demos are available.

A serial memory pack (B-M2MEM-PACK1) with five different non‑volatile serial memory add‑on boards is also available.

Additional resources

• Get started with STM32C5 MCU
• Video: STM32C5, what is key?
• Video: Introduction to the STM32Cube ecosystem
• Video: [Getting started] STM32 evaluation kits
• Explore more on the STM32 Developers Zone

First published on Mar 16, 2026

[Niclas Hedhman]

I am very curious whether the decision for HAL2 has been "documented"? Did ST interview big STM32Cube shops and asked

Do you think it is a good idea that the Hardware Abstraction Layer is replaced, so if you want to use new MCU families, you will have to spend endless hours migrating your code base and then maintain two different versions?

And was the answer really "Yes, what a great idea!" 

Or was it just a decision based off "This might improve our lives later."

[Emil Damkjaer PETERSEN]

Hello @Niclas Hedhman 

We understand that introducing changes may be perceived as a source of concern. However, this is an incremental upgrade, not a disruption. We have worked to make the migration as easy as possible, both by design and through dedicated porting guides. Furthermore, tests with our STM32 alpha customers and with external design houses have shown that adoption of the HAL2 upgrade can be smooth and straightforward, with real benefits — for example, some projects can now rely on HAL instead of LL thanks to the reduction in code size.

 

To give some context on why we decided to do this:
the HAL drivers have been supporting our STM32 products for more than 10 years. Over this period, our MCUs have gained many more capabilities and features, which naturally leads to greater overall complexity — just compare an STM32F4 to an STM32C5 or the soon to come STM32V8.

This evolution has created several challenges for the original HAL, including:

• Growing code size, as the original architecture is no longer optimal for the MCUs being developed today
• APIs that are no longer ideal for handling the increasing complexity of new features and the wider range of use cases now possible

Because of this, we decided to update to version 2.0.0. This allows us to introduce several improvements, but it unfortunately comes with some breaking changes to the API.

It is important to note, however, that:

• The breaking changes have been kept to a minimum
• The overall programming model remains the same
• You still have Polling / IT / DMA-based processing and callback mechanisms for asynchronous operations

To better understand the breaking changes and the rationale behind them, I strongly encourage you to read the “Breaking changes in concepts” section of the migration guide:

https://dev.st.com/stm32cube-docs/hal1-to-hal2-migration/1.0.0/en/docs/markup/drivers_documentation…

This should help clarify what has changed and why.

Best Regards,
Emil

[Niclas Hedhman]

@Emil Damkjaer PETERSEN You didn't reply to my question and just gave a "corporate blurb". IF the CubeMX2 and HAL2 (as a team) supported most of the existing MCUs, then perhaps some software houses would agree to the change. But I BET that it wasn't explained that they need to maintain two different version, depending on which family one uses.

The whole point of committing to a HAL is that it doesn't change all in one go.

And how about those who start a proof-of-concept with STM32C5 and after a few weeks/months hit some barrier and realize that perhaps they need H7. Tough luck. Start over!

We have two tiny public libraries that other people use, stm32-w2812 and stm32-w25qxx, and we are not thrilled at migrating and dual maintenance/support. In this case, we could have two different libraries, and maintain our APIs.

I am not arguing over whether HAL or HAL2 is "better" nor "better for whom?". I am arguing that ST is killing its main advantage over competitors, and making life harder for "those testing the waters" and "those who went all-in with HAL"

AND all the educational material available is now obsolete. 1000s of hours of content made by independents are important resources to get going with STM32. And every new video on a topic will need to be made in two versions, or confusingly describe both inside the same video. Sigh!

[Emil Damkjaer PETERSEN]

Hello @Niclas Hedhman,

My previous reply was simply intended to provide some context behind our decision to update the HAL. We understand that navigating both versions of STM32CubeMX and HAL may not be perceived as the optimal experience. However, I would like to highlight that these updates are an incremental upgrade rather than a complete overhaul; the two versions share the same programming model, and early users who have worked with HAL2 have reported that porting is relatively easy.

After 10-plus years of stability with HAL1, it is time to bring new enhancements to our HAL drivers with HAL2, which we are equally committed to keeping stable for many years to come. With the update to HAL2, we also took the opportunity to redesign STM32CubeMX. One of our goals was to improve how our drivers and the tool work together—specifically in setting up configurations and managing code generation—making STM32CubeMX2 agnostic from MCU-specific information.

The decision to keep older series on HAL1 was also a matter of prioritization, especially since multiple existing series (such as the H5 and U3) have recently been extended. We haven't closed the door on bringing HAL2 and STM32CubeMX2 to already-available STM32 series, but we must balance that against supporting upcoming products. Furthermore, we remain fully committed to supporting HAL1 and the original STM32CubeMX, as we know that as of today, a vast majority of our customers rely on them for their existing projects.

You rightly pointed out the challenge of maintaining product offerings that span STM32s based on both HAL1 and HAL2. To assist with integrating the STM32C5—and future STM32s—into your portfolio, we've introduced a migration tool and guide specifically for users updating their products to HAL2 based STM32s. For developers working across both ecosystems, our goal has been to maintain the same underlying fundamentals so that switching between HAL1 and HAL2 feels as intuitive as possible. 

Now that HAL2 is available, we are actively looking for feedback. We would genuinely appreciate hearing about the specific issues you are facing so we can identify areas for improvement. It is also worth mentioning that a large portion of the breaking changes between HAL1 and HAL2 reside in the configuration phase—such as the split between initialization and configuration, or the RCC setup rework. STM32CubeMX2 is designed to help automate and manage these changes for you. 

We know the ecosystem transition can be improved, and we would be happy to get your direct feedback to help us get there. 

 

Best regards, Emil Damkjaer PETERSEN 

[Niclas Hedhman]

@Emil Damkjaer PETERSEN wrote;

> Now that HAL2 is available, we are actively looking for feedback. 

 

We are waiting for STM32C551 to be delivered to our manufacturer in China, and we WILL have Streamline MCU board with it, probably in 2-3 weeks time. And of course, Youtube video about it on the STM32World channel.

We will connect back here when that is done.

[Emil Damkjaer PETERSEN]

Good to hear looking forward to hear your feedback @Niclas Hedhman.
You are of course also welcome to sent me a message if you have any question or topics that would be more suitable through that channel.

[Oleksii]

 

Hello Niclas Hedhman,

I am one of those developers who avoids using HAL altogether due to its overhead and complexity. Personally, I prefer working with CMSIS—I find it much more straightforward and efficient for my needs.

However, for those working on large-scale projects, it might be worth considering Zephyr RTOS. Over the last 9 years, its codebase has been significantly refined and polished. One of its biggest advantages is how it handles portability: switching between different chips is mostly a matter of updating the Device Tree (similar to how Linux works), so the core functionality remains intact.
Interestingly, support for the STM32C5 series is already present in the project, which could be a solid alternative to dealing with the HAL/HAL2 migration headache.

I am interested in the STM32C593 chip, but unfortunately, it is not available yet.)
It has 2 FDCAN and Ethernet, but as always, there is a downside: it features USB FS instead of HS. (

[hansd]

Hi, Could somebody please explain why CAN on the NUCLEO-C5A3ZG is not populated?