0
\$\begingroup\$

I have captured USB traffic between host and device operating at Full Speed. Then I am filtering on an Interrupt endpoint. bInterval value is 9 for this endpoint. In the capture I am seeing IN token from host to device on this endpoint every 35 msec.

Based on my readings I was thinking, considering Full Speed operation, the host will send the IN tokens every 9 millisecond. Why am I seeing a 35 second delay between each IN packets?

\$\endgroup\$
  • \$\begingroup\$ How are you capturing traffic? A hardware protocol analyzer (like a physical device gathering the traffic) or software (such as WireShark)? \$\endgroup\$ – Los Frijoles Apr 13 '17 at 4:38
  • \$\begingroup\$ I am using Teledyne Lecroy USB protocol analyzer \$\endgroup\$ – mathedi Apr 13 '17 at 7:36
1
\$\begingroup\$

First issue: IN transactions go device to host, not host to device. The host polls for them, certainly, but the transaction results in data going in to the host. Though I guess the token itself actually does go "host to device"...but anyway.

Now, my guess as to why you might not see a token every 9 milliseconds: The device might not have data ready and has NAK'd the request. This not unrecoverable and the host will simply poll again after bInterval, but data is not received. That is probably why you are only seeing an IN token every 35ms: The device only has data ready to send every 35ms (as for an idea why your analyzer might not be showing you the NAK'd IN tokens, stay tuned). The bInterval setting gives it the opportunity to send data every 9ms, but it is not obligated to do so. This provides the "guaranteed latency" feature of INTERRUPT endpoints.

NAKing like this is completely normal and in fact, many devices will continuously NAK the request until something actually happens (especially in the case of HID).

Now for a bit of speculation: If you are using a software protocol analyzer, it will probably only capture completed transactions which would mean that your IN tokens would only show up once the device actually sends data. You likely won't be able to see the NAKs, unless it has interfaced fairly deeply with the host USB controller or at least the dark underbelly of the OS. A hardware protocol analyzer (such as a TotalPhase Beagle or one of those Teledyne LeCroy Voyager/Mercury/Advisor devices) would probably show you NAKs, so if you are using one of those perhaps you can configure it to show them to you to verify that the device is actually NAKing every 3 or 4 pollings?

Now, if you actually are seeing NAK'd IN tokens and they only occur every 35ms then I'm completely wrong. You should see a NAK every 9ms (on a hardware analyzer) if my guess above is correct.

\$\endgroup\$
  • \$\begingroup\$ I am using Teledyne Lecroy USB protocol analyzer. I am seeing the IN token (host -> device) every 35 milliseconds. Device is immediately NAKing these IN token. I see the NAK response from device in around 4 micro seconds. So what could be the problem here? An issue with the Host controller driver? \$\endgroup\$ – mathedi Apr 13 '17 at 7:37
0
\$\begingroup\$

The USB specification says (§ 5.7.4):

An endpoint for an interrupt pipe specifies its desired bus access period. A full-speed endpoint can specify a desired period from 1 ms to 255 ms. […] The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period defined by the USB (125 µ s microframe or 1 ms frame). The client software and device can depend only on the fact that the host will ensure that the time duration between two transaction attempts with the endpoint will be no longer than the desired period.

So the actual interval could be smaller than 9 ms, but should not be larger.

(In practice, most host controller drivers will round it down to a power of two, i.e., 8 ms.)

However:

Note that errors on the bus can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed the desired period. Also, the endpoint is only polled when the software client has an IRP for an interrupt transfer pending. If the bus time for performing an interrupt transfer arrives and there is no IRP pending, the endpoint will not be given an opportunity to transfer data at that time. Once an IRP is available, its data will be transferred at the next allocated period.

("IRP" means "I/O request packet", and is a software structure that the driver uses to ask for data.)

So either your host controller driver does not handle this interval correctly, or the driver for this device does not actually ask for new data. In any case, the device is doing nothing wrong; this is entirely caused by software on the host.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.