CubeMX 4.24 LL Drivers generation bugs

[Michael N]

Posted on February 19, 2018 at 08:44

Hi ,

First of all,i want to thank ST for providing and developing such useful tools for developers.

Found couple of bugs in STM32CubeMX v 4.24 U(S)ART code generation when using LL Drivers 

During my work ,I wrote an custom bootloader and decided to use LL Drivers generation in CubeMx instead of using HAL Drivers.And found some bugs:

I worked on STM32f302xC MCU : 

1. When enabling U(S)ART other than USART1,for ex. UART4,UART5 , the CubeMX does not generates call to some functions like :

LL_USART_DisableOverrunDetect(UART4);

LL_USART_ConfigAsyncMode(UART4); // critical

LL_USART_Enable(

UART4

);//critical

but for USART1 it does.

2.When in CubeMX for some U(S)ART ,I set OverRunDetect to disable for some UART(ex. UART4 also on USART1),the CubeMX generates LL_USART_EnableOverrunDetect(

UART4

) function and vise versa .

3.In CubeMX,if I chose USART's clocksource as HSE with PLL(I thing is nevermind) ,in boudrate calculations the source is taken from HSI.

#cubemx-4.24 #ll-drivers

[Stefano Ugolini]

Posted on February 22, 2018 at 12:19

Hi, I would like to add something to the topic.

I also switched from using HAL USART1 to LL

USART1 

drivers. I did that changing project_>settings->advance.

After doing that, I noticed that my HSE_VALUE is defined to 25000000 because the file stm32f4xx_II_rcc.h is included.

This prevents the stm32f4xx_hal_conf.h to set the 

HSE_VALUE to 8000000. (Right value configured in cubemx.)

Result: All the functions that use HSE_VALUE return a wrong value affecting everything is based on that.

[henry.dick]

Posted on February 22, 2018 at 13:01

Put a ifndef HSE_VALUE .... Endif block on that hse def. It allows you to define have via the ide, or a common config file. Pretty much standard practice. St also utilized this in it's later versions of spl.

St should have known better.

[Stefano Ugolini]

Posted on February 22, 2018 at 14:09

St has already put the ifndef block around ♯ define HSE_VALUE.

Now Cubemx correctly generates 

♯ if !defined (HSE_VALUE)

♯ define HSE_VALUE ((uint32_t)8000000U) /*!< Value of the External oscillator in Hz */ ♯ endif /* HSE_VALUE */

in the file stm32f4xx_hal_conf.h

BUT because this is already define in stm32f4xx_ll_rcc.h, it has no effect.

I was just pointing out that if you use a LL library with CubeMx 4.24 the external clock value you set in cubemx is ignored.

[Mohamed Mansouri]

Posted on April 16, 2018 at 12:10

Hello Michael,

Thanks for your feedback and for your willingness to improve CubeMX.

The issue will be fixed next CubeMX release.

Please do not hesitate to contact me for further details.

Best regards,

Mohamed

[Harvey White]

This is correct. I did the same with USART3, changing it to LL. While the HSE_VALUE section in stm32F7xx_ll_rcc.h is grayed out, showing that it has already been defined, this indication is incorrect. The value in the HAL init is correct and set to 8000000 by the clock generator in CubeMX, however.

1) The value in the LL init is apparently not set from the clock generator (could this be because the clock generator is not set to LL?).

2) The LL init runs before the HAL init.

3) since the LL init defines HSE_VALUE, the HAL value is ignored.

Proof of this is to change HSE_VALUE in stm32F7xx_ll_rcc.h, recompile, and the system now runs at normal speed.

Cube version 4.27.0

Nucleo 144, F767ZI processor

A workaround is to use LL drivers for the RCC, however, I have no idea if the LL driver init is complete, and what the difference is when compared with the HAL driver.