Hal_init() never returns when TIM is selected (nucleo H755)

[GCanc.1]

Hi Everyone!

I just received 10 STM32H755 nucleo boards to use in a project in the company I work for. However, I haven`t been able to use them.

I`m facing a problem with Hal_init(). When I select any timer as the Timebase Source Hal_init() never returns. However, when I select Systick, Hal_init() return just fine.

One more thing: I`m using the internal RC oscillator as the clock source.

Thanks a lot

Guilherme

[Tesla DeLorean]

Do you have an IRQHandler for the TIM you're using?

[GCanc.1]

Yes. It is automatically generated by the STM32Cube IDE. It also generates a callback that calls HAL_IncTick()

[TDK]

Where within Hal_init does it get stuck? The more info the better.

[GCanc.1]

Within the Hal_init(), it breaks at HAL_InitTick(TICK_INT_PRIORITY)

WIthin HAL_InitTick(TICK_INT_PRIORITY), it breaks at HAL_NVIC_EnableIRQ(TIM1_UP_IRQN)

[GCanc.1]

Do I need an external crystal to use any timer as timebase source?

[Tesla DeLorean]

No

[Tesla DeLorean]

Put a break-point in TIM1_UP_IRQHandler()

Make sure you don't have a weak handler or C++ file with the handler in it.

Check the Map and Listing files to assure that the linker has bound the right routine, and make sure all pending sources are cleared prior to trying to exit the handler, otherwise it will simply reenter.

[GCanc.1]

Hi guys. I found out that the problem is clock related. I changed a few clock parameters and things started to work. For some reason the CubeIDE didn`t complain about any clock values. I guess there must be a bug in some place.

I also realized that if I enable the PLL, the generated code fail to configure the clock.

I`m almost 100% sure that there must be a bug in Cube IDE

[Tesla DeLorean]

>>I'm almost 100% sure that there must be a bug in Cube IDE

It's an opportunity rich environment for them..

Is there some perceived advantage to using a TIM over SysTick for an interrupt driven timebase?