Early Access to the STM32Cube HAL Drivers Major Update

[Emil Damkjaer PETERSEN]

Get early access to the next-generation STM32Cube HAL drivers for STM32U5

A major update to STM32Cube HAL drivers, called HAL2, is now available for preview on GitHub. It supports the STM32U5 series.

Building on over 10 years of experience, HAL2 delivers the following:

• More optimized drivers with a smaller footprint and improved performance
• Enhanced portability across STM32 devices to reduce development time
• A more intuitive API for easier and faster application development

To support this update, examples have been revamped for better reusability and understanding, and a new online documentation portal is introduced for enhanced content and easier navigation.

Try it now:

• Explore the preview on GitHub: STM32CubeU5-V2-Preview.
• Test the new features and share your feedback via GitHub Issues. Your input is essential for the final release.

Join the conversation and share your thoughts in the comments.

[Tom_pm]

Interesting, in a quick glance over the repository I definitely see a couple of shortcomings addressed in the API.

I will try to have a closer look when time permits.

Has ST already defined an very rough schedule for the release and which MCU Series will be supported by the new HAL? Most probably the new HAL will be released much later for older Series if at all?

[Loic CHOSSAT]

Thanks for your interest in STM32Cube evolution. This new major update of HAL will become available starting from next year. It will indeed be released first for all new STM32 series ST will introduce on the market. Some of the latest introduced STM32 series might progressively be supported as well. Looking forward reading your first feedback.

[Davide Dalfra]

---

@Tom_pm wrote:

Interesting, in a quick glance over the repository I definitely see a couple of shortcomings addressed in the API.

I will try to have a closer look when time permits.

Has ST already defined an very rough schedule for the release and which MCU Series will be supported by the new HAL? Most probably the new HAL will be released much later for older Series if at all?

---

I'm interested in the same. A roadmap of which families of STM32 will be supported would be fantastic.

D.

[Pavel A.]

These improvements are very welcome. Especially

* Revision of initialization and configuration

* Improvement of clock configuration and reduce code size

* "Remove Init structure from handle and convert Init structure into configuration one"

* "Remove MspInit and MspDeInit callbacks"

* Changes in the HAL files structure - stm32_hal.h instead of stm32tnxx_hal.h , removal of Ex files

* Factoring "environment" defs out of ...hal_conf.h to stm32_external_env.h

* Replacing the "locks" to OSAL layer with RTOS friendly locks

* Revision of HAL drivers state machines.

* Revision of HAL interrupt handling, esp. "prioritize handling critical interrupts first"

However, some naming looks confusing:

* "Atomic configuration methods" - the word atomic in this context is confusing because it has very specific meaning in C (as in "atomic update state"). Consider  "more granular", "split" etc.

* Same for clocks: here

* Factoring out the LL core.c/h files: the word "core" in this context is confusing. Consider "private", "internal" etc.

* Change values of HAL_Status: IMHO this change is not justified. Following crypto-paranoic "convention" in  general-purpose driver libraries makes no good. 

Not clear why stm32xxx_hal_conf.h should be included in hal_def.h rather than directly from stm32_hal.h to make it more visible? But this is a minor point.

[BJABR]

@Pavel A. 

Thank you for your valuable comments and feedbacks, it will help as improving the HAL2 and fixing some issues.

here bellow some feedbacks about your comments:

- * "Atomic configuration methods" + Same for clocks: here 

Yes what we want here is to bring more granularity for the configuration, it is not about atomic access. we will update the term , "more granular" sounds good.

- Factoring out the LL core.c/h files: the word "core" in this context is confusing: by core we mean a common set of functions to handle the peripherals that allows to have 2 or more HAL drivers on top of it (like usb core + HAL PCD/HCD or sdmmc core + HAl SD/MMC/SDIO)

we think the term core makes sense here in term of architecture. but we will double check with ST architecture team and if required we will update it.

-  Change values of HAL_Status: these are preliminary values to make it better than HAL1 values. we are indeed checking with our security architects to have better values. to help us improving these values could you please provide us with a proposal for these values.

-  stm32xxx_hal_conf.h is included by the hal_def.h only.  There a indeed some issues in the doc : here

we will fix this page: note that this is transparent for the user, all what the application needs is to have the stm32xxx_hal_conf.h at it's side, knowing that the stm32xxx_hal_conf.h is provided as a ready to use template.

[BJABR]

@Pavel A. 

regarding the point :

-  stm32xxx_hal_conf.h is included by the hal_def.h only.  There a indeed some issues in the doc : here

we will fix this page: note that this is transparent for the user, all what the application needs is to have the stm32xxx_hal_conf.h at it's side, knowing that the stm32xxx_hal_conf.h is provided as a ready to use template

"

Finally, after double-checking, the document is correct according to the references provided  here (see also below).

I now understand that your point is not about an issue in the document (my mistake, sorry), but rather a proposal to make the hal_conf.h  more visible.

As you mentioned, this is a minor point: the stm32xxx_hal_conf.h file is provided as a ready-to-use template in the package (in . All our examples use this file, and there is no change compared to HAL1 regarding this specific aspect.

From an architectural perspective, we include the stm32xxx_hal_conf.h in the lowest-level header file of the HAL inclusion model, which is stm32tnxx_hal_def.h. This approach ensures that the stm32xxx_hal_conf.h is easily accessible in the inclusion path of all peripherals HAL PPP drivers. And so make all the HAL configuration items defined in stm32xxx_hal_conf.h visible to all the peripherals HAL PPP drivers 

[Pavel A.]

My query was, would it better to include stmxxx_hal_conf.h early in stm32_hal.h so users inspecting the code will see it easier, with less include nesting? Of course if there's no other reasons to keep it that way.

> to help us improving these values could you please provide us with a proposal for these values.

Just 0,1,2, 3 4 ))  IMHO changing existing HAL_status values in the "hard crypto" style is not justified. If the intent is to force the enum size to int32, this can be done without changing the existing values.

Thanks!

P.

[BJABR]

@Pavel A. Actually the point is not about forcing U32 for the enum but rather to maximize hamming distance between values.

We have a security requirement (for CRYPTO peripherals: AES, PKA, RNG ...)  that aims to "have a hamming distance of al least 8 for return values of sensitive functions"

as there are unique type for HAL functions status return (hal_status_t), we applied the security requirement here.

 is there a particular issue you see here ? or it is just you it useless to go with these complex values for you ?   

[Pavel A.]

Ah for the CRYPTO peripherals. Well, then no objections. Though, the crypto library has its own status values where this Hamming thing is appropriate. Well, OK.