MCU initialization fail while using HSE?

[Abhishek Kumar]

Posted on November 02, 2017 at 18:18

I am using NUCLEO-F767ZI board where I observe that when I use the internal clock (HSI), the mcu runs fine, but when I configure the cubeMX project to run on external 8MHz clock (HSE), the mcu fails to run. Following is the code generated by CubeMX when HSE is selected:

/** System Clock Configuration

*/void SystemClock_Config(void){

RCC_OscInitTypeDef RCC_OscInitStruct;

RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;

/**Configure the main internal regulator output voltage

*/ __HAL_RCC_PWR_CLK_ENABLE();

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

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

*/ RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLM = 4; RCC_OscInitStruct.PLL.PLLN = 96; RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; RCC_OscInitStruct.PLL.PLLQ = 11; if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); }

/**Activate the Over-Drive mode

*/ if (HAL_PWREx_EnableOverDrive() != 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_DIV2;

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

{ _Error_Handler(__FILE__, __LINE__); }

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART1|RCC_PERIPHCLK_USART2

|RCC_PERIPHCLK_USART3|RCC_PERIPHCLK_USART6 |RCC_PERIPHCLK_UART4|RCC_PERIPHCLK_UART5 |RCC_PERIPHCLK_UART7|RCC_PERIPHCLK_UART8 |RCC_PERIPHCLK_CLK48; PeriphClkInitStruct.PLLSAI.PLLSAIN = 96; PeriphClkInitStruct.PLLSAI.PLLSAIR = 2; PeriphClkInitStruct.PLLSAI.PLLSAIQ = 2; PeriphClkInitStruct.PLLSAI.PLLSAIP = RCC_PLLSAIP_DIV4; PeriphClkInitStruct.PLLSAIDivQ = 1; PeriphClkInitStruct.PLLSAIDivR = RCC_PLLSAIDIVR_2; PeriphClkInitStruct.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2; PeriphClkInitStruct.Usart2ClockSelection = RCC_USART2CLKSOURCE_PCLK1; PeriphClkInitStruct.Usart3ClockSelection = RCC_USART3CLKSOURCE_PCLK1; PeriphClkInitStruct.Uart4ClockSelection = RCC_UART4CLKSOURCE_PCLK1; PeriphClkInitStruct.Uart5ClockSelection = RCC_UART5CLKSOURCE_PCLK1; PeriphClkInitStruct.Usart6ClockSelection = RCC_USART6CLKSOURCE_PCLK2; PeriphClkInitStruct.Uart7ClockSelection = RCC_UART7CLKSOURCE_PCLK1; PeriphClkInitStruct.Uart8ClockSelection = RCC_UART8CLKSOURCE_PCLK1; PeriphClkInitStruct.Clk48ClockSelection = RCC_CLK48SOURCE_PLLSAIP; if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK) { _Error_Handler(__FILE__, __LINE__); }

/**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, 15, 0);}

Am I missing something or this is a bug? I have tried using both v4.20 and v4.23 of CubeMX tool and facing the same issue. Any resolutions?

#cubemx-project #stm32f7

[Tesla DeLorean]

Posted on November 02, 2017 at 19:42

Does it find its way into the Error_Handler or Hard Fault Handler?

You should double check the input pin, perhaps output via PA8 (MCO) for inspection.

Check HSE_VALUE

What do you learn by using a debugger? Is it stuck somewhere? Where?

In functions I'd probably want to initialize local/auto variables, ie

RCC_OscInitTypeDef RCC_OscInitStruct = { 0 };

[Abhishek Kumar]

Posted on November 02, 2017 at 19:44

Using debugger, I see the mcu halts when 

__HAL_RCC_PWR_CLK_ENABLE(); is called. I checked the OSC_IN pin on the mcu which correctly shows 8MHz.

[Tesla DeLorean]

Posted on November 02, 2017 at 19:52

That's clearly nonsensical as the part is running from HSI at that point.

Put a ♯ if 0 .. ♯ endif around chunks of the code, isolate what's working. Stop the processor and see where it is stuck.

[John Craven]

Posted on November 03, 2017 at 04:21

I have been working with this board for a month with cube. No issues.

I just did a new cube (4.1) project with same HCLK (96mhz) as you show. It works fine.

You didn't show the pins page, but i assume it looks like this;

Here is clock code that i get;

/** System Clock Configuration */ void SystemClock_Config(void) {   RCC_OscInitTypeDef RCC_OscInitStruct;  RCC_ClkInitTypeDef RCC_ClkInitStruct;   /**Configure the main internal regulator output voltage   */  __HAL_RCC_PWR_CLK_ENABLE();   __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);   /**Initializes the CPU, AHB and APB busses clocks   */  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;  RCC_OscInitStruct.HSEState = RCC_HSE_ON;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;  RCC_OscInitStruct.PLL.PLLM = 4;  RCC_OscInitStruct.PLL.PLLN = 96;  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;  RCC_OscInitStruct.PLL.PLLQ = 2;  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)  {  _Error_Handler(__FILE__, __LINE__);  }   /**Activate the Over-Drive mode   */  if (HAL_PWREx_EnableOverDrive() != 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_DIV2;   if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)  {  _Error_Handler(__FILE__, __LINE__);  }   /**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); } �?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

There is no HSE crystal on this board.

Assuming you haven't changed any of the default solder bridges,the HSE signal comes from the MCO of the STLink (8mhz).

Cube project and generated files are attached.

________________ Attachments : N144-767.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyKz&d=%2Fa%2F0X0000000b6B%2FA4n0OsXSNfILcbFwD8cD6meQyZ50Wwsmyn4w3.QYSeg&asPdf=false

[John Craven]

Posted on November 03, 2017 at 12:32

My project is absolute min changes to get project running.

Set RCC pin outs as shown.

In clock setup, set hse input freq to 8mhz, choose hse radio buttons, entered hclk of 96mhz, hit enter to let cube solve the rest.

one dif is the line;

RCC_OscInitStruct.PLL.PLLQ = 2;�?�?�?

[Abhishek Kumar · Accepted solution]

Posted on November 03, 2017 at 12:44

I got this problem solved, I know that the 8MHz clock frequency is coming from the debugger chip. So, I just changed the following:

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;

and it worked like a charm!

Thanks everyone, I know this was stupid but now it works

[Tesla DeLorean]

Posted on November 03, 2017 at 14:28

I've found some parts need BYPASS, and some don't.

There are a couple of parts where without BYPASS it acts like it is running at 4 MHz with an 8 MHz input

There seem to be issues with L0 using an 32 MHz source in BYPASS, but it works from an 8 MHz source.

[Abhishek Kumar]

Posted on November 03, 2017 at 15:32

In my case, the mcu was not even starting when I selected external crystal source!

[Tesla DeLorean]

Posted on November 03, 2017 at 15:56

In the L0 case the HSE_READY didn't assert.

I should dig out some F7 NUCLEO's and check. ST's use and documentation is inconsistent at best.