Attaching an ESP32 via CH340 causes an error

[Noxoreos]

TLDR

• Just installed USBIPD v4.0.0 on WSL2 Ubuntu in Windows 10

• Trying to use it with an ESP32 which has a CH340 chip on the devboard

• Windows can use the device properly

• Bound USB-Device corectly

• Attaching causes an error

• The USB device is no longer recognized until I reboot Windows

• What now?

Full Description

Hello,

I have just installed USBIPD version 4.0.0 in a Win10 Pro Computer.

I'm using WSL2 with Ubuntu:

$ wsl --list --all --verbose
  NAME                   STATE           VERSION
* Ubuntu                 Running         2
  docker-desktop-data    Stopped         2
  docker-desktop         Stopped         2

Now when I connect my ESP32 devboard to my computer, it works fine. The devboard communicates to USB via a CH340 chip for which I have the drivers installed in my system.

After installing USBIPD v4.0.0, I followed the the instructions and bound the device to share it using a powershell with admin permissions:

$ usbipd list
Connected:
BUSID  VID:PID    DEVICE                                                        STATE
3-12   25a7:fa67  USB-Eingabegerät                                              Not shared
5-2    152d:578e  Per USB angeschlossenes SCSI (UAS)-Massenspeichergerät        Not shared
7-1    1a86:7523  USB-SERIAL CH340 (COM3)                                       Shared
7-4    07fd:0002  MOTU Audio                                                    Not shared
9-2    058f:6364  USB-Massenspeichergerät, USB-Eingabegerät                     Not shared
9-3    0a12:0001  Generic Bluetooth Radio                                       Not shared
9-4    046d:c52b  Logitech USB Input Device, USB-Eingabegerät                   Not shared

Persisted:
GUID                                  DEVICE

After I tried to attach the device, I got an error and heard the "USB device disconnected"-sound coming from Windows. Unpluging the device and plugging it back in has no effect and it does not work anymore - I have to reboot Windows for it to work again.

Here is the output, that I get.

• After trying to attach

  $ usbipd attach -i 1a86:7523 -w
  usbipd: info: Device with hardware-id '1a86:7523' found at busid '7-1'.
  usbipd: info: Using WSL distribution 'Ubuntu' to attach; the device will be available in all WSL 2 distributions.
  usbipd: info: Using IP address 172.17.208.1 to reach the host.
  WSL usbip: error: Attach Request for 7-1 failed - Device in error state
  usbipd: error: Failed to attach device with busid '7-1'.

• Listing devices again

  
  $ usbipd list
  Connected:
  BUSID  VID:PID    DEVICE                                                        STATE
  3-12   25a7:fa67  USB-Eingabegerät                                              Not shared
  5-2    152d:578e  Per USB angeschlossenes SCSI (UAS)-Massenspeichergerät        Not shared
  7-4    07fd:0002  MOTU Audio                                                    Not shared
  9-2    058f:6364  USB-Massenspeichergerät, USB-Eingabegerät                     Not shared
  9-3    0a12:0001  Generic Bluetooth Radio                                       Not shared
  9-4    046d:c52b  Logitech USB Input Device, USB-Eingabegerät                   Not shared

Persisted: GUID DEVICE 358623cf-530e-4db0-87d1-bec49d24ad35 USB-SERIAL CH340 (COM3)

Am I doing something wrong or what might be the issue here?

[dorssel]

I don't known, but you could try using usbipd bind --force and then reboot. This should make the device work in WSL.

[Noxoreos]

Okay, I've tried that, but unfortunately this causes a whole lot of problems and the device still not being able to be recognized.

Here is what went down:

• I ran usbipd bind -f -i 1a86:7523 and that seemed to enter an endless loop on the usbipd-win application. The command never returned, so I closed the terminal after waiting for about fifteen minutes (I had opened that terminal with admin permissions as it should be). It asked me if I agree to quit the running command, so I confirmed.
• After opening a new Powershel instance, I ran usbipd list and the device did show up as Shared (forced) state.
• I tried running the attach command as before (without the auto-attach option) and this caused the WSL2 distro (Ubuntu) to crash and show an error that the "mass storage device can't be read". This is a microcontroller chip and not a mass storage device, so that makes sense.
• I was not able to start up WSL again, because it crashed on every try to run it.
• So I unbound the device again in another terminal with admin privileges for it via usbipd unbind -a and that also did not return anymore, so I had to quit the same way as before, when trying to force-bind
• The WSL was still unable to start up. so I tried to reboot my computer and that locked up, too. I waited more than an hour on that "rebooting" loading spinner and finally gave up, by force rebooting via the reset button
• After booting completed I noticed, that the USB device did not register properly anymore and after checking the device manager, I found the device being listed as "VirtualBox USB" and not as "CH340 on COM3" anymore. This was still the case after trying another system reboot - which also locked up.
• So I attempted to uninstall the whole device in the device manager and that started another endless progress bar, which i left running for over an hour as well. This blocked the whole device manager.
• Another force reboot later, it seems that the device is now registering properly again (on a different COM port now).
• WSL2 also did not crash anymore.
• I tested de device on Windows and it worked as before, so I tried the wole force binding as well and the same story started again with a slight difference: This time running the attach command did not crash WSL, but the device did not show up when I ran lsusb. THere I only saw two "root hub" entries with other Ids than my device:

  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

