Shutdown openocd when stopping debug session?

[jhillyerd]

I'm not sure if I'm doing something wrong; when I stop the cortex-debug 0.3.7+openocd session, gdb is shutdown, but openocd is left running. Starting a new debug session fails until I manually kill the already running openocd.exe process. I'm using scoop on Windows to install openocd & gcc/gdb:

gcc-arm-none-eabi 10-2020-q4-major [extras]
openocd 0.10.0 [extras]

This happens with request set to "launch" or "attach"

I get a Failed to launch OpenOCD GDB Server: Timeout. popup, with openocd reporting the following on the Output tab:

Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed
in procedure 'init' 
in procedure 'ocd_bouncer'

[jhillyerd]

When I stop a working debug session, whether my program is paused or running, I see Info : dropped 'gdb' connection on the Output tab, and GDB exits. No errors get logged to the dev tools console.

[xoviat]

I have to unplug and plug back in my probe every time I need to re-start debugging because of this issue. I plan to switch to st-link as a solution after #365 is merged.

[jhillyerd]

One workaround I've found, type mon shutdown at the gdb prompt, while the MCU is paused, then stop the debug session. Klunky, and it doesn't always work.

[zlittell]

Also having this issue with pyocd. I can always debug the first time but I get the timeout on subsequent debugs.

Edit additional findings: If I start the debug and run the code, but never pause or break the code , I can stop and start debugging freely without error. If I start pausing or breaking the code and then stop debugging I get this error when trying to debug again. If I then run pyocd gdbserver in powershell, it takes forever, then finally starts. I can then break that command and start a debugging session in cortex-debug again.

When I get the timeout error my output window only has one line 0000446:WARNING:gdb_server:pyocd-gdbserver is deprecated; please use the new combined pyocd tool. When it is successful I get the whole slew of command outputs. So its not the same as the old starting but not knowing its running error. From the console output I can't see that it is even trying to start the process when its locked up in the timeout state.

[devanlai]

I've been playing around with cortex-debug a little to handle a specific use case - launching the GDB server via Zephyr's west debugserver to launch openocd/jlink/pyocd while having cortex-debug terminate the debug server when I end the session - and I'm wondering if the solution I've been prototyping would be generally useful here.

Normally, when the debug session for a launch type session, the session is terminated by sending "target-disconnect", then "gdb-exit", and then killing the GDB server with a SIGTERM signal.

I've found that if you have a wrapper script, killing the process with SIGTERM can leave openocd alive and running in the background such that you have to manually kill it later. The solution I've been playing around with adds (among other things) the ability for each GDB server subclass to provide a list of commands to run just before sending "target-disconnect".

For openocd, I can then send mon shutdown and mon exit before making GDB disconnect. (Actually, it might be redundant to shutdown and then exit versus just exiting, but I'm not sure). This obviates the need to kill the openocd process via signals since it terminates of its own accord.

I had originally envisioned using this in the specific case of having cortex-debug spawn an external GDB server itself (using an extended servertype "external" that supports launch configurations), but it sounds like it might be useful for openocd users that have issues with openocd lingering.

If there's interest in this as a general feature, I'd be happy to open a pull request to add support for sending commands before stopping the session.

[rk-exxec]

A fix for that issue would be nice

[devanlai]

I went back to clean up my code a bit and I retested it, but now I see that my approach doesn't work if you haven't halted the target first, because GDB stubbornly won't allow you to pass through commands to the remote server while the target is running.

I'm not sure if there's a workaround purely within GDB that wouldn't require halting the target first; from what I can tell, this is a pretty fundamental GDB assumption.

[rk-exxec]

Oh, that's a shame.

For me, this issue only happens, if the gdb encounters an error during debugging start. (Failure to erase the flash in my case) Might it be possible to just force-kill the openocd process in such a case?

[devanlai]

I believe that killing the process with SIGKILL will kill openocd even if it's spawned through a wrapper script, but I'm not sure if killing it that way has other side effects.

[haneefdm]

This should have been fixed a while ago. Please let us know (reopen) if this is still a problem

For openocd, you can use monitor [target current] configure -event gdb-detach {shutdown} in your configuration file and this will exit openocd when gdb-detaches. However, it will cause anyone else connected to OpenOCD as well.