2021-07-12 08:35 AM
Hi,
we have a strange behaviour which could be resolved by changing clock configuration, but we cannot explain why the errors occured in the first place. Perhaps some of you have any idea why the following happened:
The "error" was in the SetSysClock function which was as following:
static void SetSysClock(void)
{
/* SYSCLK, HCLK, PCLK configuration ----------------------------------------*/
/* Enable Prefetch Buffer and set Flash Latency */
FLASH->ACR = FLASH_ACR_PRFTBE | FLASH_ACR_LATENCY;
/* HCLK = SYSCLK / 1 */
RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;
/* PCLK = HCLK / 1 */
RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE_DIV1;
/* PLL configuration */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSI_Div2 | RCC_CFGR_PLLXTPRE_PREDIV1 | RCC_CFGR_PLLMULL2);
/* Enable PLL */
RCC->CR |= RCC_CR_PLLON;
/* Wait till PLL is ready */
while((RCC->CR & RCC_CR_PLLRDY) == 0)
{
}
/* Select PLL as system clock source */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
RCC->CFGR |= (uint32_t)RCC_CFGR_SW_PLL;
/* Wait till PLL is used as system clock source */
while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS) != (uint32_t)RCC_CFGR_SWS_PLL)
{
}
}
and basically does two things wrong:
Still even with this configuration the core should run normal. If we remove the FLASH_ACR_LATENCY and PLL configuration, everything works fine and the error is gone.
Anyone with any ideas?
Regards,
Patrick
Solved! Go to Solution.
2021-07-13 03:36 PM
I am not an ST insider.
Many parameters in microcontrollers are specified with a seemingly great reserve - you might've heard of STM32s being "successfully" overclocked up to 150% or even 200% of their specified maximum core clock, etc. This reserve allows for parameters variations with temperature/voltage/manufacturing process variations. It's the latter what has hit you.
JW
2021-07-13 06:45 AM
RM0008 3.3.3 lists some restrictions on prefetch and such. Read carefully, maybe yo violate some requirement.
Sorry, can not delete. Wrong device in my mind.
2021-07-13 09:35 AM
You did not tell us, which STM32F0xx.
A quick look at the PLL characteristics chapter in DS to STM32F091 shows, that minimum PLL output is 16MHz. In other words, PLL under 16MHz in the 'F091 is unstable.
JW
2021-07-13 01:49 PM
HI,
sorry the Controller is an F030F4 which seems to have the same limitations in the DS.
Interesting and probably the cause! But are there any more detailed insights what "unstable" could mean. It still doesn't sound like coincidence that for years nothing happened and then a small batch starts acting out.
Cheers and thanks for the answer!!
2021-07-13 03:36 PM
I am not an ST insider.
Many parameters in microcontrollers are specified with a seemingly great reserve - you might've heard of STM32s being "successfully" overclocked up to 150% or even 200% of their specified maximum core clock, etc. This reserve allows for parameters variations with temperature/voltage/manufacturing process variations. It's the latter what has hit you.
JW