• Checking the device manager revealed that it was changed back to a "VirtualBox USB" device as before and not as COM device as ist should be.

I hope that helps to figure out what might be the issue here. At this point it feels like more people could run into similar issues, since I don't think that I did something no one else would do.

[dorssel]

seemed to enter an endless loop on the usbipd-win application

There is no looping going on, only a change of device driver which is waited on. Windows apparently never finishes the driver installation.

I was not able to start up WSL again, because it crashed on every try to run it.

usbipd-win does nothing with WSL until you run attach --wsl. The fact that WSL doesn't start up is unrelated.

usbipd unbind -a and that also did not return anymore

Again, Windows is stuck on driver installation. All usbipd-win does is instruct Windows to install a different driver and waits for that to finish.

The WSL was still unable to start up. so I tried to reboot my computer and that locked up, too.

Again, WSL not starting up has nothing to do with usbipd-win.,Also, Windows not booting is again unrelated. usbipd-win doesn't do anything until you give it a command.

device being listed as "VirtualBox USB"

That makes sense. The driver usbipd-win uses is the one from VirtualBox. After installation it changes the name of the driver to "USBIP Shared Device". It never got to change the name, since the installation of the driver never finished.

Checking the device manager revealed that it was changed back to a "VirtualBox USB"

Again, the driver fails to install.

I don't think that I did something no one else would do

I hate to tell you this, but it looks like your Windows driver database is corrupt. The fact that Windows fails to install (or uninstall) drivers to completion, the fact that WSL crashes, and that Windows reboot is flaky are clear indications of some sort of system corruption.

[Noxoreos]

The thing is, that I'm on a relatively fresh install of windows with only a few software components installed on it at this point. I had no issues with drivers before running the bind command with the force flag. Whenever the driver is changed as you describe, only then these issues started. Then, whenever I fixed the issues caused by that change (completely uninstall and reinstall the device), then everything went back to normal. Including driver installation or removal and system reboot behavior. And the fact that I experienced this twice in pretty much the same way, must have something to do with how the mentioned driver switch is performed or with the driver that is being used to switch to.

What I'm confused about is, that after this change it is listed as "VirtualBox USB". I suppose it is not compatible with the device, which would explain lockup behavior.

usbipd-win does nothing with WSL until you run attach --wsl. The fact that WSL doesn't start up is unrelated.

Actually, I did mention that I ran the attach command (with the -w option), so this is related. I also explained that WSL was back to normal after detaching/unbinding and force rebooting my system

[Noxoreos]

Btw. I'm trying to be constructive. I'm just describing what I did exactly and report what the result is. I was not saying that the application is continually interfering with the system. I meant that the changes, performed by the bind command seem to cause driver issues, at least for some devices (like the one i'm using). It's not like someone is going to know which devices can be bound without issues and which can't. So I suppose it is at least good to know when something like this happens and how many people experience this.

[dorssel]

It is possible that the VirtualBox driver is somehow incompatible with the device and/or your platform. Have you (or did you have in the past) VirtualBox itself installed? If so, a driver version mismatch could cause problems. But I have never heard of it causing Windows boot failures. And it cannot be related to

I was not able to start up WSL again, because it crashed on every try to run it.

as when WSL starts up, no USB drivers are involved until you run attach.

[Noxoreos]

I have not installed VirtualBox after the fresh install, which was quite recent. That was why I was confused seeing it there. On the other hand I have docker desktop installed on my system and I'm not sure which virtualization engine is used there.

What exactly is the Virtual Box USB driver supposed to do? Is it some kind of bridge or usb proxy?

But I have never heard of it causing Windows boot failures. And it cannot be related to

When a driver is locked up for some reason then Windows not being able to shut down is not uncommon. Unless it causes a blue screen (which I did not see). But in case of a blue screen it is also usually not shutting down on its own.

A driver incompatibility issue could cause that and Windows does not usually install drivers which don't fit to a device. Does the force option override that behavior? This would at least explain the issues that I had, I would think.

as when WSL starts up, no USB drivers are involved until you run attach.

Yes that makes sense. As I said i did run attach on my device, because it looked as if binding did work properly at first glance.

Regarding Virtual Box, maybe I could try to install it and see if the device could be recognized in there. Not sure though, what kind of USB devices Virtual Box supports.

[dorssel]

The VirtualBox driver is a so called "stub" driver. It allows to send URBs from user code. Essentially, it is a "NULL" driver with a tap that you can hook into. It is dormant when the device is unused, and (as far as I know) it is compatible with all USB devices (so far, at least).

And normally usbipd-win works better without a full installation of VirtualBox, but you could (temporarily) install it to see if it too has issues.

[dorssel]

Any news on this?

[Noxoreos]

Hello,

there isn't really any solution that I was able to come up with in terms of combining microcontoller programming an WSL2.

I've spent a few more hours to try out VirtualBox, but didn't have any success with it, so I stopped trying, because I didn't feel like it's worth the effort. I don't have much free time for own projects (dayjob, wife, kids) and so now I'm using a Raspberry P 3Bb instead, that I didn't have any other purpose for. That worked well for me. I have docker installed on the PI and interface to it using a VSCode extension. This allows a very similar Workflow to to what WSL2 does. I only do this for programming my microcontrollers. For coding projects that don't require hardware, I still use WSL2.