Skip to main content
George.P
Associate III
January 18, 2018
Question

STM32CubeMX LL Driver Bug - HSE calculations

  • January 18, 2018
  • 6 replies
  • 3358 views
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
This topic has been closed for replies.

6 replies

George.P
George.PAuthor
Associate III
January 25, 2018
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.

Technical Moderator
January 25, 2018
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

"When your question is answered, please close this topic by clicking ""Accept as Solution"".ThanksImen"
stm32cube-t
ST Employee
January 30, 2018
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
George.PAuthor
Associate III
January 30, 2018
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
ST Employee
April 3, 2018
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
George.PAuthor
Associate III
April 4, 2018
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
Jim Kapcio
Visitor II
May 10, 2018
Posted on May 10, 2018 at 23:47

I haven't verified on a board but isn't the real problem the order of the includes in main.c?

swap the order the includes:

#include 'stm32l0xx_hal.h'

#include 'main.h'

This compiles and should give the right answer since 

stm32l0xx_hal.h includes 

stm32f3xx_hal_conf.h which will now be included before stm32f1xx_ll_rcc.h.

This would be a fix to the STM32CubeMX code generator.

Maxim Yudin
Visitor II
May 11, 2018
Posted on May 11, 2018 at 11:09

As I have mentioned above that won't help much because HSE frequency definition in this case will only take effect for main.c file compilation. Since there are still lots of LL's .c files and each one of these requires its own compilation process with its own separate defines (obviously not including any half_conf.h at all), every such .c file will get only default HSE_VALUE of 8000000 that is defined inside LL's headers making library functions see only this value.