XMOS USB not recognised on Intel Baytrail J1900
Posted: Fri Jun 30, 2017 12:53 pm
Hi,
I'm using a USB DDC (Digital to Digital converter) Mutec MC-3+ USB containing the XS1-L8A-64-TQ128-C5 XMOS USB controller. I've connected it via USB on two different Intel Baytrail motherboards from different manufacturers. Connecting to the motherboard's USB 2 or USB 3 ports, the Mutec isn't recognised as a USB device at all, either on Windows or Linux. Now the funny thing is that when using an external USB hub, which uses a different USB controller to the native Intel Z36xxx/Z37xxx controller, then it's recognised and works fine. Is there a known problem between the Intel USB controller on Baytrail and this XMOS chip? I have been debugging this with people from the linux-usb community and it does seem like the XMOS controller isn't fully USB2.0 compliant. You can find below the analysis done:
----------------------------------------------------------
> Usbmon
>
> ffff880273fcf880 2363504126 C Ii:1:002:1 0:2048 1 = 04
> ffff880273fcf880 2363504144 S Ii:1:002:1 -115:2048 1 <
> ffff880275298280 2363504217 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363504300 C Ci:1:002:0 0 4 = 01010100
This shows the device being connected.
> ffff880275298280 2363504452 S Co:1:002:0 s 23 01 0010 0002 0000 0
> ffff880275298280 2363504547 C Co:1:002:0 0 0
The kernel tells the hub to clear the Connect-Change status.
> ffff880275298280 2363504609 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363504683 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363536146 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363536303 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363568216 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363568427 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363600156 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363600301 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363632139 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363632308 C Ci:1:002:0 0 4 = 01010000
After 130 ms the device is still connected (the connection is debounced).
> ffff880275298280 2363632346 S Co:1:002:0 s 23 03 0004 0002 0000 0
> ffff880275298280 2363632522 C Co:1:002:0 0 0
The kernel tells the hub to reset the port, which will enable it.
> ffff880275298280 2363648144 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363648306 C Ci:1:002:0 0 4 = 01011100
The hub's port status indicates that the reset has ended, the port is not enabled, and the device has disconnected and reconnected.
> ffff880275298280 2363648345 S Co:1:002:0 s 23 01 0014 0002 0000 0
> ffff880275298280 2363648418 C Co:1:002:0 0 0
> ffff880275298280 2363648511 S Co:1:002:0 s 23 01 0001 0002 0000 0
> ffff880275298280 2363648738 C Co:1:002:0 0 0
> ffff880275298280 2363648794 S Co:1:002:0 s 23 01 0001 0002 0000 0
> ffff880275298280 2363649080 C Co:1:002:0 0 0
The kernel tells the hub to clear the Reset-Changed status and the Enabled status (which wasn't set to begin with, because the reset failed).
> (Repeats this block continuously)
There's not much we can do when the hardware says that the port can't be reset successfully because the device has disconnected.
It sounds like this device is not quite compliant with the USB spec.
-------------------------------------------------------------
Thanks in advance for any help.
Nuno
I'm using a USB DDC (Digital to Digital converter) Mutec MC-3+ USB containing the XS1-L8A-64-TQ128-C5 XMOS USB controller. I've connected it via USB on two different Intel Baytrail motherboards from different manufacturers. Connecting to the motherboard's USB 2 or USB 3 ports, the Mutec isn't recognised as a USB device at all, either on Windows or Linux. Now the funny thing is that when using an external USB hub, which uses a different USB controller to the native Intel Z36xxx/Z37xxx controller, then it's recognised and works fine. Is there a known problem between the Intel USB controller on Baytrail and this XMOS chip? I have been debugging this with people from the linux-usb community and it does seem like the XMOS controller isn't fully USB2.0 compliant. You can find below the analysis done:
----------------------------------------------------------
> Usbmon
>
> ffff880273fcf880 2363504126 C Ii:1:002:1 0:2048 1 = 04
> ffff880273fcf880 2363504144 S Ii:1:002:1 -115:2048 1 <
> ffff880275298280 2363504217 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363504300 C Ci:1:002:0 0 4 = 01010100
This shows the device being connected.
> ffff880275298280 2363504452 S Co:1:002:0 s 23 01 0010 0002 0000 0
> ffff880275298280 2363504547 C Co:1:002:0 0 0
The kernel tells the hub to clear the Connect-Change status.
> ffff880275298280 2363504609 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363504683 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363536146 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363536303 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363568216 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363568427 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363600156 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363600301 C Ci:1:002:0 0 4 = 01010000
> ffff880275298280 2363632139 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363632308 C Ci:1:002:0 0 4 = 01010000
After 130 ms the device is still connected (the connection is debounced).
> ffff880275298280 2363632346 S Co:1:002:0 s 23 03 0004 0002 0000 0
> ffff880275298280 2363632522 C Co:1:002:0 0 0
The kernel tells the hub to reset the port, which will enable it.
> ffff880275298280 2363648144 S Ci:1:002:0 s a3 00 0000 0002 0004 4 <
> ffff880275298280 2363648306 C Ci:1:002:0 0 4 = 01011100
The hub's port status indicates that the reset has ended, the port is not enabled, and the device has disconnected and reconnected.
> ffff880275298280 2363648345 S Co:1:002:0 s 23 01 0014 0002 0000 0
> ffff880275298280 2363648418 C Co:1:002:0 0 0
> ffff880275298280 2363648511 S Co:1:002:0 s 23 01 0001 0002 0000 0
> ffff880275298280 2363648738 C Co:1:002:0 0 0
> ffff880275298280 2363648794 S Co:1:002:0 s 23 01 0001 0002 0000 0
> ffff880275298280 2363649080 C Co:1:002:0 0 0
The kernel tells the hub to clear the Reset-Changed status and the Enabled status (which wasn't set to begin with, because the reset failed).
> (Repeats this block continuously)
There's not much we can do when the hardware says that the port can't be reset successfully because the device has disconnected.
It sounds like this device is not quite compliant with the USB spec.
-------------------------------------------------------------
Thanks in advance for any help.
Nuno