pico-debug under WSL2 using usbipd-win - openocd with debug output reports "skipping interface 0, endpoint[0] is not bulk out"
geefer opened this issue · 8 comments
This may not be supported at this point however I thought it would be useful to ask. I also apologise as this may not be actually a pico-debug "issue" but related to the use of usbipd-win but I would appreciate any thoughts or pointers as this configuration could be useful to others.
I am trying to run pico-debug using an Ubuntu 20.04LTS distribution in the latest WSL2 on Windows 10. To make the physical USB ports available from the Linux WSL2 system I am using the usbipd-win package (https://github.com/dorssel/usbipd-win). I have a udev rules file to allow access to the port from a non root user.
I have downloaded, compiled and installed the openocd package as described in your instructions at https://github.com/majbthrd/pico-debug/blob/master/howto/openocd.md
Once the usbipd Windows service is running I can successfully attach the relevant USB port to the WSL2 Ubuntu instance and lsusb gives me the following response:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1209:2488 Generic Peter Lawrence CMSIS-DAP Dapper Miser
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lsusb -vgives the following for the port in question:
Bus 001 Device 006: ID 1209:2488 Generic Peter Lawrence CMSIS-DAP Dapper Miser
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1209 Generic
idProduct 0x2488 Peter Lawrence CMSIS-DAP Dapper Miser
bcdDevice 10.03
iManufacturer 2 pico-debug
iProduct 1 CMSIS-DAP
iSerial 3 E66038B713297738
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 32
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
However, when running "openocd -f board/pico-debug.cfg" I get the following:
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Error: unable to find a matching CMSIS-DAP device
With the -d option there is additional output relating to the port :
Debug: 61 8 cmsis_dap_usb_bulk.c:161 cmsis_dap_usb_open(): found product string of 0x1209:0x2488 'CMSIS-DAP'
Debug: 62 8 cmsis_dap_usb_bulk.c:181 cmsis_dap_usb_open(): enumerating interfaces of 0x1209:0x2488
Debug: 63 8 cmsis_dap_usb_bulk.c:248 cmsis_dap_usb_open(): skipping interface 0, endpoint[0] is not bulk out
I am not sure whether pico-debug is accessed as an HID or Bulk device but if I run the command:
openocd -f board/pico-debug.cfg -c "cmsis_dap_backend hid" -d
I just get the response:
Error: 61 3 cmsis_dap.c:305 cmsis_dap_open(): unable to find a matching CMSIS-DAP device
Adding LOG_DEBUG() commands into the openocd source and re-building and re-running I can see that its attempts to enumerate an HID device fail in cmsis_dap_usb_hid.c so it then tries to look for a bulk device in cmsis_dap_usb_bulk.c whereupon it fails with the message about endpoint not being bulk out that I show above.
It may be that the usbipd-win implementation is not yet fully featured enough to allow what I am trying to do but as I have no background in USB it is very difficult to know so I would appreciate any thoughts or ideas where to look further.
I do not have any familiarity with WSL2 or usbipd-win. I do not have a local system with it to try either.
To answer your question, the pico-debug implementation uses HID, not BULK.
As your debugging shows, the issue is that openocd can't communicate with the device. That implies it is the udev rule, WSL2, usbipd-win, or Windows (not relinquishing the device).
Have you tried running openocd with sudo? If it works with sudo, then your udev rule is likely what is at issue. For what it is worth, here is my local udev rule (/etc/udev/rules.d/98-CMSIS-DAP.rules):
ATTRS{product}=="*CMSIS-DAP*", MODE="664", GROUP="plugdev"
It is not clear to me why you are using Linux instead of Windows to run openocd. For what it is worth, openocd does run natively in Windows.
Hope that helps.
Thanks for your reply and for confirming that the implementation uses HID not BULK. That implies that the failure is coming from the call to hid_enumerate(0x0, 0x0) in the openocd file cmsis_dap_usb_hid.c which returns zero and causes openocd to then try to open as BULK giving the error message I am seeing.
I think Windows is relinquishing the device as the Device Manager entry disappears when the usbipd attach command is executed to attach the USB device to the WSL2 instance. Also since the device is recognised by lsusb does that not imply at least some communication with it? I have tried running opencd with sudo and it makes no difference and without my udev rule it fails to get even as far as it does.
I will have to look further into this and whether usbipd-win is not supporting HID or not fully. Early versions of usbipd-win only supported BULK endpoints but according to their release notes by 1.1.0 it was "feature complete" so maybe I mis-interpreted what they mean by that (I'm using 1.3.0).
As to why I wish to use Linux to run openocd, I have worked in both Windows and Linux development environments before and find I prefer to develop in Linux. I may end up having to be pragmatic though...
Got it. Just food for thought: openocd is nothing but a GDB server implementation that listens on a TCP port. If you ran openocd in Windows and connected to it via Linux, all your development remains in Linux. (I am presuming that WSL2 doesn't require anything special for the Linux subsystem to connect to network services running in Windows.) Such an approach might save you from the artificial complexity of tunneling USB traffic over a virtual network between two OSes.
Thanks, I will have a look at that option.
Though I don't know what it means, there may be a clue in the Linux dmesg output when the USB port is attached to the WSL2 instance and Linux detects it (before trying to run openocd):
[ 5276.414655] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(3)
[ 5276.414659] vhci_hcd vhci_hcd.0: devid(196616) speed(2) speed_str(full-speed)
[ 5276.414737] vhci_hcd vhci_hcd.0: Device attached
[ 5276.686124] vhci_hcd: vhci_device speed not set
[ 5276.756096] usb 1-1: new full-speed USB device number 4 using vhci_hcd
[ 5276.836128] vhci_hcd: vhci_device speed not set
[ 5276.906120] usb 1-1: SetAddress Request (4) to port 0
[ 5277.008613] usb 1-1: New USB device found, idVendor=1209, idProduct=2488, bcdDevice=10.03
[ 5277.008615] usb 1-1: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[ 5277.008617] usb 1-1: Product: CMSIS-DAP
[ 5277.008618] usb 1-1: Manufacturer: pico-debug
[ 5277.008618] usb 1-1: SerialNumber: E66038B713297738
[ 5277.015763] hid-generic 0003:1209:2488.0003: device has no listeners, quitting
This looks like it may be important but I don't know enough about what is going on here to understand it. It looks as though the device has been kicked off the bus or something?
Such dealings would be at a kernel level, not at the USB bus level.
This is well outside my area, but it does look like there is a Linux kernel build option of "CONFIG_USB_HIDDEV" that might not be set in WSL2. Certainly, if one does a web search for "device has no listeners, quitting", one will see others that report issues with Linux kernels not supporting USB HID devices.
I would like to re-iterate my earlier suggestion. GDB is intended to go over a network; USB is not.
Just for completeness, Windows binaries of OpenOCD are available in a few ways.
Since the Raspberry Pi organization likes to be proprietary, they have their own OpenOCD fork. The following is a build of that fork, but the July 2021 release adds CMSIS-DAP support (including pico-debug):
https://github.com/earlephilhower/pico-quick-toolchain/releases
xPack is the unofficial official build of OpenOCD (which has supported pico-debug since its release):
Thanks. I will look at those and the direct network approach as well as possibly recompiling my WSL2 kernel which the usbipd-win repo also has instructions for.
To wrap this up and hopefully help anyone else attempting this, I have managed to get this work by setting some extra Linux kernel build options (including the "CONFIG_USB_HIDDEV" option you suggested above but also some others).
I built my own WSL2 kernel following the instructions at https://github.com/dorssel/usbipd-win/wiki/WSL-support and added the following additional options (over and above the ones recommended in that link):
CONFIG_HIDRAW=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_SERIAL_DEBUG=y
CONFIG_USB_HIDDEV on its own was not enough and I added the others listed above. CONFIG_USB_SERIAL_DEBUG is definitely needed but I am not sure about CONFIG_HIDRAW.
Thanks very much for making this extremely useful pico-debug tool. I'm now using Visual Studio Code running in Windows connecting to the WSL2 instance running Ubuntu which itself is running openocd connecting to a USB interface on the PC (attached to the WSL2 instance via usbipd-win) and I can happily debug my C code on the Pico.