My code stuck at HAL_InitTick() at the beginning of the code

[KWang.9]

I am programming my custom board with STM32G491CEU6 and STM32CubeMX 6.5.0.

The code is generated with STM32Cube_FW_G4 v1.5.1 firmware.

Steps to reproduce:

1. Select 'access to MCU selector' after opening STM32CubeMX.
2. Select STM32G491CEU6 and create the project.
3. In System Core->SYS:
   1. Set Debug to Serial Wire
   2. Set Timebase Source to anything other than SysTick.
4. Generate the code. Build and flash.

I discovered the problem after pressing pause during debugging and it shows me that the code is stuck at HAL_NVIC_EnableIRQ() called by HAL_InitTick() which is called by HAL_Init().

Note that this problem only happens when the Timebase Source is modified. Another problem arises when Timebase Source is set to SysTick: HAL_Delay() stalls the code forever since HAL_GetTick() always return 0.

I think I must have missed something trivial in my setup. What am I missing?

I don't think the problem is related to my hardware since I designed my custom board following the reference design provided in the application note. I also refer to other open-source designs that are based on STM32G4 MCUs.

It's worth noting that my board doesn't have external oscillators. Is this related?

[KnarfB]

Don't have your chip, but it works for a Nucleo G431RB board with TIM6. Check that a file stm32g4xx_hal_timebase_tim.c was generated and the HAL_InitTick in it is called, and not the default (weak) implementation.

What does "stuck" exactly mean? A hard fault? The MCU may not complete a read/write to a peripheral if the clock was not switched on before.

hth

KnarfB

[KWang.9]

Thank you for your reply.

Yes, stm32g4xx_hal_timebase_tim.c is also generated in my project folder.

"stuck" means that the code seems to have stopped running. I'm coding and debugging in VScode and the following line is highlighted when the pause button is pressed during debugging.

In this case, Timebase Source is set to timer 2.

[KnarfB]

Set a breakpoint there, restart and step into the function. Finally, only NVIC ISER should be set. You can also use Disassembly > Switch to Assembly to see where exactly it stops.

hth

KnarfB

[bobert]

Hi,

I'm having the exact same issue with the G473VET. I was able to fix it by rewriting this function:

__STATIC_INLINE void __NVIC_EnableIRQ(IRQn_Type IRQn)
{
 if ((int32_t)(IRQn) >= 0)
 {
 __COMPILER_BARRIER();
 NVIC->ISER[(((uint32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)IRQn) & 0x1FUL));
 __COMPILER_BARRIER();
 }
}

Into this:

__STATIC_INLINE void __NVIC_EnableIRQ(IRQn_Type IRQn)
{
 uint32_t data;
 uint32_t index;
 if ((int32_t)(IRQn) >= 0)
 {
 __COMPILER_BARRIER();
 index = ((uint32_t)IRQn) >> 5UL;
 data = (uint32_t)(1UL << (((uint32_t)IRQn) & 0x1FUL));
 NVIC->ISER[index] = data;
 __COMPILER_BARRIER();
 }
}

Any insight into why this is happening?

EDIT: It turns out this didn't fix it... but when I step through the code it works every time, but letting it run it hard faults.

EDIT2: You need to uncomment this to get interrupts to work with a fresh CubeMX generation:

#define USER_VECT_TAB_ADDRESS

-Rob

[Tesla DeLorean]

What address is it building the file for?

Would have helped if ST had used linker symbols instead of defines.

[trad0v]

The problem for me was in stm32f10xx_hal_tim_base.c in HAL_InitTick function:

The CubeMX generated code starts the Timer at line 92, and then calls HAL_NVIC_SetPriority at line 101.
A solution would be to flip the order of the 2 function calls to have something like this:

Hope this helps!
Jad