Skip to main content
Phil1
Phil1
Associate II
September 6, 2018
Question

BUG: CubeMX 4.26.1 (Eclipse plugin): HSE_VALUE not set correctly

  • September 6, 2018
  • 3 replies
  • 1165 views

I have a project which is using an 11.0592MHz external TTL oscillator, PLL'd up to 66MHz HCLK.

CPU is an STM32F303RET6 on a Nucleo-64 F303 board.

IDE is Atollic TrueSTUDIO STM32 Edition.

I found the System Tick timer was ticking at ~700us. After single stepping through the init code, I found that HAL_RCC_ClockConfig() had incorrectly calculated the CPU core clock:

 /* Update the SystemCoreClock global variable */
 SystemCoreClock = HAL_RCC_GetSysClockFreq() >> AHBPrescTable[(RCC->CFGR & RCC_CFGR_HPRE)>> RCC_CFGR_HPRE_BITNUMBER];
 
 /* Configure the source of time base considering new system clocks settings*/
 HAL_InitTick (TICK_INT_PRIORITY);

At this point, SystemCoreClock was 48000000, which given a PLL of 6x suggests that the HAL is set up for an 8MHz HSE clock.

Indeed, HSE_VALUE is 8000000.

Defining HSE_VALUE=11059200 in the project options fixed this.

My question is -- given that STM32CubeMX knew my HSE clock was 11.0592MHz, why did it not include the required settings in the project configuration or one of the headers?

I'm sure it used to do this.

Thanks.

Phil

This topic has been closed for replies.

3 replies

Phil1
Phil1Author
Associate II
September 6, 2018

I've just noticed that the HSE clock is set correctly in stm32f3xx_hal_conf.h:

/**
 * @brief Adjust the value of External High Speed oscillator (HSE) used in your application.
 * This value is used by the RCC HAL module to compute the system frequency
 * (when HSE is used as system clock source, directly or through the PLL). 
 */
#if !defined (HSE_VALUE) 
 #define HSE_VALUE ((uint32_t)11059200) /*!< Value of the External oscillator in Hz */
#endif /* HSE_VALUE */

I'm not quite sure why the HAL isn't picking this up.

Without the HSE_VALUE #define on the compiler command line, the HAL assumes 8MHz.

Working backwards...

* stm32f3xx_hal_rcc.c includes "stm32f3xx_hal.h"

* "stm32f3xx_hal.h" then includes stm32f3xx_hal_conf.h -- but by this point HSE_VALUE has already been defined.

* Eclipse seems to think the compiler is using the definition in stm32f3xx_ll_rcc.h...

* Working backwards: stm32f3xx_hal_conf.h includes main.h first

* main.h includes stm32f3xx_ll_rcc.h as its second include line

Therefore, stm32f3xx_ll_rcc.h defines HSE_VALUE (after being included from main.h), overriding the correct value in stm32f3xx_hal_conf.h.

So stm32f3xx_ll_rcc.h needs to not define HSE_VALUE, or stm32f3xx_hal_conf.h needs to include main.h after it defines HSE_VALUE.

As a workaround, set HSE_VALUE as a compile-time define in the project configuration.

Can any ST engineers comment on whether it'd be possible to get a fix for this either in the HAL library or STM32CubeMX?

It's a pretty nasty bug if you're using a non-8MHz external clock.

Morty Morty
Morty Morty
Associate III
September 25, 2018

Don't get your hopes up that anyone at ST understands and then fixes this issue. ;). You should probably also tag this as bug.

One solution is to include the main.h at the end of stm32f3xx_hal.conf. The better solution is to not include it there at all, and include the main.h in the .c - files that actually need that header.

Pavel A.
Pavel A.
Super User
September 25, 2018

This is indeed the situation at least with STM32F4 as well. Certain combination of HAL and LL headers causes confusion.

Just make sure to specify HSE_VALUE in the project settings (preprocessor defines) same as in stm32...hal_conf.h, else prepare to surprises.

-- pa

Terms & ConditionsAccessibility statement