Skip to main content
jvavra
Associate III
September 10, 2021
Question

Porting STM32L432 to STM32L496: HSE Never Goes Ready?

  • September 10, 2021
  • 8 replies
  • 1402 views

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)
 }
 }
 }

This topic has been closed for replies.

8 replies

TDK
September 10, 2021

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

"If you feel a post has answered your question, please click ""Accept as Solution""."
jvavra
jvavraAuthor
Associate III
September 10, 2021

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
September 10, 2021
HSE bypass requires a clock source, not a crystal. Disable bypass if you’re driving the crystal directly.
"If you feel a post has answered your question, please click ""Accept as Solution""."
Piranha
Principal III
September 25, 2021

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

jvavra
jvavraAuthor
Associate III
September 29, 2021

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.

Piranha
Principal III
September 29, 2021

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.

TDK
September 29, 2021

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

"If you feel a post has answered your question, please click ""Accept as Solution""."