Bug report: STM32F1_Cube - clock frequency incorrect

Posted on June 24, 2015 at 13:04

Hi Pac-Man,

It may be an issue with the used HSE oscillator in your board rather than a firmware bug.

To confirm this, try to debug your code and check the flags in RCC_CR register.

-Mayla-

Posted on June 26, 2015 at 07:08

Because I did not generate the STM32F1 code,

I could not conclude your problem is the STM32CubeMX's clock generation bug.

However, I also suffered from the STM32CubeMX.

I don't know the the following method is applied to your code, but you could get a hint in my process.

---------------------------------------------------------------------------------------------------------

In order to decide the generated clock code is correct,

you should probe the SystemClock_Config() function in the main().

At the last of this function, the following code is shown.

HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

To watch the value in real-time, configure the break point to the return state.

uint32_t HAL_RCC_GetHCLKFreq(void)

{

  SystemCoreClock = HAL_RCC_GetSysClockFreq() >> APBAHBPrescTable[(RCC->CFGR & RCC_CFGR_HPRE)>> POSITION_VAL(RCC_CFGR_HPRE)];

â—�

  return SystemCoreClock;

}

If the value of in the watch is correct, then it's not problem.

Maybe this value is configured you don't intend.

The next process is comparing with the example of Standard Peripheral library.

Maybe no SetSysClock() function is in the system_stm32f1xx.c.

If then, you should copy the definition of PLL configuration and this SetSysClock() function.

After copy the SetSysClock() function and related code like PLL configuration,

you would find the intended clock configured value in the watch window.

---------------------------------------------------------------------------------------------------------

Posted on July 06, 2015 at 21:37

When the comment promises that the SystemCoreClock variable is updated, and it is not updated, I consider that a bug in the firmware; especially because it's updated in the similar file for STM32F4 Cube.

I would expect that the engineer is allowed to choose any crystal he / she wishes. I see no note in the datasheet about which external oscillator speed to use for this device. However, it states that a 4-to-16 MHz crystal oscillator can be used, thus I strongly believe there's a bug in the SystemInit subroutine, when it assumes that the external crystal is always 16 MHz.

I've been able to fix the problem in my own sources (before I posted this); I'm manually setting the speed from main(), so I get 72 MHz - and I find no problems running at 72MHz from an external 8 MHz crystal.

Posted on July 06, 2015 at 21:42

Thank you for the hints. =)

The reason I reported this issue, is that many other users will come across the problem, so it's better getting it fixed at the source, rather than having more than 1000 people try to get it right. ;)