Debugger Stuck at HAL_GetTick() Function

[Giridhara_Datta_G]

Hello STM32 community,

I'm encountering an issue with my STM32L562VET controller where the debugger gets stuck at the `HAL_GetTick()` function. When debugging, the program seems to halt at this point, making it difficult to proceed with the debugging process effectively.

Additionally, I've noticed that when using EXTI1_IRQn or EXTI8_IRQn interrupts, the debugger fails to display the location of the current line being executed. This lack of visibility into the code execution flow hampers my debugging efforts even further.

It's worth mentioning that I'm using TZEN = 0 configuration. I've tried troubleshooting this problem by checking my interrupt configurations and ensuring that all necessary initialization steps are correctly implemented. However, I haven't been able to resolve the issue.

Has anyone else in the community encountered similar problems with debugging on STM32L562VET controllers with TZEN = 0 configuration? If so, I would greatly appreciate any insights, suggestions, or solutions you might have to offer.

Thank you in advance for your assistance.

Best regards,
Giridhara Datta G

[Giridhara_Datta_G]

'HAL_Delay()' is used inside the function 'ADS131A0xInit()'

[TDK]

HAL_GetTick is not blocking, doesn't make sense that it would get stuck there.

Perhaps it's getting stuck within HAL_Delay? In which case you would want to ensure interrupts are enabled and that the systick interrupt is higher priority than wherever you're using HAL_Delay.

Look at the call stack when it's stuck to gain more insight into what code is causing the issue. Likely it's not HAL_GetTick, but a couple functions up from that.

[TDK · Accepted solution]

You should also ensure that the vector table is getting set correctly in system_stm32l5xx.c. Ensure the line that defines USER_VECT_TAB_ADDRESS is uncommented.

[Giridhara_Datta_G]

Hey @TDK  ,

Thanks a ton for the helpful solution! Uncommenting the definition of  USER_VECT_TAB_ADDRESS helped. I'm new to this. I truly appreciate you taking the time to respond.

[PhillyG_SNL]

Hello TDK,

This also worked for my similar issue.

Would you be able to explain why this needs to be done?

[TDK]

> Would you be able to explain why this needs to be done?

The offset of the vector table needs to be set correctly. On some chips, it defaults to address 0x00000000 which may or may not be correct for your application. "Correctly" here can vary by application, but typically one wants it set to the start of the flash, which is 0x08000000. Uncommenting that line causes it to be set explicitly. Otherwise, the vector table offset (SCB->VTOR) is not modified at startup.

This behavior was a change to CubeMX initialization done a few years ago. Seemed like a bad choice at the time, but here we are. One could find those discussions with enough searching effort but I don't believe a reason/explanation was ever given from ST. Could be misremembering.

[PhillyG_SNL]

Ah, I see. Thank you for your explanation.

For anyone stumbling upon this thread, I am using an STM32G484RET6 and coding/building in STM32CubeIDE 1.17.0.

The issue that brought me to this post was that during debugging, my code would sometimes (not always) continue to run after the initial "resume" when it would hit the "int main(void)" function. It was not until I had the uCU mounted on a custom PCB that it would simply never continue past the initial "resume". As such I stepped through the code rather than hitting "resume," which led me to the same HAL_GetTick() function. This is when I fell down a rabbit hole, as I thought it was an issue with the VREF, since I was using an internal VREF for DAC applications.

It was not until I came across this post that I learned to leverage the call stack, which led me to the same solution as Giridhara_Datta_G.

My final question would be: when should I NOT set the flash start point explicitly by uncommenting the definition?