Ports and Interfaces > USB

Error writing HID device

(1/5) > >>

Jan Andersson:
Hello folks! (Another Jan here!  ;) )

I have a problem similar to the one discussed here: http://www.lvr.com/forum/index.php?topic=96.0

The main difference is that I am unable to reproduce the error myself. In fact the PC application seems rock steady in communicating with the embedded HID device, while a few customers have reported that they are completely unable to make it work. I have tested it on a number of PCs, low-, middle- and high ends, Win XP and Win 7. Still just works fine.

The PC application does a number of things, the ones which only read or write a small number of 64 bytes packets work, while the one which writes 300kByte to the device fails the write with error code 31, sometimes immediately, sometimes after a couple of seconds.

So what I would very much like is some suggestion how to proceed when the debugging seem to have to be done "remotely"? I have read that if the device fails ACK/NACK within reasonable time it could give errors like this, but the "load" of the device should be the same when I use it as when the ones getting the error are using it.

Jan Axelson:
Hi Jan,

If it's a low- or full-speed device, you should test with different host controllers (OHCI, UHCI) and with hubs.

The fact that the failure is on long transfers suggests that perhaps the endpoints sometimes fail to NAK when busy with the previous transaction's data. After receiving data, an OUT endpoint should immediately begin to NAK any new data from the host until the endpoint buffer can accept new data. How to manage the endpoints varies with the device hardware.

Jan

Jan Andersson:
Thanks for a quick reply!


--- Quote from: Jan Axelson on February 09, 2011, 12:26:36 pm ---Hi Jan,

If it's a low- or full-speed device, you should test with different host controllers (OHCI, UHCI) and with hubs.
--- End quote ---
Hmm... Good idea! But how to do that? I guess different PCs have different host controllers?


--- Quote from: Jan Axelson on February 09, 2011, 12:26:36 pm ---The fact that the failure is on long transfers suggests that perhaps the endpoints sometimes fail to NAK when busy with the previous transaction's data. After receiving data, an OUT endpoint should immediately begin to NAK any new data from the host until the endpoint buffer can accept new data. How to manage the endpoints varies with the device hardware.

Jan

--- End quote ---
Sounds reasonable! But what could cause this to happen for specific PCs only? Today I got a report that two laptops got this error. Is it possible laptops handle USB different in general?

mdlayt:

--- Quote ---Is it possible laptops handle USB different in general?
--- End quote ---

Yes, but the variable is not laptop versus desktop.

The variable is, when some component is different, then it might act differently.  In this case, the most relevant components are, the host controller (ie root hub), the driver code, the app code, and any hubs you may have in the system.

That is why you need to look in your device manager to figure out if there is a specific set of host controllers (ie chips on your motherboard for USB) that do or don't work.  Eg in my device manager I see I have an "Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller."

Ron Hemphill:
In your 2nd post you implied, but did not really answer whether your device is FS or LS.  Assuming it is, one thing you might try is to ask your customer to try putting a high-speed (USB 2.0) hub between the device and the PC/laptop.  The hub will then handle transactions to/from the host in high-speed and translate them to FS or LS for the device.  Also, if you're using a hub on your test system, remove it and connect the device directly to a root port (but be aware that some PCs use on-board hubs to distribute USB ports; make sure you're on an actual root port).

Navigation

[0] Message Index

[#] Next page