I am digging deeper into the trouble with the fw_update utility now. I cloned the git repository and built it from source, and am now studying the PIC updater source. What I see is:
BUT, I see that I am running this as myself (tom), when I run it as root, I get: ./fw_update -vid 0x4d8 -pid 0xfc90 -version fw_update Version: 0.2.0 U2IO BootLoader Version reading: DONE.
Which doesn't tell me much about the BootLoader Version, but at least no segfault. I'll be back later, thanks.
A quick update on the last report. I made a mistake on the jumper, fixed now and indeed the device identifies as 04d8/fc90 now with PGC and PGD connected together. The fw_update utility still segfaults when I try "./fw_update -version" though ...
This is thanks to the udev rules I added, and this should allow anybody (like me) full access to the device.
And indeed, typing "picocom /dev/ttyACM0" connects me to the port without errors as myself (user tom). I change the baudrate to 115200 and type random things, but don't know the protocol so don't really know how to check things out further.
And I am on to other adventures. My device keeps identifying as 04d8/fc92 even after I do the setup/reset thing. And I just installed a jumper to short PGC and PGD, which is recommended in some upgrade instructions I am following -- and it is still 04d8/fc92 and not 04d8/fc90 as I am told it should be. This is an obstacle as far as I know. The fw_update utility, which I am experimenting with from the command line just segfaults. Oddly enough though the LED pattern with the jumper on is PWR and ACT lights on both solid, the other two lights off.
I am working with it right now. I found another post where someone said that the lack of device metadata indicated that there was old firmware, so I used the ols-0308.tgz bundle to do a firmware upgrade, and after that the "show metadata" button is working!
This is progress of a sort, but surprising that a recently purchased device would ship with old firmware (I never did see a display of what the old firmware version was, and I guess it is gone now). So now I am repeating my tests with the new firmware and I still have the Java problems and must run as root. And the problem with improper signal inversion that I mentioned in another post still remains (two signals I know are 5 volt high are displaying as low, although a low to high trigger works with them.)
I am running Fedora Linux (Fedora 18, currently a 3.9.6 kernel on a x86_64 system). I am running Java 1.7.0_25. What I am seeing is that I cannot run the client as myself (user tom), but it seems to run fine when I run it as root.
I changed permissions on /dev/ttyACM0, first by hand, and then by putting this file in place as /etc/udev/rules.d/51-ols.rules ---
# 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", NV{ID_MM_DEVICE_IGNORE}="1"
Even as root though, the button to "Show device metadata" does absolutely nothing.
And as myself, I get:
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) ... ... and much more ....
I am two days into fiddling with the logic sniffer v 1.04 that I got earlier this week. I am using Jawi's 0.9.6.1 client under linux (Fedora 18, a 3.9.6 kernel). I am looking at signals from an old MC68010 cpu board. In particular, I am monitoring HALT* and RESET* (both are active low), and I set up a trigger on reset to do a capture when reset transitions from low to high (and this works perfectly). What is truly odd is that the capture shows both of these signals transitioning from high to low, which is exactly wrong. A meter shows RESET* as 5.0 volts when the CPU is running, which is as it should be, but the sniffer shows this signal as a low. The fact that the trigger worked properly is certainly in conflict with what I see on the display. Anybody ever seen anything like this?
This certainly looks wrong (that the logic sniffer gets identified as a FTDI rs232 device). Well, it is wrong actually. This looks like an old linux kernel. What kernel is/was this? My bet is that upgrading to something more recent will straighten things out unless your udev setup has been strangely customized. It is odd that the vendor and device id stuff is not getting displayed, which is what I see with my setup (Fedora 18 with a 3.9.6 kernel). My logic sniffer gets set up as ttyACM0.
And yes I see this is a several month old post (that nobody answered?), but I just joined the forum today.
