reason 7 - target needs reset — unreliable debugging setup

Question

I am having trouble getting a reliable debugging setup. I have seen other threads in some forums across the net with a similar title, but the circumstances seem different.

Setup:

Linux (Xubuntu) 64bit
Eclipse CDT, Neon 4.6.0
"GDB Hardware Debugging" plugin from eclipse "install new software", configured to reset & delay 3sec, halt; load symbols (all checkboxes, no custom commands)
arm-none-eabi-gcc 4.8.3 tool chain
OpenOCD, recently downloaded, running in an own console, configured for my exact MCU with script provided by them & the st-link
STM32L476RG MCU with hard float, which is used.
ST-Link V2 debugger (stand-alone)

Now, there is a sequence with which I am, after some struggle every time, able to connect with the debugger, but stepping and reading variables doesn't work so clearly reliable that I'd trust what I see for a second. But to even get to that point where the call stack would not be full of obvious nonsense entries and only very few of them, is tiring.

Example:

Flash the device with the firmware. This usually works without trouble.
Start openocd.
Start debugging in Eclipse.
OpenOcd shows connection, then says: "undefined debug reason 7 - target needs reset"
I regardless press the "resume" button in Eclipse to make the program run past the bogus top stack frame it shows.
Press "suspend" (still bogus in callstack), then "terminate".
Ctrl+C out of OpenOcd.
Manually (hardware) reset the stm32 MCU.
Restart OpenOcd.
Start debugging in Eclipse again.

OpenOCD output:

GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:31)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192646
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset

Now with some luck, I finally have a somewhat working debugger connection, for a while. But this may as well need some repetitions. Why the "press resume" in between when it's clear the connection is bad? Not sure, this seemed to increase the likelihood that in the next iteration I'll have the connection, a lot.

A maybe relevant note: The MCU has an LCD connected to it and from that I can see when it resets. For some reason, starting debugging in Eclipse will apparently not reset the device, although the reset checkbox is checked in the debug config. If I open a telnet connection to OpenOCD in a terminal, and do "reset" there, the device does reset.

What could be causes for the odd behavior of my setup?

Try including "reset halt" in your openocd .cfg or typing "monitor reset halt" in gdb. — Chris Stratton

L3w1s L3w1s · Accepted Answer · 2017-03-23T14:59:04

What OpenOCD client you're using? I made a mistake using the host gdb and I got this error. And after I modified my debugger path to the location of my arm-none-eabi-gdb in "Debug Configuration" of your eclipse the problem disappeared.

From your post you only mentioned you used arm-none-eabi-gcc toolchain, so don't know if you set your gdb to arm-none-eabi-gdb in "Debug Configurations", which is separate from project toolchain settings.

reason 7 - target needs reset — unreliable debugging setup

2 Answers