Open Logic Sniffer (OLS) - my experiences

7-7-2013

My unit arrived on July 2, 2013 after about a 2 week wait after ordering. I think this is pretty good for an item shipping out of China. I paid $50 for the unit, and also purchased 2 sets of 8 channel probe cables to go with it (so I can attach to 16 channels).

This page is a "play by play" record of some of my experiences learning about my unit and trying to make it useful.

First steps

When I plug it in to my Linux (Fedora 18 x86_64) system , I get: 
Jul  2 18:29:10 trona kernel: [80840.584502] usb 1-1.4: new full-speed USB device number 4 using ehci-pci
Jul  2 18:29:10 trona kernel: [80840.673540] usb 1-1.4: New USB device found, idVendor=04d8, idProduct=fc92
Jul  2 18:29:10 trona kernel: [80840.673545] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul  2 18:29:10 trona kernel: [80840.673548] usb 1-1.4: Product: Logic Sniffer CDC-232
Jul  2 18:29:10 trona kernel: [80840.673550] usb 1-1.4: Manufacturer: Microchip Technology Inc.
Jul  2 18:29:10 trona mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4"
Jul  2 18:29:10 trona mtp-probe: bus: 1, device: 4 was not an MTP device
Jul  2 18:29:10 trona kernel: [80840.712230] cdc_acm 1-1.4:1.0: This device cannot do calls on its own. It is not a modem.
Jul  2 18:29:10 trona kernel: [80840.712254] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
Jul  2 18:29:10 trona kernel: [80840.712694] usbcore: registered new interface driver cdc_acm
Jul  2 18:29:10 trona kernel: [80840.712698] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
This is encouraging - it is not DOA and linux recognizes it and sets it up as a ttyACM0 serial device.

On my system "javac -version" gives me: 

javac 1.7.0_25
Simply typing "java" shows that I am running Oracle java (which is probably related to fact I have recently been doing Android development on this machine and may not be the "normal" situation with Fedora 18.

I can start the OLS "jawi" client just fine, but when I try to do anything, I get the following (as the start of a long traceback: 

java.lang.IllegalStateException: JTermios call returned -1 at class jtermios.JTermios$JTermiosLogging line 489
at purejavacomm.PureJavaSerialPort.checkReturnCode(PureJavaSerialPort.java:908)
at purejavacomm.PureJavaSerialPort.setSerialPortParams(PureJavaSerialPort.java:478)
at purejavacomm.PureJavaSerialPort.(PureJavaSerialPort.java:722)
at purejavacomm.CommPortIdentifier.open(CommPortIdentifier.java:138)
The above looks like permission issues with /dev/ttyACM0. This is one of the reasons I hate Java -- the end user should not be seeing some cryptic mess like this. Proper software would emit something like "dev/ttyACM0 - permission denied". An experienced eye like mine can squint and make a general guess at what is wrong, but I pity a true end user. It works fine when run as root, which pretty much confirms my theory; however the button to "show device metadata" does nothing.

There are some hints on the wiki. The first one aims to produce a symbolic link via a udev rule file like so: 

#File /etc/udev/rules.d/ols.rules
#Rules for Openbench Logix Snifferslogic. Creates a nice link to the ols
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OpenLogicSniffer"
I don't feel any urge to produce a symbolic link, but I think the MODE="0666" line would be just the thing.

Another tip is a trick to tell modem-manager (a package I just summarily delete) to ignore the device by adding the following line to the udev file: 

ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", ENV{ID_MM_DEVICE_IGNORE}="1"

What I actually used was a file named /etc/udev/rules.d/51-ols.rules as follows: 

# UDEV Rules for OLS logic sniffer
# The game here is to get permissions we might like,
# and to tell modem-manager to drop dead.
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"
This produces the permissions I like, but I still get the nasty traceback when I run as a non-root user. I am running a 3.9.6 kernel (as of 7-2-2013), and there are some reports of problems with newer (3.6 or later) linux kernels and the Java serial libraries. This is like deja vu with java and Arduino development where there were endless troubles with the java serial libraries - yes I hate java.

Do the firmware upgrade

Reading some forum posts, I discover that the fact that the "show device metadata" button does nothing is symptomatic of my device having old firmware.

I download the file ols-0308.tgz and unbundle it. I ignore all the java stuff as well as the obsolete version of the client. I untar this, cd to /ols-0308/OLS_Upgrader and run ./ols-upgrader.sh. I must do this as root. I cross my fingers and let it do the firmware upgrade. After doing it, the client button to "show device metadata" now does something! In particular, it now shows: 

Open Logic Sniffer v1.0.1
Firmware 3.0.7
Protocol 2
Well, that is something I guess (even though the silkscreen on my unit says v1.0.4), and progress (sort of, I guess). I find it rather disgusting that a unit shipping in June of 2013 does not have firmware that was in distribution back in 2011, but what do you expect for a $50 gadget shipping out of China?

The next thing I do is to use git to fetch the latest versions of the updating tools for linux: 

git clone https://github.com/GadgetFactory/OpenBench-Logic-Sniffer

After doing this, I rebuild the fw_update utility using 

sh ./configure
make
But when I run it as ./fw_update -version it seg faults. There are 3 things wrong at least (but no decent software should segfault under any conditions).

When I hold down the "update" button on my unit, then press reset, I see the LED's doing what they should (the "ARM" led goes out and the "act" and "pwr" leds are lit once the "act" LED comes on). However when I run lsusb, I see that linux still thinks the device is 04d8:fc92 -- it should have transitioned to 04d8:fc90 when it is in boot loader mode.

The instructions now are to unplug the unit, connect (jumper together) PGC and PGD and then it should be 04d8:fc90 when it gets plugged in again.
I try this -- I solder a two pin header at this location and install a shorting plug, this indeed does the trick. After doing this "lsusb" shows 04d8:fc90, and the PWR and ACT led come on solid as soon as I plug it in. Running the updater with proper arguments I get: 

./fw_update -vid 0x4d8 -pid 0xfc90 -version
fw_update Version: 0.2.0.tjt
U2IO BootLoader Version reading: DONE.
BootLoader Version: 0.2.2
This is better than segfaulting, but only slightly. I added my initials to the fw_update version number, since I am hacking on the program. And although I was not getting a bootloader version at first, after unplugging and replugging the USB device, I am now getting the 0.2.2 version number.

To read out what is in the PIC, do one of the following: 

./fw_update -vid 0x4d8 -pid 0xfc90 -r -ob dump.bin
./fw_update -vid 0x4d8 -pid 0xfc90 -r -ox dump.hex
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org