STM32H523CET6 Debugging stops when calling HAL_InitTick()

[Sander_UP]

Hello!

I have a problem when trying to debug in VSCode using Cortex Debug extension. The flashing process is working, but I cannot go further than HAL_Init. The exact problem is with the HAL_InitTick function, to be more precise, after the HAL_NVIC_EnableIRQ function is called and when trying to enable the interrupt, the debugging process just stops and I get this in the debug console:

warning: Exception condition detected on fd 656
Remote communication error.  Target disconnected: No error.
GDB session ended. exit-code: 0
GDB never responded to an interrupt request. Trying to end session anyways

 I tried the solutions from this thread, but those did not work. I also tried to change the HAL_InitTick function as it is for STM32WB55, but that also did not solve the issue. Note that both of the codes were generated by CubeMX for CMake projects. For the STM32H5, I am using STM32CubeH5's latest version - 1.5.0. Using ST-Link V2 for debugging and flashing.

I did configure the SYS Timebase Source from CubeMX to use the TIM15 timer as CubeMX issued a warning about using the SysTick, when enabling X-Cube FreeRTOS.

It seems that the problem comes from the initialization of the interrupt, but I am not 100% sure. Also worth noting is that we are using a custom made board that uses the STM32H523CET6 chip. Also to note is that TrustZone is disabled, if that makes any difference. Attaching Option Bytes if it even helps a bit.

Any help discovering the problem would be most welcomed!

[TDK]

Does execution keep going after debugging stops? Blink an LED in a main loop.

Can you show your schematic? Could be a power issue.

Do you erase flash, go into low power modes, or reassign SWD pins?

Can you connect with STM32CubeProgrammer after debugging stops?

[Sander_UP]

Hello, @TDK .

1. The code execution does not keep going. We do not have an LED to test it, but what we did was toggle a pin. We checked with oscilloscope, but the pin stayed low and nothing happened (GPIO pin PA12 should have gone high).

2. Unfortunately I am not able to share the schematic.

3. I am not going into low power mode or reassigning SWD pins. What I am doing is using STM32CubeProgrammer from STM32CubeCLT_1.18.0 to flash the firmware, and every time the CubeProgrammer erases sectors [10 15] and uploads the new firmware.

4. Yes, I can connect with STM32CubeProgrammer (not the one from STM32CubeCLT_1.18.0).

[Sander_UP]

I tried many things to solve this, but there is one thing that somewhat helped.

In CubeMX I went to Pinout & Configuration -> SYS -> Timebase Source -> Changed form TIM15 to SysTick. The problem now is that CubeMX gives a warning about this when X-CUBE FreeRTOS is enabled. And yeah, this fixed the debugging problem (i can get past HAL_Init function now), but FreeRTOS is not working.

Also, to note, is that the file stm32h5xx_hal_timebase_tim.c was deleted, where the called function HAL_InitTick (not the one in the stm32h5xx_hal.c, which has the weak attribution) was residing. So, maybe there was a problem in the code in that file and in that function HAL_InitTick.

So, as of now, I can debug again, but am not able to use X-CUBE FreeRTOS. Although I cannot say for certain, that if I did not have the previous problem occurring, that FreeRTOS would have worked. But at this point I am out of ideas as to what might be wrong with either FreeRTOS or timers or timer initialization form the HAL_InitTick (in the stm32h5xx_hal_timebase_tim.c file).