We have made our own hardware based on the mangoh design and have been experiencing some problems with the USB hub stopping working after some time. After quite a lot of testing we have identified that it only happens when the USB hub is left lonely without any slave devices connected. We have therefore, in order to investigate if it were a problem with our hardware or something also present on the mangoh boards, removed the CP2130 USB->SPI adapter (U1006) from the mangoh board and then tried attaching and detaching (actually keeping it connected but cutting power to the peripheral) a camera from usb numerous times in a row while monitoring the output of “lsusb –t”. After a number of on/off cycles of the peripheral the USB hub is removed from the lsusb –t output.
Our question is therefore:
• Have anyone else seen this issue and what have you done to overcome it?
• Are there any way to reset the USB hub and reenumerate it when it goes into this state of not connected (we have the possibility to move the reset signal from reset_out from the SOM to a gpio and thereby control it by software).
• Any other idea of what we can do? USB is rather critical for our product and we do not have time for a hardware spin to attach a dummy device to the USB hub. Currently the I2C bus of the SOM isn’t connected to the USB hub in our hardware, but we can do so in a last resort (even though it will need manual hardware modifications of all devices shipped before a hardware spin).
Running dmesg will show the kernel logs. Do you see anything different in the kernel logs in the case where you cycle the camera and it does enumerate vs. doesn’t enumerate?
In the mangOH Red design, the RESET_N pin of the USB3503 is connected to System_reset, so you can’t independently reset the hub using that pin. I also took a quick look at the I2C interface of the USB3503 and there doesn’t appear to be a way to reset the chip using that interface.
You could try disabling the HSIC interface and re-enabling it by doing this:
Hi
Thank you for helping us debug this.
When the connect of the devices work as expected we see something like this in dmesg:
[ 222.819105] msm_hsic_host msm_hsic_host: HSIC-USB exited from low power mode
[ 223.040866] usb 1-1: reset high-speed USB device number 2 using msm_hsic_host
[ 223.380955] usb 1-1.3: new high-speed USB device number 4 using msm_hsic_host
[ 223.482038] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (0c45:6369)
[ 223.536212] uvcvideo: Unable to create debugfs 1-4 directory.
[ 223.561300] input: USB 2.0 Camera as /devices/platform/msm_hsic_host/usb1/1-1/1-1.3/1-1.3:1.0/input/input1
[ 223.645078] 4:4:1: cannot get freq at ep 0x84
Whereas nothing is showing up when the hub has fallen off (which in some way makes sense in that the hub is not connected anymore so the root hub does not get the information that a new device is trying to connect).
I have tried to disable and re-enable the HSIC interface but we still only see this one line in lsusb:
root@swi-mdm9x15:~# lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=msm_hsic_host/1p, 480M
even though I am pulling the reset pin of the usb hub low for a couple of seconds while having the hsic disabled.
I don’t know if it makes any difference properly disconnecting the devices instead of pulling the power as this use-case doesn’t make much sense for us. We have to power off the USB devices as they are attached to the USB hub by traces on the board and therefore we do not have a good way to disconnect them in our end-product.
I have just made a test where I simply pull the plug instead of powering the device off. Same behaviour. I can see in dmesg that the kernel works in the background to make the usb hub reenumerate:
[ 4017.256797] usb 1-1: device not accepting address 2, error -110
[ 4017.265618] usb 1-1: USB disconnect, device number 2
[ 4017.270257] usb 1-1.3: USB disconnect, device number 7
[ 4017.637081] usb 1-1: new high-speed USB device number 8 using msm_hsic_host
.....
[ 4028.056767] usb 1-1: device not accepting address 8, error -110
[ 4028.236868] usb 1-1: new high-speed USB device number 9 using msm_hsic_host
.....
[ 4038.656797] usb 1-1: device not accepting address 9, error -110
[ 4038.836898] usb 1-1: new high-speed USB device number 10 using msm_hsic_host