When debugging custom hardware using a STM32L431KC, the debugger gets stuck in the reset_handler.

[JNoon.1]

When debugging custom hardware with the STM32L431KC, the debugger gets stuck in the reset handler:

Reset_Handler:
  ldr   sp, =_estack    /* Set stack pointer */

And in the console it says:

Open On-Chip Debugger 0.12.0-rc1+dev-00061-g5e9b46d77 (2022-10-20-14:50) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V3J10M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.274617
Info : clock speed 8000 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x2ba01477
Info : [STM32L431KCUx.cpu] Cortex-M4 r0p1 processor detected
Info : [STM32L431KCUx.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32L431KCUx.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : [STM32L431KCUx.cpu] external reset detected
Info : accepting 'gdb' connection on tcp/3333
[STM32L431KCUx.cpu] halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x080020a4 msp: 0x20010000
Info : device idcode = 0x10016435 (STM32L43/L44xx - Rev Z : 0x1001)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
Info : accepting 'gdb' connection on tcp/3333
Warn : GDB connection 2 on target STM32L431KCUx.cpu not halted

Any help/reasons to why it does this?

It will suddenly work and then not work for hours....

Any help is appreciated.

Thanks

[waclawek.jan]

Wild guess: spurious bootloader entry?

JW

[JNoon.1 · Accepted solution]

Forgot to post an answer to this....

For some unknown reason when the live expressions tab is open the debugging session will not start but if I change it to the breakpoint view for example and try to debug again... it works! 

Weird solution but works for me!

[Garnett.Robert]

Hi,

Unhandled interrupt?

Regards

Rob