hi IPenguin thanks for clearing up the details.I think this kind of info can clear up/speed up a lot of testing time- i finally deduced what needed to be done. see pics in http://dangerousprototypes.com/forum/in ... pic=576.60
hopefully the picture is supportive of your test description
OSX, initial capture still fails with "Device not found." 2nd and continuing captures take place but an exception is raised: :SumpJavaClient$ java -d32 -jar analyzer.jar Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.usbmodemfd321 /dev/cu.usbmodemfd321 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem Device Controller found: org.sump.analyzer.devices.FpgaDeviceController /dev/tty.usbmodemfd321 /dev/cu.usbmodemfd321 /dev/tty.Bluetooth-PDA-Sync /dev/cu.Bluetooth-PDA-Sync /dev/tty.Bluetooth-Modem /dev/cu.Bluetooth-Modem Device Controller found: org.sump.analyzer.devices.Hp16500DeviceController Device Controller = FPGA Controller Tool found: org.sump.analyzer.tools.I2CProtocolAnalysis Tool found: org.sump.analyzer.tools.SPIProtocolAnalysis Tool found: org.sump.analyzer.tools.StateAnalysis Tool found: org.sump.analyzer.tools.UARTProtocolAnalysis Attaching to: /dev/tty.usbmodemfd321 (115200bps) initial run Run started Device ID: 0x1e0003f Run aborted java.io.IOException: Device not found. at org.sump.analyzer.devices.FpgaDevice.run(FpgaDevice.java:648) at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceController.java:546) at java.lang.Thread.run(Thread.java:637) Attaching to: /dev/tty.usbmodemfd321 (115200bps)
subsequent runs Run started Device ID: 0x534c4131 11000000 00000000 00000000 00000000 00000000 11000001 00000000 00000000 00000000 00000000 11000010 00000000 00000000 00000000 00001000 10000000 00000000 00000000 00000000 00000000 10000001 11111111 00000001 11111111 00000001 Flags: 10000000010 10000010 00000010 00000100 00000000 00000000 Run completed java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1175) at gnu.io.RXTXPort.removeEventListener(RXTXPort.java:814) at gnu.io.RXTXPort.close(RXTXPort.java:1039) at org.sump.analyzer.devices.FpgaDevice.detach(FpgaDevice.java:518) at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceController.java:559) at java.lang.Thread.run(Thread.java:637) Attaching to: /dev/tty.usbmodemfd321 (115200bps) Run started Device ID: 0x534c4131 11000000 00000000 00000000 00000000 00000000 11000001 00000000 00000000 00000000 00000000 11000010 00000000 00000000 00000000 00001000 10000000 00000000 00000000 00000000 00000000 10000001 11111111 00000001 11111111 00000001 Flags: 10000000010 10000010 00000010 00000100 00000000 00000000 Run completed java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1175) at gnu.io.RXTXPort.removeEventListener(RXTXPort.java:814) at gnu.io.RXTXPort.close(RXTXPort.java:1039) at org.sump.analyzer.devices.FpgaDevice.detach(FpgaDevice.java:518) at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceController.java:559) at java.lang.Thread.run(Thread.java:637)
@LukeS make sure you jumper PGC PDC (i.e short them out) or set the board into bootloader mode. At this point both ACT and PWR lights will be illuminated permenantly. the firmware update file then finds the board automatically, and you will see the trace of the firmware update in the command shell.
you should be able to run the client from the command line with:
java -jar analyser.jar ( note US spelling of analyzer.jar)
@all I successfully uploaded to firmware 4. In some cases the capture is successful in some the device is not found. It appears to be more problematic with device not found in OSX (10.6.3) than XPsp2
In OSx, I have to have the OLS plugged in before I start up the jar. This seems to be the main cause of my visible error. In some cases I have to reaffirm the port from the dropdown window even if it is the correct one displayed.
How does one effectively use this, I've just updated to firmware 3 and the latest test release, as a quick test i tried to use it but was unsuccessful?
OK heres the lowdown with my faulty board sans bootloader
had to look for some header pins to solder to the board,( always in the last place to find them) I uploaded the bootloader using pickit2, went smoothly no problems
I tried firmware 2 with with the latest bitstream following the procedures, everything went well trying the client, as others found an exception error was raised, since its sitting in the same filepath I'm surprised, I expect there is a hardcoded attribute in the jar thats throwing things off. Trying with th eoriginal client still generated 'device not found'. A bit confused by this?
I then tried firmware3 with the latest bitstream, this worked with the original client.
I then followed the same procedure to update the working board. This too was successful. i.e. running firmware 3, the device is found time after time.
In both cases I have not tried to connect the probes to a signal
For what its worth I tried the pump-loader.exe -status with the working board I get the same result. Boot: 255
So what we have here is a working pic, (in both board cases) and with code used to configure USB for loading the OLS already in place, this means that I cannot install new pic code without a plckit or similar, but I can continue to load bits for the fpga? or am I mistaken??? as so far I can run the ROM loader and I see a trace of some form or load/write taking place?
I have a pickit, I am happy to load the bootloader, other than allowing pic updates will it bring anything else to the table in this current investigation?
I added this to thread 549 concerning intermittent problems http://dangerousprototypes.com/forum/in ... opic=549.0 but it seems more appropriate here: I have two OLS, one works in the OSX or XP the other always fails with "device not found" I have tried the analyser.jar with the delay file from the 19th May as well as altering the advanced port settings, with no joy.
FYI, all LED appear to provide the correct feedback, making the assumption that all is good. It is recognised in the device manager ports, I can upload different bit streams to it, but as soon as i hit 'capture' the device not found' rears its ugly head.
I would now assume that this is not software based but hardware based issue we have here as one OLS functions faultlessly and the 2nd doesn't?
Using realterm as an interface, when sending "02H" I get feedback with the working OLS, the other OLS (that gives "device not found" with sump) offers me nothing (empty display)
