USB "error frame"

[Burns]

Hello
I’m using a TI Stellaris controller and sending with the generic_hid tool in “Control Transfers Only” mode continues data. (Thanks for this great example implementation).
When I’m connecting/disconnecting another device at the same USB hub the controller receives wrong data. It looks for me a little like an error frame.

[receive buffer index] = value
[ 0]= 33
[1]= 9
[2]= 0
[3]= 2
[4]= 0
[5]= 0
[6]= 64
[7]= 0
Followed by valid data (but with an offset of 8 byte] for example:
[8]= 6
[9]= 134
[10..63] =0

The last valid frame is:
[ 0]= 4
[1]= 132
[2..63] =0

So one frame is completely lost ([ 0]=5; [1]=133) and one has this “error frame”
Im not very familiar with USB. Is this really an error frame or a bug in my firmware? How is this handled usually?

-Burns

[Jan Axelson]

Detaching a device should have no effect on other device communications.

A hardware protocol analyzer will show what is happening on the bus and will help isolate the problem.

If you don't have an analyzer, use a monitor program, watch variables, or whatever debugging tools you have to find out what the device has received and what it is sending.

Jan

[Barry Twycross]

I've known at least one hub which would corrupt traffic on an adjacent port when a device was unplugged. Its not unknown that unplugging a device can cause issues on another port.

[Jan Axelson]

Oh boy. Well, I did say "SHOULD have no effect".

Thanks, Barry.

Jan

[Burns]

Thanks for your reply,
you a right it is only a problem with on special USB hub. I tried different PCs and USB hubs but only this on causes the problem. I’m wondering why other USB devices work with this HUB. I would expect for example corrupted files on a USB stick. But this doesn’t happen.

Burns

[Jan Axelson]

Maybe the problem is only with control transfers.

Jan

[Barry Twycross]

When we noticed the problem with the hub, it was because an attached device was not behaving to spec. The problem with the hub caused a packet to get corrupted. As the packet was corrupted, the packet was not ACKed. The host retried the packet and the device in question responded with a zero length packet. That is an error on the device part, the correct response to a retry is to resend the packet which has not been acked. The device's failure to follow the spec then caused other issues that caused the problem to be noticed (a file copy hung).

USB should be able to cope with corrupted packets on the bus, its when devices don't follow the spec with regards to recovery from the errors that things get "interesting".

So is your device behaving correctly to spec in the face of unexpected errors?

I would note that we've had other devices which would occasionally corrupt a packet, but as error recovery was properly followed, this never resulted in a symptom the user would notice. We only noticed it by looking at bus traces. We've sold millions of such devices and I'm not aware of any user complaints caused by the behaviour.