Cached USB frame (?!)

One variants of our USB 1.1 device is “dumb” one, no firmware, just pure hardware. It is fully controlled from host and host is responsible for all data processing (instead of “smart” variant where everything is done in firmware). Host sends a command via control channel which tells device to start data transfer. Device genarates data at constant rate (~850 kB/s) and host reads them using bulk endpoint. When it decides there is enough data, it sends another command and device stops generating data. Part of data can be lost with no problem but it is important to know which part. For this purpose there is 14-bit counter in every 64 byte frame. The counter is zeroed when “start” command is received so the first data frame should always have counter 0.

Everything works as expected if device is directly connected to computer. When there is an USB 2.0 hub is involved, strange thing occurs sometimes. To be quite clear, setup is following: USB 1.1 device <-> USB 2.0 hub <-> USB 2.0 HC. More hubs in chain increase probability of problem:

  1. Host sends “start” command and device generates frames 0, 1, 2…, X - 1, X
  2. Host sends “stop” command. The last received frame is X - 1.
  3. Some time later host sends “start” command again.
  4. The first frame received is X and the next is 0.

The X frame is clearly from previous run; I verified it using USB analyser connected between device and hub. Frame X is received via hub during the first run and the first frame sent by device after #3 is 0. It seems as hub caches frame X and when host later asks for bulk frame, cached frame is retrieved. I don’t know if it is even possible and unfortunatelly can’t verify it because have only USB 1.1 analyser which sees nothing when connected between hub and HC (I told my mingy chief we may need 2.0 but 1.1 was so cheaper… :).

It is clear the frame is cached somewhere. I don’t think HC or OS does it because problem can be reproduced only with hub. Also, I verified there is no pending IRP; I used command line app which starts device, processes data, stops device and exits (so all pending IRPs are cancelled). The driver is mine and it doesn’t send bulk URBs on its own; only if app requests.

I tried to wait 5 minutes between #2 and #3 and problem still occurs. It is rather easy to fix (was not so easy to find :), just read bulk endpoint before starting device to flush pending data. However, I’d really like to know where is this rogue frame coming from. Can anybody explain it? Thanks.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]