STM32F7 - HSI configuration

[Omar Suárez]

Posted on March 21, 2017 at 13:12

Hi,

I am trying to configure a project in a STM32F769I-DISC1 board using TIM6, DAC1, the FMC connected to the external SDRAM and the DMA (to pass data between SDRAM and DAC).

I have generated the configuration using STM32CubeMX, everything compiles OK but when running the code the firmware is throwing me an error from the HSI configuration function.

The error comes from this line:

/* Check if HSI is used as system clock or as PLL source when PLL is selected as system clock */

    if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_HSI)        || ((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_PLLCLK) && ((RCC->PLLCFGR & RCC_PLLCFGR_PLLSRC) == RCC_PLLCFGR_PLLSRC_HSI)))    {      /* When HSI is used as system clock it will not disabled */      if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET) && (RCC_OscInitStruct->HSIState != RCC_HSI_ON))      {        return HAL_ERROR;      }      /* Otherwise, just the calibration is allowed */      else      {        /* Adjusts the Internal High Speed oscillator (HSI) calibration value.*/        __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);      }    }

It returns the HAL_ERROR here.

In STM32CubeMX I configured the RCC to work with the HSE from the board (25 MHz) so I don't understand why is the firmware having an issue with the HSI.

I  have attached also the RCC configuration in STM32CubeMX.

Any clue to fix this?

Thanks in advanced,

Omar

#stm32f7 #stm32cubemx

[Tesla DeLorean]

Posted on March 21, 2017 at 13:47

I'd have to assume it relates to code earlier, and it making a determination that HSE didn't start. Start doing your debugging before this stepping through to be sure of the path to this point.

The 25 MHz clock source is from an oscillator, not a crystal, you'd probably need to make sure that the HSE is in BYPASS mode.

[Omar Suárez]

Posted on March 21, 2017 at 15:18

I have changed the HSE mode from Crystal/Ceramic resonator to BYPASS mode but now the error seems to come from the HSI function:

if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_HSI) == RCC_OSCILLATORTYPE_HSI)  {    /* Check the parameters */    assert_param(IS_RCC_HSI(RCC_OscInitStruct->HSIState));    assert_param(IS_RCC_CALIBRATION_VALUE(RCC_OscInitStruct->HSICalibrationValue));        /* Check if HSI is used as system clock or as PLL source when PLL is selected as system clock */     if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_HSI)        || ((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_SYSCLKSOURCE_STATUS_PLLCLK) && ((RCC->PLLCFGR & RCC_PLLCFGR_PLLSRC) == RCC_PLLCFGR_PLLSRC_HSI)))    {      /* When HSI is used as system clock it will not disabled */      if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET) && (RCC_OscInitStruct->HSIState != RCC_HSI_ON))      {        return HAL_ERROR;      }      /* Otherwise, just the calibration is allowed */      else      {        /* Adjusts the Internal High Speed oscillator (HSI) calibration value.*/        __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);      }[.......]

Seems to come from the 'if' statement where HSI si checked as not disable.

I was executing the code step by step three or four times, but everything works until this line now.

Does it make sense to you?

Thanks,

Omar

[Tesla DeLorean]

Posted on March 21, 2017 at 15:26

Not really. You'd want to inspect the RCC registers in the debugger, and perhaps scope the HSE clock source.

The part should start running from the 16 MHz HSI, if you don't reconfigure the clocks it will continue to do so. If the HSI was non-functional the part would not start and you would not be able to debug.

[Omar Suárez]

Posted on March 21, 2017 at 17:10

Finally I could fix the problem!!

It seems like a bug in the code generated by STM32CubeMX to initialize the Osc and the CLK in the SystemClock_Config function.

The line configuring the HSIstate is missing there!

This is the generated code:

 /**Initializes the CPU, AHB and APB busses clocks     */  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;  RCC_OscInitStruct.PLL.PLLM = 25;  RCC_OscInitStruct.PLL.PLLN = 400;  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;  RCC_OscInitStruct.PLL.PLLQ = 4;

This is the one with the added line for the HSI:

 /**Initializes the CPU, AHB and APB busses clocks     */  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;  RCC_OscInitStruct.HSIState = RCC_HSI_ON;  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;  RCC_OscInitStruct.PLL.PLLM = 25;  RCC_OscInitStruct.PLL.PLLN = 400;  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;  RCC_OscInitStruct.PLL.PLLQ = 4;

Now I can see the MCU and the DAC working.

Thanks for helping!

Omar

[Omar Suárez]

Posted on March 22, 2017 at 09:42

Making a review of the code from another example using FMC to control the SDRAM I found that the code initializing the clock is a bit different comapred to the one I posted:

  /**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 = 25;  RCC_OscInitStruct.PLL.PLLN = 400;  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;  RCC_OscInitStruct.PLL.PLLQ = 4;

It seems to work on the board so I am a bit confused now... I gues that the wrong line from the code above is then:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;=

Another question is when to use the RCC_HSE_ON or the RCC_HSE_BYPASS?. I changed this option in the SDRAM example and the MCUs seemed to work well in both cases.

Thanks,

Omar

[Amel NASRI]

Posted on March 22, 2017 at 09:59

Hi

Su_rez.Omar

‌,

There is a confirmed bug with CubeMX 4.20 generated code (see

https://community.st.com/0D50X00009XkYY4SAN

).

This bug will be soon fixed.

To understand more the difference between the usage of

RCC_HSE_ON or the RCC_HSE_BYPASS:

• RCC_HSE_ON: means you use the crystal available on the board

• RCC_HSE_BYPASS: means you will be using an external source

• You find more details in the chapter RCC of

  http://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/96/8b/0d/ec/16/22/43/71/DM00224583/files/DM002245pdf/jcr:content/translations/en.DM002245pdf

  (see section5.2.1 HSE clock)

-Amel

[Omar Suárez]

Posted on March 22, 2017 at 12:29

Hi Amel N,

thanks for the advice about the bug!

I am using the 25MHz oscillator in the board, so I guess that the correct option is RCC_HSE_ON then.

The external source is external to the board then, not to the MCU, isn't it?

Thanks,

Omar

[Jeanne Joly]

Posted on April 28, 2017 at 09:28

Hello

Su_rez.Omar

and

Turvey.Clive.002

,

I would inform you that anew patch

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html

V 4.1is available to fix this issue.

Sorry for any inconvenience this may cause you.

BR. Eric