Showing results for 
Search instead for 
Did you mean: 

STM32F373CCT hangs when using HSI and PLL

Posted on March 21, 2018 at 10:40


I got generated code from STM32CubeMX for STM32F373CCT where it is configured the clock with HSI and PLL. When debugging my CPU hangs after I enable PLL.

Currently the only way to run firmware is using HSI without PLL.

Any suggestions/ideas why the PLL won't work when using HSI clock?

Generated code for clock setup:

void SystemClock_Config(void)


  RCC_OscInitTypeDef RCC_OscInitStruct;

  RCC_ClkInitTypeDef RCC_ClkInitStruct;

  RCC_PeriphCLKInitTypeDef PeriphClkInit;

    /**Initializes the CPU, AHB and APB busses clocks


  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;

  RCC_OscInitStruct.HSIState = RCC_HSI_ON;

  RCC_OscInitStruct.HSICalibrationValue = 16;

  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;



  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)


    _Error_Handler(__FILE__, __LINE__);


    /**Initializes the CPU, AHB and APB busses clocks





  RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;

  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;

  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)


    _Error_Handler(__FILE__, __LINE__);


  PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_USART1|RCC_PERIPHCLK_SDADC;

  PeriphClkInit.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2;

  PeriphClkInit.SdadcClockSelection = RCC_SDADCSYSCLK_DIV12;

  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)


    _Error_Handler(__FILE__, __LINE__);




    /**Configure the Systick interrupt time



    /**Configure the Systick



  /* SysTick_IRQn interrupt configuration */

  HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);


Attaching also my STM32CubeMX project.

#clock #stm32f373
Eric Deuel
Posted on April 10, 2018 at 15:28

I was experiencing the same problem with a STM32F072C8 custom board.  My issue was a missing component, in this case a ferrite bead, between my VDD and VDDA rails.  If you haven't gotten resolution, try looking at the relationship between those two rails as VDDA >= VDD is a documented requirement.

Andrew Neil
Evangelist III
Posted on April 10, 2018 at 19:17

When debugging

Is the behaviour different when not debugging?

my CPU hangs

What, exactly, do you mean by that?

Is it getting 'stuck' in the Hard Fault Handler - which is, by default, just an infinite loop ?

after I enable PLL.

Do you have everything else correctly configured; eg, Flash wait states ... ?

Posted on May 15, 2018 at 13:20

Hi Andrew,

I'm facing this issue right now and my answers to your specific questions are as follows:

1) The problem goes on when not debugging too

2) CPU is stuck in 'Hard Fault Handler' for ~90MHz but goes into 'Reset Handler' for 200MHz pll configuration

3) What should i do for flash wait states, is it required to do such configuration just for blinking a LED ?

Posted on May 15, 2018 at 13:34

And what chip are you using? Thinking it's not an F3 part...

it is not about blinking the LEDs, it is about how the processor can read FLASH memory, and how fast/responsive that is (or isn't in this case). Assume the FLASH operates at 24 MHz, if you run the processor faster you need to add wait states to accommodate the disparity in speeds.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on May 15, 2018 at 13:57

I'm working on STM32F746NG DISCO board. I don't want to use HAL library or CUBEMX, trying to configure manually. I misunderstood the meaning of wait state so thank you so much for the explanation. I will configure flash registers according to my CPU speed and VDD, and try again. 

Posted on May 15, 2018 at 14:13

Hi again Clive;

I configured the flash latency accordingly and its OK now.

Thanks so much again.