STM32CubeMX LL Driver Bug - HSE calculations

[George.P]

Posted on January 18, 2018 at 09:18

Hello,

I've encountered a bug in code generation when using the LL STM32F3 drivers 1.9.0 in Cube 4.23.0.

The device is the

STM32F303CCTx

, although it's probably not device specific.

Using the clock configurator and setting an HSE of 16MHz, the code generated in 

stm32f3xx_ll_rcc.h

indicates a wrong value for HSE:

&sharpif !defined (HSE_VALUE)

&sharpdefine HSE_VALUE 8000000U /*!< Value of the HSE oscillator in Hz */&sharpendif /* HSE_VALUE */

This can cause all sorts of problems if one uses the API to get various peripheral clock speeds, like  

LL_RCC_GetUSARTClockFreq

which gave me the wrong value, causing me to set up the wrong baud.

The

.ioc

 file seems correct since the relevant field is correct:

RCC.HSE_VALUE=16000000

#ll-drivers #stm32f3 #cube-mx

[George.P]

Posted on January 25, 2018 at 09:46

No reply from any rep?

I'm offering debug information for your software, so any response should be expected to say the least.

[Imen.D]

Posted on January 25, 2018 at 16:39

Hello

Pikoulis.George

,

Thanks for highlightingthis issue. I raised it to the appropriate team. We will keep you informed about the taken actions if needed.

Best Regards,

Imen

[stm32cube-t]

Posted on January 30, 2018 at 09:54

Hello George,

Attached the ioc file for F3, RCC, LL configuration,using CubeMX latest 4.24 that solves RCC/LL related issues.Here belowa snapshot of the generated code (found in the CubeMX generated stm32f3xx_hal_conf.h file):

#if !defined (HSE_VALUE)

#define HSE_VALUE ((uint32_t)16000000) /*!< Value of the External oscillator in Hz */ #endif /* HSE_VALUE */

Could you please confirm this solves your issue.

Thank you

________________ Attachments : F303_RCC_LL_project.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxyf&d=%2Fa%2F0X0000000b3m%2FKiUXY0vngpxIL8anqlDPMfwx8c.Dsa2TqkbezzvJpuo&asPdf=false

[George.P]

Posted on January 30, 2018 at 10:53

Hello,

Thanks for looking into this.

The driver for LL does not generate a

stm32f3xx_hal_conf.h

file. This file is generated in HAL or mixed HAL/LL.

On your file, you use mixed HAL/LL.

The relevant file in the LL driver is

stm32f3xx_ll_rcc.h

, which still has wrong code generated. I'm generating for IAR.

See attached

.ioc

for an example case.

Best regards,

George ________________ Attachments : 2PH_Inverter Test.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy5a&d=%2Fa%2F0X0000000b3r%2Fdwc292dN2913NR9E5l8KzsffMf0zHnF.30bwmBwtsHU&asPdf=false

[stm32cube-t]

Posted on April 03, 2018 at 12:14

Hello George,

Using your ioc file and CubeMX 4.24, the

stm32f3xx_hal_conf.h

file is properly generated under the Include folder.

The

stm32f3xx_ll_rcc.h

 driver file is not generated by CubeMX but only copied from the STM32CubeF3 embedded software package.

Best regards.

[George.P]

Posted on April 04, 2018 at 11:17

Hello

,

Thanks for looking further into this.

Please also use the attached

main.c

, I've just added a variable to read the

HSE_VALUE

.

/* Private variables ---------------------------------------------------------*/

volatile uint32_t test; /* USER CODE BEGIN PV */ /* Private variables ---------------------------------------------------------*/

.

.

.

int main(void)

{

/* USER CODE BEGIN 1 */

test=HSE_VALUE;

/* USER CODE END 1 */

It seems that due the multiple definitions, inclusion order and

#if !defined (HSE_VALUE)

macro,

HSE_VALUE

evaluates to the value set by

stm32f3xx_ll_rcc.h

in the end.

Best regards,

________________ Attachments : main.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxqV&d=%2Fa%2F0X0000000b1J%2F..Bg0K4ia.uyc2F25BtSlVi8bW8n.PYy95xZ.N4DI9g&asPdf=false

[Maxim Yudin]

Posted on May 05, 2018 at 10:09

Hello,

I confirm the same problem that still exists though it was found months ago, it's bad...

I've spent an hour trying to figure out why my just out of the Cube generated USART code based on LL sends wrong data. By debugging the problem's origin was in aforementioned

HSE_VALUE

. The necessary Cube defined value is put only into the

stm32f1xx_hal_conf.h

file while it even doesn't get included anywhere in the

main.h

since I don't generate HAL code at all preferring LL. After all system just gets the default

8000000U

value for

HSE_VALUE

and hence calculates the wrong timings.

Moreover it seems that all LL

.c

files that include

stm32f1xx_ll_rcc.h

still use the

HSE_VALUE

defined in

stm32f1xx_ll_rcc.h

as during every particular

.c

compilation they won't touch

stm32f1xx_hal_conf.h

in any way. That makes Cube's frequency modification of only

stm32f1xx_hal_conf.h

file meaningless even if it will be properly included for

main.c

file.

[Tesla DeLorean]

Posted on May 06, 2018 at 19:05

The model was to have the project/board specific stuff in the stm32fxxx_hal_conf.h, and this gets pulled via stm32fxxx.h when USE_HAL_DRIVER is defined.

You can also push HSE_VALUE in via the compiler command line if you prefer that approach.

[Pavel A.]

Posted on May 06, 2018 at 23:10

IMHO the proper solution for this is to define 

HSE_VALUE at the project level in C preprocessor defines. Not in any .h file.

In the library .h files there should be:

&sharpif !defined (HSE_VALUE)

&sharperror HSE_VALUE must be defined in the project settings

&sharpendif /* HSE_VALUE */

--pa