cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F0xx Hardfault through PLL misconfiguration?

patrickschneider9
Associate III

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:

  • random hardfault during runtime after 2min to several hours
  • only on a few of thousands of devices, all from a limited production batch over half a year

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:

  • uses PLL with HSI to achieve 8MHz clock, where PLL is not needed and can be skipped totally (dividing HSI by 2 and then multiplying it with 2)
  • uses wait states while for 8MHz none are required

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

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

4 REPLIES 4
Uwe Bonnes
Principal III

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.

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

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!!

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