CubeMX generates incorrect system clock init code?

[Pavel A.]

Posted on February 23, 2018 at 01:56

Still very fresh with CubeMX and all this STM32 stuff, hope it is my fault. Or not?

In the Clock configuration tab in Cube 4.23 I've produced configuration that should set the HCLK and SYSCLK to 72 MHz

(not sure how it calculated this config, I have external osc. 8 MHz and must have 48 MHz for USB). The chip is STM32F446. See the picture below.

But, in the generated code in main.c after SystemClock_Config()  SystemCoreClock value is 225,000,000.

If I understand correctly SystemCoreClock should be exactly the HCLK (or Sysclk?)

I know that the actual frequency is 72 MHz because I use debug output via ITM_SendChar, and entered 72Mhz in Keil debug settings. It prints   

Today I upgraded this project to Cube v. 4.24 and libraries 1.19.0 and the  

SystemCoreClock value still is 225,000,000.

This may be related to

https://community.st.com/0D50X00009Xkav1SAB

.

Please advice...

Regards,

-- pa

#cubemx-4.23 #stm32f446 #cubemx-v4.24

[waclawek.jan · Accepted solution]

Posted on February 23, 2018 at 07:10

Incorrect HSE_VALUE?

I don't Cube.

JW

[Pavel A.]

Posted on February 24, 2018 at 03:23

> 

Incorrect HSE_VALUE? 

The HSE comes from Master Clock Output of another STM32F446 where it is set to repeat it's 8 MHz HSE.

So I defined it as 8 MHz in  BYPASS mode.

There are too many multipliers and various buses to keep in mind, for me is the main reason to use the Cube. The GUI factor. C code puts my h/w engineer in high-impedance state. Only when he sees the GUI, he is contactable.

-- pa

[waclawek.jan]

Posted on February 24, 2018 at 09:27

I mean, incorrectly defined symbol HSE_VALUE

---

Please don't confuse Cube (the 'library') with CubeMX. CubeMX (the GUI) can still be used for clicking, without using the 'library' or generated code. We do exactly this with my colleague who does the HW.

I prefer to print out the clock tree from the RM or the pin list from DS (or

http://www.efton.sk/STM32/STM32F4xx%20misc.pdf

) and use colored pens and highlighters.

JW

[Tesla DeLorean]

Posted on February 24, 2018 at 16:52

The setting for HSE_VALUE is typically in stm32f7xx_hal_conf.h (or whatever family you use) and is a project localized file.

There have been a number of situations where ST writes the wrong value as many of the EVAL boards use 25 MHz, where as most of the DISCO/NUCLEO boards use 8 MHz. This rule however is not universal as the STM32F769I-DISCO for example has a 25 MHz HSE.

Bottom line if the USART timings look off it is most likely that the HSE_VALUE doesn't match the hardware on the board (yours or ST's), as this is use to back-compute the CPU speed vs the PLL/RCC settings.

[Pavel A.]

Posted on February 25, 2018 at 14:01

Found the culprit... you won't believe it.

Yes I've defined 

HSE_VALUE = 8000000 in my stm32f4xx_hal_conf.h, and this used to work for a while.

But some time ago, added LL drivers for UARTs. This pulled in a bunch of LL includes from the Cube repository.

HSE_VALUE is defined there as well, in 

stm32f4xx_ll_rcc.h !

And this is because i

n the main.h and main.c generated by Cube, &sharpincludes for all the LL drivers go first, before inclusion of stm32f4xx_hal.h. So 

stm32f4xx_ll_rcc.h from the library gets included before my local 

stm32f4xx_hal_conf.h and overrides my HSE_VALUE. 

So the resolution...  HSE_VALUE must be defined at the topmost project level (in IDE compiler defines, makefile, etc). 

For extra security, added ASSERT(HSE_VALUE == 800000);  early in main(). 

It's interesting that neither UARTs or USB were affected by wrong HSE_VALUE.

Thank you Jan and Clive!

-- pa

[JObr]

I had another issue when my HSE_VALUE was overridden by defaut value, see https://github.com/platformio/platform-ststm32/issues/290. It's in PlatformIO.