Infinite loop in HAL_RCC_OscConfig - STM32G4 ?

[newbie_stm32]

Hi Community,

I am working on a project with a custom board that uses both HSE (24MHz) and LSE (32.768KHz) clock sources. TIM6 is used as a time base source because SysTick is used by the RTOS. When running a debug session I can see that it is going into an infinite loop at the following code in the HAL library.

 

/* Wait till LSE is ready */
while (READ_BIT(RCC->BDCR, RCC_BDCR_LSERDY) == 0U)
{
 if((HAL_GetTick() - tickstart) > RCC_LSE_TIMEOUT_VALUE)
 {
 return HAL_TIMEOUT;
 }
}

 

After a closer look, it is found that HAL_GetTick is returning 0 every time because of which it went into an infinite loop but it should not be zero at this point because it is initialized in the HAL_Init with HAL_InitTick which in turn runs TIM6 ISR and should start updating the tick.

 

Why is that so?

PS: The configuration and code generation is done using STM32CubeIDE. This code ran effectively on a Nucleo Board. But not running on a custom board.

[AScha.3]

> This code ran effectively on a Nucleo Board. But not running on a custom board.

So : on your custom board : no running clock...or wrong.

Did you check with a scope , clks running ok ?

+

show circuit of your board...maybe something wrong.

+

and a pic...if possible.

[Tesla DeLorean]

Need to make sure NVIC has TIM6 Interrupt enabled, that there's an TIM6_IRQHandler in the vector table, it calls into the HAL, and your callback increments the tick count.

Make sure it's not task switching.

There's not good reason it would work on a NUCLEO vs CUSTOM

If the MCU uses a VCAP pin, make sure that has a capacitor and is at 1.25V

Have your Error_Handler() and HardFault_Handler() output actionable data if it ends there.

It shouldn't hard to pin down why the TIM6 isn't enabled or interrupting.

[waclawek.jan]

The infinite loop is not because the tick counter does not count, but primarily because your LSE does not start. And that's probably a HW design problem.

JW

PS My guess is that at that point TIM6 is simply not yet set up, I may be wrong, but I don't care, I don't use Cube.

[Tesla DeLorean]

TIM6 clocking and interrupting, and LSE starting, or not, should be relatively easy to determine.

HAL_Init() would be where SysTick would be fired up. Usually does that before the other MX horsery

The MCU and NUCLEO board weren't called out, I tentatively edited the title with the STM32G4 based on post history.

[newbie_stm32]

@Tesla DeLorean Yes I am using STM32G4 it does not come with a VCAP pin.

[Pavel A.]

Hmm this can be tricky, if the clock source of TIM6 depends on LSE or PLL. It will cause circular dependency, or a deadlock, whatever you prefer. During initial setup of clocks the systick is more robust. The RTOS issue can be resolved by some hacking of the generated code. 

As Jan wrote, the LSE fails to start, this is the root cause. Since this is a custom board, all bets are off.

NOTE: HAL_Init() calls setup of the HAL timer, no matter is it systick or TIM. So that after HAL_Init() HAL_GetTick() must work... unless when it does not.

[newbie_stm32]

@AScha.3 @Tesla DeLorean @Pavel A. @waclawek.jan Thanks for your inputs. I am checking with the hardware team to look into the external crystal to make sure it is functional.

I will update it here once it is fixed.

[waclawek.jan]

You perhaps could've started with checking/setting the LSE drive higher.

JW

[newbie_stm32]

Hi @waclawek.jan, I tried setting the LSE drive higher but had no luck. I can't see a waveform on LSE.

[AScha.3]

Hi,

set the LSE drive to high drive , check then in program.

Be aware if check with a scope: with 10:1 (10Mohm) probe it might be possible, to see the 32kHz oscillation, but you might stop it, just because connecting the probe !

And the crystal + surrounding area has to be clean, no solder/flux remains there; clean with aceton or isopropanol, if not sure about "clean" .

+ check Vbat : > 3.0 V ?