0
\$\begingroup\$

I have a device (USB CDC) class that is connected to a host PC via USB. On this device there's a request-response task implemented, meaning I get a message, do some stuff and when I'm done I send a response. The problem I have is that it takes, from the host perspective, too long until I get a response to a certain request. My suspicion is that probably the polling of the USB input buffer on the host PC is too slow and therefore causes this delay. But to rule out a problem on my USB device, I thought I can hook up a scope to my data line (D+) and measure the time between the incoming and the outgoing message. Unfortunately there's a lot going on on this line even though no data is transmitted.

  1. Is there some idle communication on the USB line?
  2. Is there a way to distinguish this idle data from real data? Or is there a better way than measuring the data line?

Update
I took a capture (at least I think I did) where the two PPP Unknown messages contain my data. Is this proof that the response time 55.624225 vs 55.625272 is less than 1ms?

enter image description here

As a consequence, this would mean that it's indeed the host application that cannot poll the USB Input Buffer fast enough?

\$\endgroup\$
4
  • \$\begingroup\$ What is your expectation regarding response time? How big are the requests and responses? USB polls a device once every millisecond to ask if it has data to transmit. So in addition to the time taken for transmitting the request and response you will also need to consider the time between polling, i.e 0.5ms on overage, 1ms max. \$\endgroup\$
    – Codo
    Feb 1, 2021 at 14:08
  • \$\begingroup\$ I receive 1 Byte and I send 1 Byte, the processing is a bit of pointer manipulation, but on the host it takes more than 100ms between sending and receiving. \$\endgroup\$
    – po.pe
    Feb 1, 2021 at 14:11
  • \$\begingroup\$ That's excessively long and is worth an investigation. \$\endgroup\$
    – Codo
    Feb 1, 2021 at 14:32
  • \$\begingroup\$ updated the question with a screenshot from wireshark \$\endgroup\$
    – po.pe
    Feb 1, 2021 at 15:06

2 Answers 2

2
\$\begingroup\$

There is comms happening all the time over USB, StartOfFrames if nothing else.

The best way to see what's going on is to use a protocol analyser such as a USB Beagle from Total Phase (I have no affiliation, but own, use and am happy with their tools).

Wireshark can be used and there are various other software tools which can do USB packet capture, but I find none work quite as well as a hardware tool.

\$\endgroup\$
7
  • \$\begingroup\$ Unfortunately I don't have one at hand... \$\endgroup\$
    – po.pe
    Feb 1, 2021 at 13:54
  • 1
    \$\begingroup\$ It'd be worth trying the software option possibly, you might be able to get the information you need from Wireshark. \$\endgroup\$
    – Colin
    Feb 1, 2021 at 13:55
  • \$\begingroup\$ I'll give it a try \$\endgroup\$
    – po.pe
    Feb 1, 2021 at 14:08
  • 1
    \$\begingroup\$ @ChrisStratton I still stand by my statement that the best way to see what's going on is with a protocol analyser, and none of the software I've tried is as good. \$\endgroup\$
    – Colin
    Feb 1, 2021 at 15:59
  • 2
    \$\begingroup\$ @ChrisStratton In my defence there, the question didn't have software results until my answer suggested using wireshark. \$\endgroup\$
    – Colin
    Feb 1, 2021 at 16:01
0
\$\begingroup\$

Your screen shot shows a bulk in request issued, to which the device does not respond for almost 3 seconds.

That indicates that the problem is in the device (or more likely, a mistaken in the expectation that it should respond promptly), and not in the USB host stack.

\$\endgroup\$
2
  • \$\begingroup\$ Not sure if I understand, the data contained in the two marked messages is what I expect to be sent and received. I don't know what these bulk requests are... \$\endgroup\$
    – po.pe
    Feb 1, 2021 at 16:05
  • \$\begingroup\$ The bulk messages are the interesting part. Whatever the "PPP unknown" is, it's write-only so not where you'd be looking for a device response. You could try to decode it further or disable PPP interpretation (is your device even implementing a PPP channel, or is irrelevant?) and just look at the underlying USB. You want to look at the places where there's time elapsed, and at least in the capture you've shown, the only place that happens is between the bulk in request and response. If you're sure that's not it, perhaps you need a different capture to show the interesting behavior. \$\endgroup\$ Feb 1, 2021 at 16:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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