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 ....
Is there a problem with just device metadata or there is also a problem regarding the waveform capture?
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.)
Yeah, firmware update was what I was going to suggest. It ships with old firmware as that's included in the manufacturing package Seeed received. There was no HW revisions so they are still using the old manufacturing package.
Can you access that serial port as a normal user by using a serial terminal program like screen? There is probably a permission problem, had a similar thing when I got a new 64-bit laptop.
Good question, I'll try picocom right now. Just for the record, I see this:
ls -l /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 0 Jul 6 15:58 /dev/ttyACM0
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.
Oh, and by the way, hi Tayken!
Thanks for taking the time to respond and help.
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 ...
No problem! :)
Hmm, what I understand is there is a problem with not the hardware but only software? Maybe Jawi can look into it. I was going to suggest checking out pins for the wrong signal status thingy but you mentioned that the trigger works for them so HW should be OK.
Can you post the segfault error message here?
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:
[tom@trona fw_update]$ ./fw_update -vid 0x4d8 -pid 0xfc90 -version
fw_update Version: 0.2.0
U2IO BootLoader Version reading: FAILED.
Segmentation fault (core dumped)
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.
@TucsonTom: what you describe in your OP is a known issue in version 0.9.6 of my client. It should be fixed in the upcoming 0.9.7 release. If you like, you can give the first RC (http://http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=5693) a spin to verify this...