cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F4 clock configuration tool generates code that causes USART baud rates to be 2x too fast

stockel
Associate II

I am using the STM clock configuration tool STM32F4xx_ClockConfiguration_V1.10.xls to generate the system_stm32f4xx.c file for a project using a STM32F407 processor with a 16MHz HSE. I am also using the Keil MDK-ARM V5.23, and the STM32F4xx_DSP_StdPeriph_Lib_V1.0.0 library. This combination produces code where the USART baud rates, and the SysTick clock are 2x too fast.

We recently changed the HSE from an 8 MHz clock to a 16MHz clock. With the 8MHz clock, the clock configuration tool produced a system_stm32f4xx.c for our code where all the peripheral clocks were correct. Now, with a 16MHz HSE, and the settings in the clock configuration tool set for a 16MHz HSE, the tool generates a system_stm32f4xx.c file for our code where some of the peripherals appear to be running twice as fast as expected.

Any suggestions? Is there a more recent clock configuration tool I should be using?

Thanks very much for any help you can provide.

2 REPLIES 2

>>Is there a more recent clock configuration tool I should be using?

Math here isn't hard

BRR = APBCLK / Baud for OVER16 operation

Check HSE_VALUE define is reflective of your external clock, ditto PLL settings, mostly PLLM where your comparison frequency should be between 1 and 2 MHz for F2/F4 parts, as I recall.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
stockel
Associate II

Tesla DeLorean,

Thanks, you nailed it. The HSE_VALUE was incorrect. I assumed the clock configuration utility tool that I used, "STM32F4xx_ClockConfiguration_V1.10.xls", which creates the "system_stm32f4xx.c" file, would correctly define this, but it does not. Bad assumption on my part.

Regards, Jim