We have been battling issues with USB memory stick support for some time with the i.MX28 Windows CE BSP. We have implemented a number of 'fixes' ranging from Microsoft updates, Errata Work-arounds and general Windows CE fixes from other BSPs or user experiences found online and in these forums.
We have an issue where after several insertions of a memory stick the USB port appears to lock up and on the next device attachment the 'AttachDevice' process fails at DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST. This is actually the first point in the attach process that an attempt is made to communicate with the device and uses ENPOINT 0 on a control pipe created during earlier stages of the AttachProcess.
Once the port has failed it no longer responds to any other USB device and fails at this same point every time. The pipe has the halt flag set and is non-functional. The only way to recover seems to be to power cycle the unit.
We have found forum posts that recommend increasing the delay from ResetAndEnablePort (the previous step) and sending any data. By default in the BSP this is 10ms but some devices may not be ready to communicate at this point and still coming out of reset. We have tried increasing to 100ms and the results initially seemed promising but we could eventually get it to fail again after repeated insertions.
We have used a USB logger to see what happens on the bus through several insertions to failure. For each successful attach and detach we see no bus errors and can decode the SCSI packets. The last successful transfer on removal was the last SCSI Test Unit Ready packet which is sent to poll for disk removal.
When we insert the disk and there is a failure we just see babbled data out of the USB port. There isn't a single valid packet but random data bytes being received by the analyser following device reset. The analyser cannot tell if the memory stick is babbling or the i.MX28 processor as it is just receiving random bytes constantly.
I have attached the last successful transfer below (note that NAKs and SOF are hidden). The memory stick was unplugged in the middle of this screenshot which is why the analyser detected suspend (no bus activity). The Reset following the suspend is when the stick was re-inserted. You can see that following this we just have babbled data. The bytes are random values.
On a successful remove / attach we see that after the suspend there are two resets and we have the initial 'get descriptor test' followed by the address set and the rest of the successful enumeration.
I have been adding debug messages at various points to try and figure out what could be going on. I am not sure why the USB port has the random data on it. Perhaps there is a corrupt qHead/qTD that is just running through memory sending out random data bytes but the data is not in any of the proper transfer types (SETUP/IN/OUT).
The transfer queue should be torn down on removal and cleared out and then recreated on the first transfer on attach.
Has anyone seen anything similar or could offer some debugging advice?
Thank you in advance, Mark