Issues with some USB controllers? (Was: VirtualBox USB forwarding with TinyFPGA Bootloader)


#1

Just wondering, has anyone else tried using the VirtualBox Extension Pack’s USB forwarding, to forward a TinyFPGA to a guest OS?

I just tried it here to forward the USB device from a Windows host to a Linux guest (where I’d rather run the FPGA dev toolchain), but it not only failed, but managed to break the VM badly (i.e. causing IO errors for the virtualized disk drive somehow). Forwarding other USB devices works fine, but it seems like some interaction between the TinyFPGA bootloader’s USB stack and VirtualBox’s USB forwarding implementation really don’t play well together.

Probably going to either do the programming from the host, or use a different machine, but I thought it worth bringing this up. Looking forward to trying out some ideas on this board.


#2

I don’t know anything about the Extension Pack, and am not using it, but I am able to program my TinyFPGA from within a Linux guest in a MacOS host.

I didn’t do anything special, other than add an entry to the USB device filters in the settings for the VM:

17%20AM

It is necessary to plug in the TinyFPGA after the VM boots, but other than that, everything just works.


#3

Hmm, maybe it plays nicer with the USB 1.1 mode that doesn’t require the extension pack. I was using the USB 2.0/3.0 modes as those are what I usually use and have success with for USB passthrough. I’ll give that a try tonight.


#4

So nope, USB passthrough still didn’t like the device in USB 1.1 mode either. Still breaks the VM and also causes the Windows host to give an “One of the USB devices attached to this computer has malfunctioned” error.

I then proceeded to try testing the programmer under Windows… which since I’m on Winodws 7 involved installing an inf to tell Windows to use the right driver for the VID/PID. This looked like it worked, the device was recognized and showed up as a port in Device Manager… but if I actually try to open the serial port in the programmer or any program? The program trying to do so freezes until I unplug the device to force an error, so that’s no good.

So it seems my Windows 7 machine doesn’t like the TinyFPGA BX’s USB at all, whether it’s using it directly or forwarding it to a VM. Tried various things such as through a hub or direct to the case front connector too just in case, but no dice.

Moving to a native Linux machine though… it works 100% fine


#5

It works fine on my Windows 10 laptop, but on my Linux machine it occasionally stops all my USB devices from working and I then have to reboot using the power button :frowning_face:


#6

What USB host controller? Can you paste an lspci?


#7

I have not investigated this. It happens every few hours when I am doing lots of uploads. I have not seen the machine do it with other USB devices. I am also using a USB UART device for the picosoc uart, so that could be the culprit, but I have not had the problem with that before. Here is my lspci:

00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0e)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA AHCI Controller (rev 0e)
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI (rev 0e)
00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e)
00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller (rev 0e)
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 1 (rev 0e)
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 2 (rev 0e)
00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 3 (rev 0e)
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 4 (rev 0e)
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0e)
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus Controller (rev 0e)
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

#8

On my same desktop where it’s not working under Windows 7, I booted into Linux to see if it would be any happier connected to this machine under a different OS… and what I’m seeing is the TinyFPGA bootloader endlessly being connected and disconnected over and over. This doesn’t seem expected, and seems to happen regardless of if anything has the port open.

[ 1145.011174] usb 3-11: USB disconnect, device number 61
[ 1145.011258] cdc_acm 3-11:1.0: failed to set dtr/rts
[ 1145.426729] usb 3-11: new full-speed USB device number 62 using xhci_hcd
[ 1145.575236] usb 3-11: New USB device found, idVendor=1209, idProduct=2100
[ 1145.575239] usb 3-11: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1145.575908] cdc_acm 3-11:1.0: ttyACM0: USB ACM device
[ 1160.011772] usb 3-11: USB disconnect, device number 62
[ 1160.011872] cdc_acm 3-11:1.0: failed to set dtr/rts
[ 1160.426806] usb 3-11: new full-speed USB device number 63 using xhci_hcd
[ 1160.575353] usb 3-11: New USB device found, idVendor=1209, idProduct=2100
[ 1160.575357] usb 3-11: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1160.575987] cdc_acm 3-11:1.0: ttyACM0: USB ACM device

lspci output in my case is:

00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller (rev 06)
00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller
00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V
00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2
00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
00:1c.3 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d0)
00:1c.7 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 8 (rev d0)
00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1
00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family Z97 LPC Controller
00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)
06:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe

And kernel version just in case relevant:

Linux ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

And just in case, the lsusb -t output showing where on the bus it’s connected “Port 11” is where the TinyFPGA is hooked up, showing as “Dev 116” now:

/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 5: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
    |__ Port 9: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 4: Dev 7, If 2, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 4: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 4: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 2: Dev 6, If 1, Class=Audio, Driver=snd-usb-audio, 12M
            |__ Port 2: Dev 6, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 11: Dev 116, If 0, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 11: Dev 116, If 1, Class=CDC Data, Driver=cdc_acm, 12M
    |__ Port 13: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 13: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 13: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 14: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 14: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M

