STM32F373CCT hangs when using HSI and PLL

[Jean Paul Talledo Vilela]

Posted on March 21, 2018 at 10:40

Hi

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;

  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;

  RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL8;

  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

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

    */

  RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

                              |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;

  RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

  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__);

  }

  HAL_PWREx_EnableSDADC(PWR_SDADC_ANALOG1);

  HAL_PWREx_EnableSDADC(PWR_SDADC_ANALOG3);

    /**Configure the Systick interrupt time

    */

  HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

    /**Configure the Systick

    */

  HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

  /* 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]

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 ... ?

[N ORhan]

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 ?

[Tesla DeLorean]

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.