OpenOCD server drops GDB connection with LIBUSB error

[oswinrodrigues]

Steps To Reproduce

1. Start debug session, arrive at main entry
2. Set breakpoint a couple lines down
3. Continue code-execution until said breakpoint
4. GDB connection to OpenOCD server drops
5. OpenOCD log shows a libusb_handle_events() failed with LIBUSB_ERROR_INTERRUPTED message

Setup

launch.json - Click To Expand

```json { "name": "(gdb) Stack Controller", "type": "cortex-debug", "request": "launch", "cwd": "${workspaceFolder}", "servertype": "openocd", "serverArgs": ["-c ftdi_serial nebb13"], "searchDir": ["${workspaceFolder}/prog"], "configFiles": ["sc_busblaster.cfg"], "device": "TM4C1294NCPDT", "executable": "${workspaceFolder}/fw/bin/tiva/sc.exe", "runToEntryPoint": "main", "overrideLaunchCommands": ["monitor reset halt"] } ```

I have an interesting networking setup. Using VS Code on my Mac at home. With the Remote - SSH extension, I tunnel into an Ubuntu 18.04 VM that is hosted on my Windows 10 machine at work. The openocd and gdb installations are on this VM. As well, the debug probes' USB connections are captured by the VM (physically connected to the machine at work). I tried removing some of these layers by launching a debug session directly on the VS Code instance in the VM, and I see the same behaviour.

Logs

OpenOCD - Click To Expand

``` Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : FTDI SWD mode enabled trst_only separate trst_push_pull adapter speed: 500 kHz Info : clock speed 500 kHz Info : SWD DPIDR 0x2ba01477 Info : tm4c1294ncpdt.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'gdb' connection on tcp/50000 undefined debug reason 7 - target needs reset adapter speed: 500 kHz cortex_m reset_config sysresetreq target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0000177c msp: 0x200014cc Info : dropped 'gdb' connection Error: libusb_handle_events() failed with LIBUSB_ERROR_INTERRUPTED ```

GDB - Click To Expand

``` Please check OUTPUT tab (Adapter Output) for output from openocd Launching server: "openocd" "-c" "gdb_port 50000" "-s" "/home/orodrigues/bms-device/prog" "-f" "sc_busblaster.cfg" "-c ftdi_serial nebb13" Launching GDB: "arm-none-eabi-gdb" "-q" "--interpreter=mi2" Reading symbols from /home/orodrigues/bms-device/fw/bin/tiva/sc.exe... done. main () at sc/src/main.cpp:57 57 int main() { Not implemented stop reason (assuming exception): undefined adapter speed: 500 kHz cortex_m reset_config sysresetreq target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0000177c msp: 0x200014cc Note: automatically using hardware breakpoints for read-only addresses. Temporary breakpoint 1, main () at sc/src/main.cpp:57 57 int main() { b 78 Breakpoint 2 at 0x264fe: file sc/src/main.cpp, line 78. {"token":707,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}} c Continuing. {"token":710,"outOfBandRecord":[],"resultRecords":{"resultClass":"running","results":[]}} Breakpoint 2, main () at sc/src/main.cpp:78 78 if (board.getJtagDisabledState()) ```

Some Observations

• The last line in the OpenOCD log, with the LIBUSB error, does not always appear. But the behaviour is consistent.
• This behaviour is not observed if I use openocd and gdb in the terminal directly.
• For some odd reason, this problem does not happen if the breakpoint is between lines 57 and 78. It also does not seem to occur if I place a breakpoint in other functions, at points that occur after main.cpp:78 in the code path, such as inside getJtagDisabledState() or just any point during the main execution loop of the firmware.
• Sometimes, a step over / into / out anywhere in the code (even during the main execution loop) results in a dropped connection as well, but without the LIBUSB error showing up.
• (Might be unrelated but) sometimes, a step over / into / out seems to act as if it was a continue operation. The code just runs and doesn't stop until it reaches a breakpoint.

[Marus]

The cortex-debug doesn't do any handling of the USB layer - this is entirely within OpenOCD.

Don't have any idea why you would be getting different behaviour when running it directly within that VM mind you, other than launching the OpenOCD command all of the extensions interaction is through the GDB machine interface.

If I had to guess it's likely that the USB connection in the VM is not entirely stable; perhaps using it from the command line interface doesn't expose the issue as you are likely issuing far less commands to the GDB server - and thus it has less traffic over the debug probe's connection. The extension loads things like core registers, possibly peripheral registers, any watches, etc. every time execution stops - which would lead to much higher bursts of traffic than you would get trying to manually enter those commands in GDB.

[oswinrodrigues]

Don't have any idea why you would be getting different behaviour when running it directly within that VM

Just to clarify, this is not the case. Rather "I see the same behaviour" when trying to reproduce directly (using RDP) in the VM i.e. removing the whole SSH + VPN tunnel layering.

That said, I think I understand that's besides the point. The VM's USB connection-handling seems to be what you're suggesting is the issue. My question then is: in order to avoid the high bursts of traffic, is there any way to optionally disable or control how much information is loaded? I wouldn't need anything more than just variables in the local scope.

[Marus]

Not really, it needs to be able to load information in order for functionality of the extension. The likely issue is simply that this happens much quicker than it would if you are manually typing in the gdb commands as well, it can send commands a lot quicker than you could - which seems to be an issue with the USB in the VM.

Don't know what VM environment you are using - but you could consider trying a different VM, possible that it might have a better USB passthrough which wouldn't have issues.

[haneefdm]

The only VM I trust with USB is VMWare. While it costs money, it is worth the frustration. Some people had luck with Parallels, but I have not tried it

[oswinrodrigues]

Gotcha. So to confirm, this extension isn't really meant to be used inside a VM then? It may work, it may not, depending on the VM environment, etc.?

If so, then maybe this is something that can be flagged on the extension's landing page, that this is an undocumented and unsupported use case and behaviour? Definitely would be good for someone else in my shoes to know when considering whether to install the cortex-debug extension.

On that note, seeing that this was based on the Native Debug extension, does anyone know if that happens to have VM support?

[oswinrodrigues]

I confirmed this works on a host OS. So yes, this is an issue with the VM's USB handling.

@Marus, I'll leave it to you to decide whether to mention this on the README / the extension's landing page. It's not uncommon for developers to be working within a VM and so this might be a good thing to flag.

[oswinrodrigues]

On that note, seeing that this was based on the Native Debug extension, does anyone know if that happens to have VM support?

@Marus, would you know anything about this? Thanks for your time 🙏🏽