It doesn’t do this on two of my laptops running Linux… but on my desktop, it behaves odd whether directly under Linux, directly under Windows 7, or trying to do Virtualbox USB forwarding under Win 7. Makes me think it’s related to the USB controller, though not certain.


#9

What happens if you connect it through a USB hub?


#10

If I connected it via powered USB hub (the one labeled “Port 9: Dev 2” in the above lsusb output), it behaves almost the exact same. It keeps periodically disconnecting/reconnecting as before, but additionally it starts spamming the following two lines over and over for about a couple hundred ms before before the “USB disconnect” message:

[   115.029514] xhci_hcd 0000:00:14.0: WARN Cannot submt Set TR Deq Ptr
[   115.029517] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.

#11

Wow…that is very curious. What version of Linux are you running?


#12

kernel version 4.15.0, and more specifically, running Ubuntu off the latest live boot ISO, “ubuntu-18.04.1-desktop-amd64.iso”
Didn’t have a Linux install (aside from in VM) on the desktop, just my laptops, so I booted the desktop off that iso to do a quick test to see if it broke under Linux as it is under Win 7 on the same machine.


#13

So I did some digging and used debugfs+usbmon that the Linux kernel provides to get a low level trace of USB activity via /sys/kernel/debug/usb/usbmon/

What I discovered from examining some hex digits that looked in the ASCII range in the USB trace… was it appears something in the Ubuntu environment was blindly sending “AT^SQPORT?\r” followed by repeated “AT\r” to the device!

Turns out this ‘something’ was the ModemManager process that goes along with NetworkManager. For some reason ModemManager thinks it appropriate to send AT commands to any old serial device it meets, and also turns out the TinyFPGA bootloader really really doesn’t like AT commands and disconnects upon receiving that.

With that process killed, it seems to connect and stay connected just fine.

In case it helps anyone else who runs into this, apparently you can set a UDEV rule to cause ModemManager to ignore serial ports based on USB VID/PID. See here

Apparently ModemManager’s source code contains a preset list of PIDs/VIDs they’ll ignore, things like some common UPS devices mostly… but anything else? Apparently ModemManager thinks it’s fair game to throw AT commands around to make serial modems plug-n-play.

So… it’s now working on Linux on my desktop. Whatever is going wrong in Windows 7 on the same desktop at this point is something different, and this seems to clear the USB host controller’s good name.

(EDIT: And now it’s working now under Windows? The VirtualBox forwarding is still broken… It looks like maybe the freezing under Windows only occurs after a failed attempted at the VirtualBox USB forwarding, and a reboot is needed to make the COM port work under Windows again)


#14

Ah, yes - ModemManager. If you don’t need it, turn it off. Permanently.


#15

Sorry to bring this back up but I’m having trouble too.

  • My host PC in Win7 and when I plug in tinyFPGA BX I get a COM22 port (showing as a Teensy)
  • I run Ubuntu 18.04 in a VirtualBox VM
  • The board shows up under USB devices as InterBiometrics (VID/PID of 1209/2100)
  • When I try to attach the driver fails so I tried adding the UDEV rule to cause ModemManager to ignore this device but that didn’t help

Am I missing something that I need to do?


#16

I saw a similar problem in VMware (Ubuntu guest) on Windows 10 host. Device works well on Windows, but something goes very wrong at the handoff to the VM. I have a USB analyzer on my desk, and I’m supposed to know how USB works… so I checked. Looks like a problem handling USB reset, but I didn’t go into it deeply. Writing this, I have a hunch that USB reset might not be resetting all the device state properly, but … that’s just a hunch.

The trace shows that the the SET ADDRESS to the device after USB reset was not being acked.

Note that the device was previously in the addressed state (at address 21) and functioning; when you do a VM handoff, the system issues a reset, which is supposed to put the device back to address 0. Since the setups do not get an ack after the DATA0, it looks very much as if the device address register didn’t get cleared by USB reset.

There’s a free tool called USB3CV from USB-IF (usb.org). It validates basic USB compliance, and tests all these fine points.


#17

That’s some great debugging! I think you are correct. I’ll have to take a close look at the device reset and see what I can do. I might just have it issue an FPGA-level reboot.


#18

Depends on how you handle USB reset. If you clear the “configured” state flag (if you have one), and clear the address register, you’ll pretty much be back where you started.

There’s some pretty tight response time requirements after reset; you might not have time to reboot. Running the USBCV tests without a bus analyzer is a pain… but I have a bus analyzer and I’m motivated to help, so I can test changes. (If I weren’t heads down getting ready for the RISC-V show, I could probably hack on the RTL, but…) I’ll swap helping fix this for a little guidance on my project. (Where should I post about that? The post should start with a longish description of what I’m trying to do…)


#19

Luckily I have a protocol analyzer that will work for full-speed USB. You can post your project right here on the forums. I think the “TinyFPGA Projects” category is the best fit.