STM32L4 only does debug session only every other time.

[Johannes]

I have a problem when debugging STM32L4 form CubeIDE with STLINKV2, the debugger only starts every other time. First start of debug session is ok, program halts at "main()". When debug session is closed and started again, the download is successful, but the CPU does not halt at "main()". If I press "pause", it is stuck in ROM code at 0x1fff523e. Seems to be bootloader code. I can see a bootloader device on my PC via USB.

Why does the CPU enter bootloader code here? The boot pin is fixed to LOW. I have checked with oscilloscope during start time. The Boot-Pin is not used for anything else and is not assigned to GPIO or something.

When stuck in bootloader code and the debug session is restarted once again, the program now runs fine and stops at "main()". Next try -> again stuck in bootloader code....

Does anyone experience the same?

Good behavior

 

bad behavior

 

STM32CubeIDE

Version: 1.6.1

Build: 9958_20210326_1446 (UTC)

STM32L4R7VIT6

STM32CubeL4 Firmware Package V1.17.0 / 11-February-2021

STLink V2J37S7

[TDK]

Custom board? Is BOOT0 tied low?

Does your firmware jump to the bootloader anywhere?

[Johannes]

Custom Board.

boot0 is tied low and checked with oscilloscope during reset

firmware does not jump to bootloader

 

T200 is not open during boot.

[HBaga.1]

I'm also having the same issue with my STM32L4 Discovery board. Most of the time, the first "debug session" halts to a specific address, and restarting debug again usually fixes it.

I have reported it here, which I think is the same issue as yours

https://community.st.com/s/question/0D53W00000raYd2SAE/intermittent-break-at-address-0x1fff51f4-with-no-debug

[Johannes]

My issue seems a little bit different:

I observe a third stage. The debugger manages to run to void(main) but then gets lost in "HAL_Init"

I am using free RTOS and have assigned Timer 7 to create the system tic.

"HAL_init" gets lost immediately in "HAL_initTick" , HAL_TIM_Base_Start_IT(&htim7) , HAL_TIM_ENABLE(htim) -> jumps into bootloader

So is there a problem with the vector table? Does the debugger setup the vector table wrong every other time?

[Johannes]

Next observation: In case of a "not running" debugger, the vector table does not point to 0. It points into bootloader code

see register "vtor"

in this example to 0x1FFF0000