cancel
Showing results for 
Search instead for 
Did you mean: 

Bug report: STM32F1_Cube - clock frequency incorrect

pacman
Associate III
Posted on June 20, 2015 at 13:27

Version: STM32F1_Cube v1.0.0

Microcontroller: STM32F103c8 (64KB Flash, 20KB SRAM, 72MHz Cortex-M3)

I think there might be several issues here.

In the file ...

STM32Cube_FW_F1_V1.0.0/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/system_stm32f1xx.c

... the comment for SystemInit() promises the following:

''

Setup the microcontroller system. 

Initialize the Embedded Flash Interface, the PLL and update the SystemCoreClock variable.

''

-However, SystemCoreClockUpdate is not called and the SystemCoreClock variable is either set to 24000000 or 72000000 in advance.

On my bare-metal board, I have an 8 MHz external crystal, thus HSE_VALUE would be 8 MHz; HSI_VALUE would also be 8 MHz.

However, when I run a LED-blinker, SystemInit is called, but when looking at the values using the debugger, the microcontroller seems to run at HSI_VALUE (eg. all values appear to be set to the ''reset value'' mentioned in RM0008.

My timing-tests also suggests that the microcontroller is running at 8 MHz, not 24MHz nor 72MHz.

It seems that in the STM32F4_Cube, the clock frequency is usually set to the maximum by SetSysClock(), which is called from inside SystemInit().

Shouldn't the STM32F1_Cube behave in a similar way ?

#stm32cubemx #clock #bug #stm32f103x8-stm32f1_cube-bug
4 REPLIES 4
Amel NASRI
ST Employee
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-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

just4you
Associate II
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.

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

pacman
Associate III
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.

pacman
Associate III
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. 😉