search

whitequark / libfx2

Chip support package for Cypress EZ-USB FX2 series microcontrollers
BSD Zero Clause License
73 stars 26 forks source link

cdc-acm example: port disabled by hub #2

Closed jedrzejboczar closed 4 years ago

jedrzejboczar commented 4 years ago

I tried to start the cdc-acm example on Numato Opsis board. It results in the device being enumerated correctly but when I try to read or write to to serial at /dev/ttyACM0 the kernel disables the device:

[264968.588502] usb usb1-port6: disabled by hub (EMI?), re-enabling...

It then gets enumerated correctly again, e.g.

[264098.323234] usb 1-6: USB disconnect, device number 36
[264098.580121] usb 1-6: new high-speed USB device number 37 using xhci_hcd
[264098.721757] usb 1-6: New USB device found, idVendor=04b4, idProduct=8613, bcdDevice= 0.00
[264098.721764] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[264098.721767] usb 1-6: Product: FX2 series serial interface example
[264098.721771] usb 1-6: Manufacturer: whitequark@whitequark.org
[264098.725829] cdc_acm 1-6:1.0: ttyACM0: USB ACM device
[264968.588502] usb usb1-port6: disabled by hub (EMI?), re-enabling...
[264968.588504] usb 1-6: USB disconnect, device number 37
[264968.845672] usb 1-6: new high-speed USB device number 38 using xhci_hcd
[264968.987283] usb 1-6: New USB device found, idVendor=04b4, idProduct=8613, bcdDevice= 0.00
[264968.987287] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[264968.987289] usb 1-6: Product: FX2 series serial interface example
[264968.987291] usb 1-6: Manufacturer: whitequark@whitequark.org
[264968.989257] cdc_acm 1-6:1.0: ttyACM0: USB ACM device
[265520.727085] usb usb1-port6: disabled by hub (EMI?), re-enabling...

I wonder if you have any idea why this would happen. It seems like the device is sending something when it shouldn't? However I haven't been able to find out which transfer is causing the problem.

whitequark commented 4 years ago

That's quite strange. Can you capture a log with wireshark? I don't have any ideas offhand.

mithro commented 4 years ago

The Numato Opsis is a little strange in that it has a setup where; (a) The FX2 can reset the FPGA. (b) The FPGA can reset the FX2.

This is done so; (a) the FX2 can reset the FPGA during JTAG programming mode (b) The FPGA can cause the FX2 to switch between different operating modes by supplying different FX2 firmware.

What could be happening is that the FX2 is somehow causing the FPGA to reset which in turn resets the FX2. There is a jump you can remove which prevents the FPGA from being able to do this reset. I think it's call JRST or something?

There is some info at https://opsis.hdmi2usb.tv/features/usb-peripheral.html but there are also some lies I have never got around to fixing.

whitequark commented 4 years ago

Yeah, I was wondering if something like that was happening. That sounds like the most likely explanation.

jedrzejboczar commented 4 years ago

Ok, thanks, this may be the problem. I'll test as soon as possible, so most likely on Monday.

jedrzejboczar commented 4 years ago

I tried removing the JFX2-RST jumper but it didn't fix the problem, so most likely this is not the FPGA resetting the FX2.

I checked the USB traffic using usbmon and Wireshark. I can see multiple BULK IN transfers (EP6) with responses from FX2 resulting in -EOVERFLOW, which in theory means too long data packet, but is probably related to random data on the line. I also tried disabling all the code available for responding on endpoint 6 in cdc example, but the problem still occurs.

The disabled by hub (EMI?), re-enabling... error in system logs comes from hub.c here, so the message is probably not related to disconnection or overcurrent (relevant discussion). And indeed shortly after those failing transfers there are GET_STATUS and CLEAR_GEATURE: C_PORT_ENABLE issued to the hub, which restarts the hub.

So this looks like some interference on the line, but the firmware from hdmi2usb works without a problem on the same hardware and I wonder what makes this CDC example fail.

As Wireshark shows only whole transfers, some random data may be sent which causes the hub to consider it as EMI. The problem seems similar to this one, which may suggest that it is somehow linux-specific, but I haven't tested it under Windows.

Another strange behavior is that when I switched kernel to older version (5.3.5 -> 4.19.78) usbtest driver gets loaded for the device. On 5.3.5 cdc_acm was being loaded correctly at first, but now after switching back to 5.3.5 from 4.19.78 usbtest is being loaded each time. After manually unbinding the driver and switching it to cdc_acm, the problem happens in the same way (but after restarting the hub usbtest gets loaded again).

In case this could be helpful I attach files with:

whitequark commented 4 years ago

I have an OpenVizsla and a Numato Opsis. I'm fairly busy right now, but if @mithro wants we could arrange something to prioritize this issue.

jedrzejboczar commented 4 years ago

Indeed the problem was specific to Numato Opsis and it was the jumper, but it is somehow necessary to remove it before powering on the board, which I didn't suspect as the the problems happens only on a CDC data transfer, so it would seem that jumper could as well be removed after power-up.

Anyway the problem is not related to libfx2, so the issue can be closed.