Oooh, That (USB) Smell
Being a programmer, a computer engineer, or an electrical engineer has one major challenge: You usually can't see what you are doing. If you build bridges or roads or car engines, you can see your design come to life. We have to rely on indirect evidence.
My lab is strewn with oscilloscopes, logic analyzers, and various other devices that try to be our microscope into the electronic world. I don't use my logic analyzers as often as I used to — everything is locked up on the microcontroller chips where I can't get to them. However, the proliferation of serial busses has made a particular type of logic analyzer — a protocol sniffer — very useful, if you have one.
A sniffer is just a colloquial word for a logic analyzer that knows how to eavesdrop on some kind of communication channel. That may involve some hardware and almost certainly requires some specialized decoding software. I have talked about logic analyzers that have capability like this a few times in the past. All of those require some kind of hardware connection.
Like everything else, though, a lot of sniffers are turning into nothing but software. That's handy, especially for data that is flowing on the PC already.
A case in point: sniffing USB traffic. You can get a hefty-priced hardware analyzer (which has certain benefits, I'll admit). Or you can use any number of software tools (including the ubiquitous WireShark).
I recently picked up an inexpensive device programmer on eBay called a Minipro TL866. It's just a small box with a 40-pin ZIF socket and a USB socket. It has a lot of features for such a small box — it will program EPROMs, EEPROMs, Atmel AVR CPUs, and Microchip PICs. It will even test logic family chips. Well, that is, it will if you can run the Windows software (see the figure below).
You may recall that I mostly use Linux. You can load the software under VirtualBox, so that's one answer. There's also a library that allows the Windows software to run under Wine. Those are both fine options, but the software has a few problems (notably, programming PIC ID words prevents the configuration words from being programmed). It also seems possible that you might want to add your own devices and that would not be simple with the closed source Windows software.
Naturally, there's an open source alternative. The developer, apparently, reverse engineered the protocol and developed a command-line interface to drive the programmer.
I expect the developer might be primarily an Atmel AVR user. There were a few minor issues with the PIC support. The beauty of open source, of course, is that I fixed the issues and contributed them back to the project.
There was one fix that wasn't so simple. The original code assumed that all PICs have a single configuration word. Many of the newer ones, however, have two. The original Windows software was able to handle the situation, so I knew the firmware in the box could handle it.
Since the Windows software could do the job, it seemed like a good job for a USB sniffing software. Turns out, the same developer that wrote the device programmer software also wrote a USB sniffer.
Armed with the Windows software running in VirtualBox and the USB sniffer, it was a simple matter to make the software write the PIC configuration words and capture the bus traffic.
lsusb command reveals the USB ID (04D8:E11C). Using the
usb_capture command reveals (in part):
BULK_OUT(0.1):13630200c83f00ff1fff3af622ff3f0fc00fe00f4000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 # 0.0018110275268555 BULK_OUT(0.1):12630200004000ff1fff3af622ff3f0fc00f # 0.0019600391387939 BULK_IN(0.1): 120202003e0202ff1fff3a # 0.0654678344726562
The 13 is a configuration word write (gleaned from the software's minipro.h file). The 12 corresponds to a configuration word read. I wrote 1FFF and 3AFF into the two words, so it was pretty simple to pick out the location of the data.
With that data, it was a relatively simple matter to figure out how to patch the existing software to send and receive the right packets. The hardest part was figuring out the entire list of PIC devices that take two configuration words.
Thanks to Github, my changes are incorporated in the original software. In a fit of boredom, I also wrote a simple script wrapper and a GUI wrapper (with Qt, see the figure below) to make it easier to use the software.
In and of itself, writing some device programmer software is no big deal. But the ability to sniff USB packets is a valuable tool to have in your bag of tricks. Next time, I'll show you some other viewing tools I have around the lab.