Porting STM32L432 to STM32L496: HSE Never Goes Ready?

[jvavra]

As above, have a project I'm porting from one custom board to another. Using the same external crystal (8Mhz) and virtually identical circuitry with the exception of a few custom ASICs. This code works fine on the L432, but when I run it on the L496 (debugging via STLink pod) I get a timeout while waiting for HSE to go ready.

/* Enable HSE BYPASS to PLL */
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    /* Initialization Error */
    ClockError();
  }

This is directly from the ST LIbrary file stm32l4xx_hal_rcc.c; I hit this timeout every time waiting on HSE. Brought the timeout value from 100mS default to 500mS, no change.

/* Set the new HSE configuration ---------------------------------------*/
      __HAL_RCC_HSE_CONFIG(RCC_OscInitStruct->HSEState);
 
      /* Check the HSE State */
      if(RCC_OscInitStruct->HSEState != RCC_HSE_OFF)
      {
        /* Get Start Tick*/
        tickstart = HAL_GetTick();
 
        /* Wait till HSE is ready */
        while(READ_BIT(RCC->CR, RCC_CR_HSERDY) == RESET)
        {
          if((HAL_GetTick() - tickstart) > HSE_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;    //Times out at 200mS (default was 100mS)
          }
        }
      }

[TDK]

Are these custom boards? Are you feeding in an HSE clock source?

[jvavra]

Sorry, I had given some more detail in an earlier edit of the post then realized I wasn't describing the issue correctly.

Yes, they are custom boards. This exact custom board previously worked with a STM32F205; I had it reworked with a STM32L496 (same package) and now am trying to port some (also previously working) FW from a very slightly different custom board that was running an STM32L432. I know that's a bit confusing; chip shortages have a lot of people scrambling.

I have an 8MHz crystal feeding HSE; I verified the crystal is oscillating.

[TDK]

HSE bypass requires a clock source, not a crystal. Disable bypass if you’re driving the crystal directly.

[jvavra]

Correct. I am switching to PLL as the HSE source.

  /* Enable HSE BYPASS to PLL */
  RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    /* Initialization Error */
    ClockError();
  }

The issue is that HSE never goes ready, so this times out:

        /* Wait till HSE is ready */
        while(READ_BIT(RCC->CR, RCC_CR_HSERDY) == RESET)
        {
          if((HAL_GetTick() - tickstart) > HSE_TIMEOUT_VALUE)
          {
            return HAL_TIMEOUT;
          }
        }

[Piranha]

You were told that HSE bypass mode is not for crystals, but you are still using it!

[jvavra]

No. Please re-read my post. I TEMPORARILY switch to the PLL feeding the HSE. It is during this TEMPORARY change that I use bypass mode. And, as I stated, HSE never goes ready.

[TDK]

> I TEMPORARILY switch to the PLL feeding the HSE. It is during this TEMPORARY change that I use bypass mode.

This makes no sense. HSE feeds the PLL, not the opposite.

> No. Please re-read my post.

For reference, here's what you said:

> I have an 8MHz crystal feeding HSE; I verified the crystal is oscillating.

So you have a crystal, but it's somehow temporarily not hooked up? And what's hooked up there instead? I've reread your post. It doesn't make a lot of sense. I suspect there is a fundamental misunderstanding.

[Piranha]

I did understood from the first time that you do not understand how HSE and PLL works. Now go and read the respective sections from the reference manual. 😉

HSE has two modes - the one for crystals and the other one (bypass) for external clock signals. And PLL has nothing to do with it.