I have been negligent. Or, maybe it's that I've just been a little hesitant to give-away my edge. In any case, I've finally decided to come-clean and tell you about a product that's made my life easier and saved my sorry driver-writing ass more times than I care to count. That product is the Ellisys USB Explorer 200, USB protocol analyzer.
Oh, I hear you now: "Sure, some freakin' guy from OSR loves his freakin' USB analyzer. Of course he freakin' does. They have a lot of freakin' money at OSR to spend on freakin' stuff like that. There's no freakin' way my freakin' boss is going to spend tons of freakin' money on a freakin' USB analyzer, no matter how much I beg and whine and kiss his ugly ass." (You can see that I imagine you, dear reader, in nothing but the most erudite of terms).
But STFU and listen to me for a minute. The tool I'm talking about costs less than US$3K. If you work on USB stuff, tell your boss you'll wait until next year for a new development system. Tell him to check out one of these things instead, because it'll save you and the company a lot of time and annoyance in the long run.
About USB Traffic Analysis
In the world of USB decoding, you've traditionally had two options:
1) Use a software-based decoder -- These decoders are either free or inexpensive (good ones can be purchased for about US$200). They insert a filter driver into the USB stack and decode USB packets as they go by.
2) Spend a ton of money and buy a hardware USB analyzer.
The advantage of using any decoder/analyzer is that it gives you an independent view of the message traffic. By having a "third party" outside your driver decode and interpret the packets that you're sending and receiving, it becomes clear, pretty quickly, when you're getting or sending malformed messages.
How does this work, exactly? Well, I'll give you an example. Just the other day, I was attempting to retrieve a string descriptor from my device. The "Get Descriptor" command I was issuing was not failing, but the return values I was getting were odd, short, and looked (in the debugger) like nothing but an "O".
Now, I could have gone back and stepped through my driver code to find the problem. But, instead, I had my USB analyzer hooked-up. The analyzer display told me that I was sending a "Get Descriptor" for "String Language IDs". Well, that's certainly not what I had intended. And, sure enough, I discovered that I wasn't building the "Get Descriptor" command properly in my code, and was sending zero as the desired string index. A quick check of my code revealed the error of my ways, and after a one-line change my bug was fixed and all was right with the world. Well, at least as far as retrieving this one string descriptor was concerned.
This wasn't exactly a tough problem to analyze and, as I said, in this case I could have relatively easily found the bug by examining my driver code. But finding and fixing the bug was faster, easier, and more pleasant with the use of the analyzer.
Also in this case, either a software-based decoder or a hardware-based analyzer would have helped me find the problem equally quickly. Software-based decoders clearly have their place. That place is to monitor and display packets between a client driver and the USB controller driver.
However, the ability to show the actual traffic on the USB bus, the way the controller sends it and sees it arrive, is what makes the hardware-based analyzer the gold standard. Whereas in a software-based decoder you're only going to see packets that are exchanged between the USB controller driver and its client(s), a hardware-based analyzer gives you a window into the traffic between a device and the USB controller, the overall bus traffic, and even device performance. In short, for the greatest amount of flexibility and usefulness, most developers agree that there's nothing like a hardware analyzer.
Why Doesn't Everyone Use A Hardware Analyzer?
Until recently, when it came to hardware-based analyzers just about the only game in town were the bus analyzers (for USB and just about every other kind of bus) made by CATC. CATC has actually been owned by LeCroy for a few years now. You see their USB analyzers everywhere. They are excellent. If you've ever seen a multi-colored USB protocol trace, you've seen the output from a CATC analyzer (an example is shown in Figure 1).
The only disadvantage to the CATC analyzers that I'm aware of is that they are expensive (over US$13K, according to the last quote I got, which is admittedly a few years old). This leads most devs to rule-out the possibility of using a hardware-based analyzer for their USB development work. It just plain costs too much money, and it's not worth it to the boss.
When we were searching for a USB bus analyzer a few years back here at OSR, just about everyone we talked told us to get a CATC. Then we discovered, almost by accident, a Swiss company named Ellisys. They make several models of hardware-based USB analyzers. When we discovered the reasonable price of these analyzers, we bought one!
The analyzer we bought is the Ellisys USB Explorer 200, which supports USB low speed, full speed, and high speed. The analyzer box is about 6x5x3 inches (small enough to carry on the plane). You connect this box to the USB bus that you want to monitor, between the computer on which the host controller is running and the device(s) that you want to watch. The analyzer uses a separate USB connection to send the collected data to a second machine, where it is collected by a custom driver and analyzed/displayed by the Ellisys Visual USB software application. You can use your development machine or laptop to run the collection/analysis software (I've done both). The latest version of the software is available (without additional upgrade fees for the latest version) for download from the Ellisys web site. Yes, they have an x64 driver.
An example of the analyzer output is shown in Figure 2.
There are many options that allow you to filter and adjust the output to suit your project and preferences. In the display shown in Figure 2, you can see that the bus states are shown, complete with their timings, including the high-speed detection chirp/handshake. I've also chosen to "drill into" the transactions that are part of the first "Get Descriptor" request to see why it appears to be invalid. The payload for each individual packet can be shown, as well as a decoded display of the packet's meaning. The display on the right goes even further, interpreting the packet information and the fields in each packet.
After using this analyzer for more than three years, off and on, I recommend it highly. One thing I really like about it is (unlike some similarly specialized devices) even when I don't touch it or do USB-related work for several months, it's never hard for me to figure out how to get back to doing useful things with the analyzer. It's just that simple to use.
No t A Commercial
I didn't intend to author a commercial for the Ellysis USB Explorer 200 hardware-based analyzer. Rather, I wanted to make you aware of the fact that a hardware-based USB analyzer doesn't have to cost a gazillion dollars. In fact, if it cost what other hardware-based analyzers cost, then Dan would have complained to our General Manager that, "Engineering is spending all the capital equipment money again, and I can't buy [some stupid marketing thing or a license for some expensive graphics layout program]", and I wouldn't have been able to buy it. And I'd be stuck wondering why the prototype USB FX2 board was broken.
So, that's the secret that I've been keeping from you for these many years. The secret to my USB success. For less than the cost of a decent dev machine, you can get one of these suckers and save yourself a lot of time and annoyance. You won't be sorry.