Hi Carlos,
thanks for your reply. I share your opinion of using compliant devices only. Unfortunately, the mentioned USB Key appears to be compliant with the USB chapter 9 tests (verified with USB-IF Command verifier tool). Is there another compliance-check that verifies the basic USB device capabilities?
Although it is not fully compliant with the MSD class specs (according to the verifier tool), this should not yet be a problem in this case. The MFS driver does not even get informed when inserting the key, no MSD transactions take place. The timeout occurs on the very first token (Setup token of the "get device descriptor" control transfer) that's triggered by the "usb_dev_list_attach_device()" function, right after detecting the USB device speed.
Sequence: Key insert --> Interrupt(ISTAT.ATTACH) --> KHCI Attach call --> GetDeviceDescriptor --> Setup Token --> Bus Timeout
The GetDeviceDescriptor transfer is repeated 15 times.
In the USB-IF Command verifier tool, there is an enumeration test, which does 150 enumerations of the device. This test succeeds with the mentioned device... The enumeration of the device seems to be no problem on windows. One difference from windows USB to MQX USB is, that the windows stack sends as first transfer a get device descriptor with 64Bytes requested data, MQX requests 8Bytes. According to the spec. this makes no difference because the device must return the requested amount of data or - if the requested size is larger than the available data - the size of the requested descriptor.
This is what I know so far, maybe this information helps to get closer to where the problem lies...
Best regards,
Lukas