Dangerous Prototypes

Other projects => Open Bench Logic Sniffer => Topic started by: jack.gassett on May 26, 2010, 12:18:06 am

Title: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 12:18:06 am
EDIT by ian: Please see the test upgrade guide (http://http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed) for further instructions, and to test for the bootloader.

Here's a list of the most recent releases (http://http://dangerousprototypes.com/forum/index.php?topic=580.0), the files attached to these posts are old.

Ok,

We have two new test releases ready, both of them use SPI mode and will require an update of the PIC firmware and the FPGA-ROM. For those without a bootloader we will need to figure out how to get bootloaders installed before these test releases can be used.

Test Release 2.03 takes the standard 32bit4kinside bitstream and replaces the UART communications between the PIC and the FPGA with SPI communications. It speeds things up and will hopefully eliminate the communication issues people have been seeing. Please note that we have not really made any attempts yet to make it fast but you should see a speed increase, it will probably be much faster when we tune it.

Test Release 2.04 still uses the SPI mode but adds some goodies and a new version of the Java client. The Java client has an option to select the inside or outside numbering scheme and it also adds a test mode. If a ribbon cable is connected between the two headers and test mode is selected a test pattern can be captured. There is also a first attempt at enabling multiple memory configurations. If channel group 2 and 3 is disabled then 8k of memory depth should be available. If all channel groups are enabled then 4k of memory depth is available.

Please note that I have not done much testing at all with these releases and I'm hoping for help finding any issues.

Jack.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 12:19:09 am
2.04

EDIT by ian:
There's an overview of the upgrade process here:
http://dangerousprototypes.com/2010/05/ ... ers-needed (http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed)

I attached a second download to this post that includes another update to the firmware (new USB descriptor that might help with hub problems). It also includes the bootloader firmware for testers who don't have the bootloader installed, but do have a PIC programmer.

If you don’t have a bootloader, we are working on several ways to install it. First, a utility to use the Bus Pirate to reprogram the OLS PIC chip should be available within the week. Second, we’ll setup repair centers worldwide to provide reflashes if you don’t have a Bus Pirate, and we can send a few Bus Pirates out on a mailing chain to help people update. Finally, there’s the option of using the FPGA to reprogram the PIC with a crafty bitstream.

Edit: removed v03 firmware, attached v05/06.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: terrymeyer on May 26, 2010, 01:52:20 am
Jack:

I'm a complete newb at all this, but was able to update the firmware using a jumper on the ICP header.

Through an Adaptec powered USB 1.1 hub, communication failures continued to occur (hmmm...maybe it's the 1.1?)

Connected directly to a ThinkPadT42, only one comm failure in over 50 sniffs. Much improved.

The LA sees I2C signals, but continues to report that over 90% of each reading (fast, slow, std, RLE, whatever) is filled with bus errors.
Could be me, don't know.

Speed and stability better than before. Haven't gotten to the enhanced Java features yet.

Thanks for the rev....

Terry
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 26, 2010, 01:56:53 am
Jack which do you want us to test?  BTW your .bat files never work on my XP systems the choice command seems to be missing or an add on I do not have.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 02:06:39 am
@Terry
Thanks for testing, I haven't had an opportunity to use the I2C plugin yet but with the UART plugin I did find that the higher frequency I captured the data at the more accurate the plugin was. You might try capturing at the highest frequency that you can get all your data in and see what the plugin results are then.

@rhyde
You probably want to start with 2.04 since it has some interesting new features, if it proves to be unstable then drop down to 2.03 and see if the same instability exists.
Sorry about the bat files, someone pointed the problem out a couple weeks ago but the SPI mode has taken so much effort to implement that I didn't have the energy to fix the bat file before releasing. Sorry, I intend to replace choice with a mingw equivalent soon.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 26, 2010, 02:21:50 am
Sorry I reread Jacks message and my problem is I did not update the pic.   So ignore me.  I have a bootloader less board, I will have to look at my options.

Okay initial attempt on xp box at work fails.  The device is com14 which is seenm but I have a consistent failure, where it use to be intermittent.   This is 3 for 3 here. (That is i tried 3 runs and all 3 failed) I will be headed home and I will try it on the mac and xp box there.
No problem with the bat I just want to make sure it had been pointed out.

No bootloader so I did not update the PIC, I am not sure if that was required.  I do have a bp so if Ian can point the script for that method I am willing to try that.


$ /cygdrive/c/Program Files/Java/jdk1.6.0_20/bin/java.exe -jar analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM1
COM14
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM1
COM14
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: COM14 (115200bps)
Run started
Device ID: 0x0
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Thread.java:619)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: LukeS on May 26, 2010, 08:20:18 am
I haven't tried updating yet so hopefully I have the boot loader but for those that do not can the OBLS PIC be programed with a bus pirate?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 10:27:53 am
Hi Terry - It sounds like you may have a timeout problem in the SUMP client, maybe the updated .jar file (with updated delay) will help. The SUMP project doesn't get many updates from it's authors any more, I'm hoping sigrok will have OLS support soon and I would recommend moving in that direction ASAP.

Just in case, I've attached an updated (SPI) firmware with a new USB device descriptor that allows for more current and has other updates. Maybe that will help with the hub problem. Please let me know what you find if you try it.

rhyde & Luke - We successfully programmed the flash of a PIC with the Bus Pirate on Monday, now we're adding the part of the app that loads and parses the HEX file to write. The difficult part (writing to PIC flash) is done, the HEX loading and parsing code can be borrowed from DS30Loader. The utility should be ready for testing very very soon, but I suggest you hold off until a few people with PIC programmers have tested it before risking bricking your OLS.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 26, 2010, 12:07:11 pm
@Jack.gasset: Is the testpattern simular with the one generated with two OLS, e.g. each next channel is halved the frequency? Could you provide a screenshot so people could compare their results with a know good one?

I'll post my findings tonight (I got a complete OLS with bootloader). You want the test results in a separate topic (like on the buspirate forum)?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 12:51:21 pm
This update worked for both the OLS boards I have, including the one with the 'unable to communicate with some bitstreams' problem. sampling of the PWM output of a a Bus Pirate looks good.

Maybe the firmware with updated descriptor will solve some hub issues, and we can release a massive fix for the most common issues. Once we get a handle on the bootloader problem we'll be in good shape.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: laube on May 26, 2010, 01:05:20 pm
I have a programmer and have tested the new release. It works fine with the old java client and appears to be little bit faster than before.
I don't think that it is necessary to get even higher transfer speeds though, because the OLS doesn't have a lot of memory to dump.. with my setup it gets the data in < 1s.

Trying to run the new Java client with the command line
Code: [Select]
java -jar analyzer.jar
gives me the error:
Code: [Select]
Error while invoking application: null

dont know what that is supposed to mean..

files in folder:
[font=courier:]Verzeichnis von F:ProgrammeSUMP2.04TestRelease

26.05.2010  12:28              .
26.05.2010  12:28              ..
30.04.2010  14:39           124'927 analyzer.jar
25.05.2010  15:52             1'236 ChangeLog.txt
26.05.2010  12:28              firmware
25.05.2010  16:00               308 load_ROM.bat
25.05.2010  14:34           169'314 logic_sniffer.bit
25.05.2010  14:35           465'404 Logic_Sniffer.mcs
24.02.2010  16:49            33'022 pump-loader.exe
15.12.2006  11:36                30 run_java_client.bat
26.05.2010  12:58              jre1.6.0_14-b08
               7 Datei(en)        794'241 Bytes
               4 Verzeichnis(se),  3'490'840'576 Bytes frei[/font:]


Laube
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 26, 2010, 03:17:21 pm
Hi,
[quote author="laube"]
Trying to run the new Java client with the command line
Code: [Select]
java -jar analyzer.jar
gives me the error:
Code: [Select]
Error while invoking application: null
Laube
[/quote]

The same here, is the source code for this version of the client somewhere (can't find it in SVN on GadgetFactory, last update on the trunk was 8 days ago)

Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 26, 2010, 04:09:12 pm
Hi,
I updated the board with the 2.04 release (PIC and bitstream)
The board is still detected as a USB2Serial but every attempt to capture data fails with
Code: [Select]
Attaching to: /dev/ttyACM0 (115200bps)
Run started
Device ID: 0x0
Run aborted
java.io.IOException: Device not found.
        at org.sump.analyzer.devices.FpgaDevice.run(FpgaDevice.java:649)
        at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceController.java:550)
        at java.lang.Thread.run(Thread.java:619)
I have another LA, are the signals used for the new SPI transfer available on pins? I could try to capture the signals between PIC and FPGA.

I use the client code from GadgetFactory SVN with the timeout on the usb2serial set to 5 seconds.

Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 04:21:58 pm
@wayoda - Is the ACT LED off? Could you please post the results of a pump-loader -status run.

Also, could you please test with a serial terminal that can send hex like Herculese (http://www.hw-group.com/products/hercules/index_en.html (http://www.hw-group.com/products/hercules/index_en.html)) and send 00 00 00 00 00 02. It should return 1ALS as in the screenshot attached.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rajkosto on May 26, 2010, 04:28:31 pm
Found PUMP HW: 1, FW: 0.1, Boot: 255

:(
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 04:38:15 pm
Please see the status command in the upgrade overview. If you run status and get BOOT:255 then it is not installed.
http://dangerousprototypes.com/2010/05/ ... ers-needed (http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 04:43:10 pm
Hello,

Code: [Select]
Error while invoking application: null


This error message means that you do not have rxtx installed in the java instance that is first in your path.

Jack.

[quote author="laube"]
I have a programmer and have tested the new release. It works fine with the old java client and appears to be little bit faster than before.
I don't think that it is necessary to get even higher transfer speeds though, because the OLS doesn't have a lot of memory to dump.. with my setup it gets the data in < 1s.

Trying to run the new Java client with the command line
Code: [Select]
java -jar analyzer.jar
gives me the error:
Code: [Select]
Error while invoking application: null

dont know what that is supposed to mean..

files in folder:
[font=courier:]Verzeichnis von F:ProgrammeSUMP2.04TestRelease

26.05.2010  12:28              .
26.05.2010  12:28              ..
30.04.2010  14:39           124'927 analyzer.jar
25.05.2010  15:52             1'236 ChangeLog.txt
26.05.2010  12:28              firmware
25.05.2010  16:00               308 load_ROM.bat
25.05.2010  14:34           169'314 logic_sniffer.bit
25.05.2010  14:35           465'404 Logic_Sniffer.mcs
24.02.2010  16:49            33'022 pump-loader.exe
15.12.2006  11:36                30 run_java_client.bat
26.05.2010  12:58              jre1.6.0_14-b08
               7 Datei(en)        794'241 Bytes
               4 Verzeichnis(se),  3'490'840'576 Bytes frei[/font:]


Laube
[/quote]
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 04:53:23 pm
@Sjaak
Attached is a screenshot of the test pattern

@wayoda
The Java client code checked into svn is the correct code, I made the changes 8 days ago with a non SPI bitstream.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 05:19:58 pm
I don't think the current SPI firmware supports the SPI send of 0x03 for the test pattern with a jumper, I just added that to SVN. But you can send it manually with a serial terminal.

I also added several small updates to the SVN version can we can roll into the new release:
*ADC configured for lower power use
*ADC on PROG_B pin used to measure 2.5volt power supply
*change to central variable for timers
*I've updated the non-pubic USB descriptor file

My to do list for the firmware, after we get the SPI working and handle the missing bootloaders:
* Improve SPI speed, especially on dumps by filling the buffer until the FPGA has no more data or the buffer is full.
* maybe add a r/w indicator signal to avoid missed bytes during bidirectional traffic
* move self-test to a separate function
* clean up the code, move to separate files
* eventually move to an open source USB stack. I don't think the one we hired out will ever be done, but I found LUFA today which has much of the work done. All that is needed is a custom hardware abstraction for the PIC USB peripheral. It's currently in progress.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rajkosto on May 26, 2010, 05:39:38 pm
i get a device not found when trying to update the pic firmware
does this mean that i dont have the bootloader installed (even though i have the firmware installed)
is there an updating procedure anywhere detailed ? (do we have to short pgc with pgd)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: justinsm on May 26, 2010, 05:41:16 pm
Hi,

I've got the SVN version of the diolan bootloader client to compile under Linux (ubuntu 10.04).

I just added string.h to osdep/lnxdefs.h:

   #include
   #include
   #include
   #include
   #include
   #include

   #include
   #include

and stdlib.h to osdep/osdep.h:

   /* Linux definitions */
   #include "lnxdefs.h"
   #include
   #include
   #include
   #endif /* (defined _WIN32 || defined _WIN64) */
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 06:01:03 pm
@rajkosto - please check that you follow all the steps detailed in the upgrade guide:

http://dangerousprototypes.com/2010/05/ ... ers-needed (http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed)

Run pump-loader with the -status flag to check the bootloader. If you still have a problem connecting but the bootloader is installed, please let me know.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 26, 2010, 06:03:19 pm
@Jack: thanks. I'll try it tonight and will post my findings. I would guessed it would be the same as the other testpattern so I would be scared to death when I saw this ;)

@ian: the usb HW is fairly simple to controll and for most pics the same. Goods news! Only the vid/pid thing to conquer ;)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 06:11:14 pm
@justinsm - is it possible to create a redistributable from your compile that we can include in the release package?

@Sjaak - after we have a open licensed firmware, I'm not worried about the VID/PID thing ;)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 26, 2010, 06:36:06 pm
@rajkosto - it looks like you updated an old post instead of posting a new one, I almost missed it:

Quote
Found PUMP HW: 1, FW: 0.1, Boot: 255

This is the missing bootloader indication. Do you have a PIC programmer or Bus Pirate? These will be the easiest way to install a new bootloader. There is also someone close to you (your IP anyways) who can reflash it and have it back in a few days, please PM me for an address.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Crawford on May 26, 2010, 07:31:48 pm
Hi,

I tried the 2.03 and 2.04 code, going through the whole upgrade process for both upgrades, and got the 'Device Not Found' error, using the precompiled 1.0 SUMP client on Windows XP.  I got the Java Client running and go the same 'Device not found' error.

Next I uploaded the PUMP.hex PIC code from the firmware-03-20Mhz.zip file, and reloaded the 2.04 Logic_Sniffer.mcs code for good measure.

Final state according to pump-loader status: Found PUMP HW: 1, FW: 0.3, Boot: 1

So, now I can connect to the Open Bench with either client, but while it is much faster, it's not really more reliable.  I ran a bunch of sniffs back-to-back:

With the Java client:
Number of successful runs before a failure (Device not found): 5,7,2,2,8,2,8,2,2  (37 successes, 9 fails, ~25% failure rate)

With the precompiled client:
Number of successful runs before a failure (Device not found): 7,10,0,47,27 (91 successes, 5 fails, ~5% failure rate)

So, I'm not sure what to conclude from this other than the latest PIC f/w works for me (and the others don't) and the Java client is faster, but less reliable.

-Crawford
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 26, 2010, 07:45:10 pm
Hmmmm,

I guess the big question is whether the Device not found failures are coming from the SPI communication between the FPGA and the PIC or from USB communication failures like people have been seeing with certain hubs...

Jack.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 26, 2010, 08:39:55 pm
Seems like I had  the same problem as wayoda. After upgrading the firmware to 0.3 it worked again. It seem to work ervery time and not intermittingly like crawford (not tested much yet). Haven't had a go at the integrated testpattern, since upgrading took me longer then expected ;) I'm sorry but tonight i haven't got any time to do anymore testing, sorry.

When it didn't work I tried to do it with the hercules util but no reaction from the OLS, even tried extra leading 0x00, but nothing.

One thing can be confusing, all the filenames of the  bitstreams and firmwares have the same name. Could you please integrate it in the filename? (I know it is easily to forget and I do it also wrong sometimes ;)

For the record I have a transcript of the upgrade proces and running the various analyzer.jar's . (analyzer2 is the new one)


Code: [Select]
D:2.04TestRelease>dir
 Het volume in station D heeft geen naam.
 Het volumenummer is 00B2-CF12

 Map van D:2.04TestRelease

05/26/2010  06:56 PM    <DIR>          .
05/26/2010  06:56 PM    <DIR>          ..
04/30/2010  02:39 PM           124,927 analyzer.jar
05/25/2010  03:52 PM             1,236 ChangeLog.txt
05/26/2010  06:56 PM    <DIR>          firmware
05/25/2010  04:00 PM               308 load_ROM.bat
05/25/2010  02:34 PM           169,314 logic_sniffer.bit
05/25/2010  02:35 PM           465,404 Logic_Sniffer.mcs
02/24/2010  04:49 PM            33,022 pump-loader.exe
12/15/2006  11:36 AM                30 run_java_client.bat
               7 bestand(en)          794,241 bytes
               3 map(pen)  34,687,549,440 bytes beschikbaar

D:2.04TestRelease>pump-loader.exe -p:com8 -status
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

D:2.04TestRelease>cd firmware

D:2.04TestReleasefirmware>dir
 Het volume in station D heeft geen naam.
 Het volumenummer is 00B2-CF12

 Map van D:2.04TestReleasefirmware

05/26/2010  06:56 PM    <DIR>          .
05/26/2010  06:56 PM    <DIR>          ..
02/24/2010  04:49 PM           257,536 fw_update.exe
05/18/2010  09:25 AM                68 OLS-program.bat
05/11/2010  09:38 AM            22,421 PUMP.hex
               3 bestand(en)          280,025 bytes
               2 map(pen)  34,687,549,440 bytes beschikbaar

D:2.04TestReleasefirmware>cat OLS-program.bat
fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix PUMP.hex
pause
D:2.04TestReleasefirmware>..pump-loader.exe -p:com8 -boot
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.1, Boot: 1
Found flash: ATMEL AT45DB041D
PUMP switched to bootloader mode

D:2.04TestReleasefirmware>OLS-program.bat

D:2.04TestReleasefirmware>fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix
 PUMP.hex
U2IO flash erasing: DONE.
U2IO flash programming: DONE.
RESET Device
Operation successfully completed.

D:2.04TestReleasefirmware>pause
Druk op een toets om door te gaan. . .

D:2.04TestReleasefirmware>..pump-loader.exe -p:com8 -status
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.2, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

D:2.04TestRelease>pump-loader.exe -write -p:com8 -wH:.Logic_Sniffer.mcs -run
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.2, Boot: 1
Found flash: ATMEL AT45DB041D
Reading HEX file '.Logic_Sniffer.mcs' ... OK! (binary size = 169216)
Will write 641 pages
Page 0x0000 write ... OK
Page 0x0001 write ... OK
Page 0x0002 write ... OK
Page 0x0003 write ... OK
Page 0x0004 write ... OK
.. coffeebreak
Page 0x027d write ... OK
Page 0x027e write ... OK
Page 0x027f write ... OK
Page 0x0280 write ... OK
PUMP switched to RUN mode

D:2.04TestRelease>cd BFP_Logic_Analyzer_1.0

D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jat analyzer2.jar
Unrecognized option: -jat
Could not create the Java virtual machine.

D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jar analyzer2.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM3
COM8
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM3
COM8
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: COM3 (115200bps)
Run started
Device ID: 0x0
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM8 (115200bps)
Run started
Device ID: 0x0
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Unknown Source)

D:BFP_Logic_Analyzer_1.0>
D:BFP_Logic_Analyzer_1.0>cd ..2.03TestRelease

D:2.03TestRelease>dir
 Het volume in station D heeft geen naam.
 Het volumenummer is 00B2-CF12

 Map van D:2.03TestRelease

05/26/2010  08:01 PM    <DIR>          .
05/26/2010  08:01 PM    <DIR>          ..
05/25/2010  03:52 PM             1,236 ChangeLog.txt
05/26/2010  08:01 PM    <DIR>          firmware
05/25/2010  04:00 PM               308 load_ROM.bat
05/25/2010  11:12 AM           169,314 logic_sniffer.bit
05/25/2010  11:12 AM           465,404 Logic_Sniffer.mcs
02/24/2010  04:49 PM            33,022 pump-loader.exe
               5 bestand(en)          669,284 bytes
               3 map(pen)  34,686,582,784 bytes beschikbaar

D:2.03TestRelease>pump-loader.exe -write -p:com8 -wH:.Logic_Sniffer.mcs -run
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.2, Boot: 1
Found flash: ATMEL AT45DB041D
Reading HEX file '.Logic_Sniffer.mcs' ... OK! (binary size = 169216)
Will write 641 pages
Page 0x0000 write ... OK
Page 0x0001 write ... OK
Page 0x0002 write ... OK
Page 0x0003 write ... OK
Page 0x0004 write ... OK
Page 0x0005 write ... OK
Page 0x0006 write ... OK
Page 0x0007 write ... OK
... yet another coffee
Page 0x027b write ... OK
Page 0x027c write ... OK
Page 0x027d write ... OK
Page 0x027e write ... OK
Page 0x027f write ... OK
Page 0x0280 write ... OK
PUMP switched to RUN mode

D:2.03TestRelease>cd BFP_Logic_Analyzer_1.0

D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava.exe -jar analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM3
COM8
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM3
COM8
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: COM8 (115200bps)
Run started
Device ID: 0x0
Run aborted
java.io.IOException: Device not found.
        at org.sump.analyzer.devices.FpgaDevice.run(FpgaDevice.java:613)
        at org.sump.analyzer.devices.FpgaDeviceController.run(FpgaDeviceControll
er.java:524)
        at java.lang.Thread.run(Unknown Source)

D:BFP_Logic_Analyzer_1.0>
D:2.03TestRelease>.pump-loader.exe -p:com8 -status
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.2, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

D:2.03TestRelease>
D:2.04TestReleasefirmware>fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix
 PUMP0.3.hex
U2IO flash erasing: DONE.
U2IO flash programming: DONE.
RESET Device
Operation successfully completed.

D:2.04TestReleasefirmware>cd BFP_Logic_Analyzer_1.0

D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jar analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM3
COM8
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM3
COM8
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: COM8 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed

D:BFP_Logic_Analyzer_1.0>cd 2.04TestRelease
D:2.04TestRelease>pump-loader.exe -p;com8 -status
PUMP loader

Opening serial port 'com8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.3, Boot: 1
Found flash: ATMEL AT45DB041D
no input file specified !

D:2.04TestRelease>pump-loader.exe -P:COM8 -wH:.Logic_Sniffer.mcs -write -run
PUMP loader

Unknown parameter '-P:COM8'

D:2.04TestRelease>pump-loader.exe -p:COM8 -wH:.Logic_Sniffer.mcs -write -run
PUMP loader

Opening serial port 'COM8' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.3, Boot: 1
Found flash: ATMEL AT45DB041D
Reading HEX file '.Logic_Sniffer.mcs' ... OK! (binary size = 169216)
Will write 641 pages
Page 0x0000 write ... OK
Page 0x0001 write ... OK
Page 0x0002 write ... OK
Page 0x0003 write ... OK
Page 0x0004 write ... OK
... something else then coffee
Page 0x027b write ... OK
Page 0x027c write ... OK
Page 0x027d write ... OK
Page 0x027e write ... OK
Page 0x027f write ... OK
Page 0x0280 write ... OK
PUMP switched to RUN mode

D:2.04TestRelease>cd BFP_Logic_Analyzer_1.0

D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jar analyzer2.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM3
COM8
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM3
COM8
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: COM8 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)

D:BFP_Logic_Analyzer_1.0>

Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: justinsm on May 26, 2010, 08:46:02 pm
@ian, attached is a dynamically linked fw_update build for 64-bit linux, I'll make a statically linked one too. 32-bit will take a little while, as I need to build a suitable 32-bit VM.

Also, I haven't tested that it works yet, which I'm about to do (or not, if my OLS lacks a bootloader)...
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: robots on May 26, 2010, 09:29:13 pm
[quote author="justinsm"]
@ian, attached is a dynamically linked fw_update build for 64-bit linux, I'll make a statically linked one too. 32-bit will take a little while, as I need to build a suitable 32-bit VM.

Also, I haven't tested that it works yet, which I'm about to do (or not, if my OLS lacks a bootloader)...
[/quote]

My bet is that it won't work :)  As the bootloader acts as HID it gets bind with generic linux HID driver. You need to instruct libusb to unbind the driver for you. I have already mentioned this in earlier threads  http://dangerousprototypes.com/forum/index.php?topic=336.15 (http://http://dangerousprototypes.com/forum/index.php?topic=336.15)

You need to patch the pic-bootloader.cpp
Code: [Select]
@@ -516,8 +518,16 @@
  // Valid device found
  found = true;
  devHandle = usb_open(dev);
+
  if (devHandle == NULL)
  break;
+
+ char buf[40];
+ int ret = usb_get_driver_np(devHandle, 0, buf, sizeof(buf));
+ if (ret == 0) {
+ usb_detach_kernel_driver_np(devHandle, 0);
+ }
+
  if (usb_claim_interface(devHandle, 0) < 0) {
  usb_close(devHandle);
  break;
Also i have had problems with some command sequences.

This should probably have thread on its own
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: justinsm on May 26, 2010, 10:32:52 pm
@robots, yes that fixes it.

The attached works for me. Well, read (-r) and write (-w) work, verify (-v) doesn't, but I upgraded to FW 0.3 without any difficulty.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rajkosto on May 26, 2010, 10:53:18 pm
i am using a vpn
i am actually from serbia
it's no problem, just sucks that i have to do extra work
i will make a program for my ft2232 test board to do the pic programming
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 26, 2010, 11:13:01 pm
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


/Mac
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ado on May 26, 2010, 11:23:39 pm
I have no bootloader, maybe overwritten by testing.
I made some tests and I have still the problem with the wrong PID.

Here my test:

Erased the PIC.
Don't know about the programs/datas inside the the PROM and the FPGA.
Program the PIC with ICD2 with the bootloader from the 1.03 Packet.

There's no Serial Device because of no fw.

Jumpered PGC/PGD

HID Device with PID FC90 is there.

Update fw with OLS-program.bat from 2.04TestRelease.

In  both modes the PID is still 000A.


Just for information.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 27, 2010, 12:29:52 am
Thanks for the good work, I am waiting until I hear from you before doing anything more here, other that pinging friends for a pic programmer if they have one.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 10:48:22 am
Quote
In  both modes the PID is still 000A.

Both ROM update and SUMP mode have the same PID. That isn't the correct PID (compiler error), but it is correct that those two modes share the same PID. They work from the same driver, have the same connection type, the update button just branches to a different loop.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 10:56:22 am
@crawford - Thanks for the report. Can you please try a few things and let us know the results. We might be able to pin this on the hardware or the software with a little testing.

First, could you please post the output of the SUMP Java debug screen from a failed capture.

Second, could you please try using a program like herculese (http://www.hw-group.com/products/hercules/index_en.html (http://www.hw-group.com/products/hercules/index_en.html)) to send 00 00 00 00 00 02 to the OLS serial port. It should reply 1ALS every time. (please see the attached screenshot).

Finally, can you please try running portmon (http://technet.microsoft.com/en-us/sysi ... 96644.aspx (http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx)) on the OLS serial port, then start SUMP and log port traffic during a failed capture. Please post the log here.

This debugging info could help us figure out what's going on.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 27, 2010, 11:59:21 am
Hi,
here are my results with the two Test packages:
The 2.03 Version works fine. With the original Firmware/Bitstreams that came with the board preprogrammed I had to reset the board manually sometimes to make it work. Now it works all the time. (But I never had any problems capturing data with the original firmware/bitstreams, so I don't seem to have that timing problem with the FPGA)

The 2.04 Version does not work at all. I tried this 4 times: switching between version 2.03 and 2.04.
2.03 always worked -
2.04 never even answered to the 5 RESET commands followed by GET-ID.

Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 27, 2010, 12:23:13 pm
@Wayoda: did you also try the new firmware (0.3) Ian posted?

I had simular error (however both SPI bitstreams didn't work) but it was solved with the new firmware.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 27, 2010, 12:53:03 pm
Regarding the bitstreams,
Can I run the old bitstreams with firmware 3?
Or do they all need to be ported to the 2.04 release format???

/mac
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 01:02:15 pm
@swissMac - No, the old bitstreams have a UART connection between the PIC and FPGA, the new ones use an SPI connection. The FPGA won't respond with a mis-matched interface type.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 27, 2010, 01:09:23 pm
[quote author="Sjaak"]
@Wayoda: did you also try the new firmware (0.3) Ian posted?

I had simular error (however both SPI bitstreams didn't work) but it was solved with the new firmware.
[/quote]
No, I don't think that would help in any way. I never had any problems with my OLS boards and my powered hub.
There are also no problems with the USB part of the firmware. The  device is enumerated by the USB system without any problems.
The linux kernel is pretty good at reporting errors in the USB-subsystem, but there is no trace of it. 
The 2.04 firmware simply never answers the getID request, connection times out (I set the timeout to 5 seconds) and that's the whole problem.
(I also tried this with the hercules-serial-utility, the device simply does not answer).

But I lost track about how this went for others, did anybody else get the 2.04 version to work?

Since the 2.03 version works fine on the first board, I will now try 2.04 on the second board.
Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 27, 2010, 01:20:32 pm
@wayoda,

With firmware 0.2 my OLS didn't respond to the getID request (USB device did connect OK), when I upgraded to firmware 0.3, it automagically got working and the OLS respond to the getID:

Quote
Seems like I had  the same problem as wayoda. After upgrading the firmware to 0.3 it worked again. It seem to work ervery time and not intermittingly like crawford (not tested much yet). Haven't had a go at the integrated testpattern, since upgrading took me longer then expected ;) I'm sorry but tonight i haven't got any time to do anymore testing, sorry.

When it didn't work I tried to do it with the hercules util but no reaction from the OLS, even tried extra leading 0x00, but nothing.

I know that the changes Ian described about the 0.3 firmware don't mention fixing this, but it did work after the upgrade.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 27, 2010, 03:23:51 pm
[quote author="Sjaak"]
@wayoda,

With firmware 0.2 my OLS didn't respond to the getID request (USB device did connect OK), when I upgraded to firmware 0.3, it automagically got working and the OLS respond to the getID:

I know that the changes Ian described about the 0.3 firmware don't mention fixing this, but it did work after the upgrade.
[/quote]
Confirmed. The boards responds and collects data.
Up to 4k of data the device seems to work good. All 4 trigger-steps work fine. 
If I switch to 8k of data with groups 2+3 disabled the results becomes unpredictable.
The device triggers sometimes on the right data but most of time it returns the wrong data (all zero).

So my Test status is now:
Release 2.03 works
Release 2.04 works with firmware revision 0.3 up to 4k of data

Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 03:30:43 pm
Here is a firmware v0.4 to test. It has some additional changes and an additional self test.

I hope maybe the extra attention and delays to the startup sequence will eliminate some erratic behavior, especially on the first run.

This is an 'SPI' link firmware, and will only work with the 2.03 or 2.04 FPGA bitstreams posted at the top of this thread.

You will need to use the updated .INF file included to reinstall the OLS after updating. The corrected PID is used, and the device now appears as 'Logic Sniffer CDC-232'.

v0.4
*updated the USB descriptor file for power, current, PID, says 'Logic Sniffer CDC-232'
*extra care to reset FPGA after SPI CS pin is setup
*ADC configured for lower power use
*ADC on PROG_B pin used to measure 2.5volt power supply as extra self test
*change to central variable for timers

Edit: it looks like the gadget factory website is down, I'll commit these changes to SVN when I can.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Crawford on May 27, 2010, 03:56:52 pm
Ian,

As requested ..here's the first part of the test. A successful run followed by a failed one (with an error reported). 
Code: [Select]
Run completed
Attaching to: COM12 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM12 (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: 10
10000010 00000010 00000000 00000000 00000000
Run aborted

... and now for something completely different, an failed run without any error reported...

Code: [Select]
Run completed
Attaching to: COM12 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed
Attaching to: COM12 (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: 10
10000010 00000010 00000000 00000000 00000000
Run aborted


Not sure what to make of this, but sometimes it errors and sometimes not.  Also I got this once, between successful runs:

Code: [Select]
Run completed
Attaching to: COM12 (115200bps)
Run started
Device ID: 0x0
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM12 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed

Note that I only get this using back-to-back-as-fast-as-I-can-click runs.  If I wait half a sec between clicks it seems to keep up.

I'll send the port scans, etc. soon.

-Crawford
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 04:14:03 pm
Thanks Crawford - The interesting thing about the Java output is that there is never a place where the OLS doesn't give it's ID correctly. I take this as good news because it means you;re not having the problem the SPI was implemented to fix (some bitstreams don't respond on some boards). There may be problems with hardware/firmware/software/system that cause these issues. We'll keep looking into it. The port captures will help because we can see exactly what happened when it decided to quit.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: wayoda on May 27, 2010, 04:15:40 pm
[quote author="ian"]
Here is a firmware v0.4 to test. It has some additional changes and an additional self test.
[/quote]
Installed v0.4

Works as good/bad as v03 on my board:
(up to) 4k captures are ok.
8k captures do not work here (the data is returned without but not correct).

Eberhard
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 04:27:11 pm
Quote
8k captures do not work here (the data is returned without but not correct).

I'd guess that is probably a bug in the new bitstream that combines the different memory depths and channels, instead of a hardware/firmware/software bug. Has anyone gotten the new features in 2.04 working?

Have any of the new firmwares resolved the hub or laptop USB port problems people have been experiencing? That's a big target of the new firmware updates (0.03+).
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: theterg on May 27, 2010, 07:09:41 pm
First off, Ian, thanks for the work you are putting into this.   I can't wait to see all the new features future firmwares will uncover.

[quote author="ian"]
Quote
In  both modes the PID is still 000A.

Both ROM update and SUMP mode have the same PID. That isn't the correct PID (compiler error), but it is correct that those two modes share the same PID. They work from the same driver, have the same connection type, the update button just branches to a different loop.
[/quote]

I'm having trouble updating the PIC firmware.  After writing either 2.03 or 2.04 to the FPGA on my OLS, "pump-loader -status" indicates "Boot: 1".  However, when I go an preform a fw_update, I see "Device is not found" "Operation Aborted."  I noticed that my OLS is also showing up with a PID of 000A, and that changing the -pid flag to fw_update doesn't actually make it work.

Any ideas?  Is there any chance that I didn't have the bootloader, and upgrading the FPGA first cleared the Boot: 1 message?  What does a PID of 000A indicate?

Thanks.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 07:26:39 pm
Hey theterg - it sounds like you're not in bootloader mode. Enter by connecting the PGC/PGD pins and then press reset. Or, you can go to ROM update mode and use pump-loader to enter the bootloader:

http://dangerousprototypes.com/2010/05/ ... ers-needed (http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: theterg on May 27, 2010, 07:36:50 pm
Yup, didn't read that through closely enough.  Was too excited.  OLS works now, thanks.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 07:43:11 pm
Thanks for the update, glad it worked for you.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: phdussud on May 27, 2010, 08:14:21 pm
Hey, I can't find the drop down to test and configure the memory in the java client. Also it seems that in the 2.04 zip file, the date of the jar file is old (April). Are you sure you have included the version of the jar file you intended?
Thanks
Patrick.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 08:19:28 pm
Quote
I can't find the drop down to test and configure the memory in the java client.

Hi Patrick - as far as I know, the memory is configured by selecting the sample depth and checking or unchecking channels to sample.

I don't know of a memory test. There is a manufacturing test build into 2.4, but it is triggered externally, not from the SUMP client.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: phdussud on May 27, 2010, 08:45:50 pm
Ian, I was referring to the following post fragment Jack included in his 2.04 announcement:
Test Release 2.04 still uses the SPI mode but adds some goodies and a new version of the Java client. The Java client has an option to select the inside or outside numbering scheme and it also adds a test mode. If a ribbon cable is connected between the two headers and test mode is selected a test pattern can be captured. There is also a first attempt at enabling multiple memory configurations. If channel group 2 and 3 is disabled then 8k of memory depth should be available. If all channel groups are enabled then 4k of memory depth is available.

How can I select the numbering scheme or the test mode?
Thanks!
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: elwing on May 27, 2010, 08:51:33 pm
doh, too bad...

Code: [Select]
PUMP loader

Opening serial port 'COM5' @ 921600 ... OK
Found PUMP HW: 1, FW: 0.1, Boot: 255
Found flash: ATMEL AT45DB041D
no input file specified !

the worst being that I got no bus pirate nor ICSP device...
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 27, 2010, 09:21:16 pm
@phdussud

The analyzer.jar that is included is the correct one. I made the changes to the Java client some time ago and released the same changes in the forum before. I just don't think many people noticed it, only a couple people downloaded it. :)

To access the test mode you need to startup the analyzer.jar with a version of the JRE that has rxtx included. You will see a new dropdown box called "Number Scheme" which is under the connection settings group. The options are, "Inside", "Outside", and "Test Mode".

I will try to make an executable available soon.

Jack.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: phdussud on May 27, 2010, 09:25:58 pm
@Jack
I see, cool. I will look for such a JRE. Meanwhile, I have the most recent firmware (the one with the updated USB profile) and the 2.04 update and everything seems to be working well. I need to test more to verify the integrity of the recording, but I have had no connection problems.
Thanks!!!!
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 27, 2010, 10:07:09 pm
Sorry guys, I missed the update to the Java client, I still use the last one from SUMP project (0.81? something).
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Crawford on May 27, 2010, 10:40:51 pm
@Ian,

Well the Hercules utility returns 1ALS every time.

With PortMon running, it is damnably hard to get it to fail.  I think that it slows down the whole system so it does not glitch.  I wasn't able to get the lasteest Java client to fail at all with PortMon on.  With the old 'compiled' client (BP_LogicAnalyzer.exe took some doing, but I did get it into a failure mode. Below is the dump from PortMon during a (more or less complete) failed run.  All other failed runs had a similar ending ~20 lines.

Code: [Select]
0	0.00001481	javaw.exe	IRP_MJ_CREATE	USBSER000	SUCCESS	Options: Open 	
1 0.00000363 javaw.exe IRP_MJ_CLEANUP USBSER000 SUCCESS
2 0.00037295 javaw.exe IRP_MJ_CLOSE USBSER000 SUCCESS
6 0.00001257 javaw.exe IRP_MJ_CREATE USBSER000 SUCCESS Options: Open
7 0.00000223 javaw.exe IOCTL_SERIAL_SET_QUEUE_SIZE USBSER000 SUCCESS InSize: 2048 OutSize: 1024
8 0.00000307 javaw.exe IOCTL_SERIAL_GET_PROPERTIES USBSER000 SUCCESS
9 0.00052744 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
10 0.00047604 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
11 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
12 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
13 0.00043050 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
14 0.00048274 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
15 0.00000251 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
16 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
17 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
18 0.00054783 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
19 0.00046403 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
20 0.00000307 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
21 0.00000196 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
22 0.00087832 javaw.exe IOCTL_SERIAL_SET_BAUD_RATE USBSER000 SUCCESS Rate: 9600
23 0.00000251 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
24 0.00032462 javaw.exe IOCTL_SERIAL_SET_DTR USBSER000 SUCCESS
25 0.00097890 javaw.exe IOCTL_SERIAL_SET_LINE_CONTROL USBSER000 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
26 0.00000279 javaw.exe IOCTL_SERIAL_SET_CHAR USBSER000 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0
27 0.00000223 javaw.exe IOCTL_SERIAL_SET_HANDFLOW USBSER000 SUCCESS Shake:1 Replace:0 XonLimit:0 XoffLimit:0
28 0.00000251 javaw.exe IOCTL_SERIAL_SET_TIMEOUTS USBSER000 SUCCESS RI:0 RM:0 RC:0 WM:0 WC:0
29 0.00056460 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
30 0.00046235 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
31 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
32 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
33 0.00000279 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
34 0.00050844 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
35 0.00066768 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
36 0.00000307 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
37 0.00000223 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
38 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
39 0.00043804 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
40 0.00043190 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
41 0.00000251 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
42 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
43 0.00092274 javaw.exe IOCTL_SERIAL_SET_BAUD_RATE USBSER000 SUCCESS Rate: 9600
44 0.00000251 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
45 0.00032937 javaw.exe IOCTL_SERIAL_SET_DTR USBSER000 SUCCESS
46 0.00085625 javaw.exe IOCTL_SERIAL_SET_LINE_CONTROL USBSER000 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
47 0.00000251 javaw.exe IOCTL_SERIAL_SET_CHAR USBSER000 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0
48 0.00000223 javaw.exe IOCTL_SERIAL_SET_HANDFLOW USBSER000 SUCCESS Shake:1 Replace:0 XonLimit:0 XoffLimit:0
49 0.00000279 javaw.exe IOCTL_SERIAL_SET_TIMEOUTS USBSER000 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0
50 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
51 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
52 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
53 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
54 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
55 0.00000223 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
56 0.00050397 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
57 0.00050705 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
58 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
59 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
60 0.00000223 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
61 0.00053443 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
62 0.00049112 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
63 0.00000251 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
64 0.00000223 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
65 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
66 0.00053415 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
67 0.00048665 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
68 0.00000223 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
69 0.00000223 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
70 0.00095291 javaw.exe IOCTL_SERIAL_SET_BAUD_RATE USBSER000 SUCCESS Rate: 115200
71 0.00000307 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
72 0.00043274 javaw.exe IOCTL_SERIAL_SET_DTR USBSER000 SUCCESS
73 0.00095710 javaw.exe IOCTL_SERIAL_SET_LINE_CONTROL USBSER000 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
74 0.00000307 javaw.exe IOCTL_SERIAL_SET_CHAR USBSER000 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0
75 0.00000279 javaw.exe IOCTL_SERIAL_SET_HANDFLOW USBSER000 SUCCESS Shake:1 Replace:0 XonLimit:0 XoffLimit:0
76 0.00000279 javaw.exe IOCTL_SERIAL_SET_TIMEOUTS USBSER000 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0
77 0.00043330 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
78 0.00047073 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
79 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
80 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
81 0.00000279 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
82 0.00040284 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
83 0.00048637 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
84 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
85 0.00000223 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
86 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
87 0.00043832 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
88 0.00046486 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
89 0.00000279 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
90 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
91 0.00091744 javaw.exe IOCTL_SERIAL_SET_BAUD_RATE USBSER000 SUCCESS Rate: 115200
92 0.00000279 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
93 0.00043246 javaw.exe IOCTL_SERIAL_SET_DTR USBSER000 SUCCESS
94 0.00095990 javaw.exe IOCTL_SERIAL_SET_LINE_CONTROL USBSER000 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
95 0.00000279 javaw.exe IOCTL_SERIAL_SET_CHAR USBSER000 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0
96 0.00000251 javaw.exe IOCTL_SERIAL_SET_HANDFLOW USBSER000 SUCCESS Shake:1 Replace:2 XonLimit:0 XoffLimit:0
97 0.00000279 javaw.exe IOCTL_SERIAL_SET_TIMEOUTS USBSER000 SUCCESS RI:-1 RM:0 RC:0 WM:0 WC:0
98 0.00046570 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
99 0.00045397 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
100 0.00000251 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
101 0.00000223 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
102 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
103 0.00052465 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
104 0.00048274 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
105 0.00000251 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
106 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
107 0.00000251 javaw.exe IOCTL_SERIAL_GET_TIMEOUTS USBSER000 SUCCESS
108 0.00055314 javaw.exe IOCTL_SERIAL_GET_BAUD_RATE USBSER000 SUCCESS
109 0.00046570 javaw.exe IOCTL_SERIAL_GET_LINE_CONTROL USBSER000 SUCCESS
110 0.00000307 javaw.exe IOCTL_SERIAL_GET_CHARS USBSER000 SUCCESS
111 0.00000251 javaw.exe IOCTL_SERIAL_GET_HANDFLOW USBSER000 SUCCESS
112 0.00090263 javaw.exe IOCTL_SERIAL_SET_BAUD_RATE USBSER000 SUCCESS Rate: 115200
113 0.00000335 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
114 0.00041793 javaw.exe IOCTL_SERIAL_SET_DTR USBSER000 SUCCESS
115 0.00068891 javaw.exe IOCTL_SERIAL_SET_LINE_CONTROL USBSER000 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
116 0.00000279 javaw.exe IOCTL_SERIAL_SET_CHAR USBSER000 SUCCESS EOF:4 ERR:0 BRK:0 EVT:a XON:0 XOFF:0
117 0.00000279 javaw.exe IOCTL_SERIAL_SET_HANDFLOW USBSER000 SUCCESS Shake:1 Replace:2 XonLimit:0 XoffLimit:0
118 0.00000279 javaw.exe IOCTL_SERIAL_SET_TIMEOUTS USBSER000 SUCCESS RI:0 RM:0 RC:100 WM:0 WC:100
119 0.00028300 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
120 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
121 0.00030367 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
122 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
123 0.00033468 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
124 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
125 0.00038161 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
126 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
127 0.00031065 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
128 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
129 0.00032965 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
130 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
131 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
132 0.00000391 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: 1
133 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
134 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
135 0.00000335 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: A
136 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
137 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
138 0.00000307 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: L
139 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
140 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
141 0.00000363 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: S
142 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
143 0.00039251 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: .....
144 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
145 0.00035032 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: .....
146 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
147 0.00035815 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: .....
148 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
149 0.00036709 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: ..'..
150 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
151 0.00036094 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: .....
152 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
153 0.00031987 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 5: .....
154 0.00000307 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
155 0.00043749 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
156 0.00000335 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
157 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
158 0.09814823 javaw.exe IRP_MJ_READ USBSER000 TIMEOUT Length 0:
159 0.00000363 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
160 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
161 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
162 0.00000279 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
163 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
164 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
165 0.00000447 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
166 0.10928707 javaw.exe IRP_MJ_READ USBSER000 TIMEOUT Length 0:
167 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
168 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
169 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
170 0.00000279 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
171 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
172 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
173 0.00000447 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
174 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
175 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
176 0.00000223 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
177 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
178 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
179 0.00000447 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
180 0.10926277 javaw.exe IRP_MJ_READ USBSER000 TIMEOUT Length 0:
181 0.00000363 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
182 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
183 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
184 0.00000223 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
185 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
186 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
187 0.00000419 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
188 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
189 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
190 0.00000251 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
191 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
192 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
193 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
194 0.04565999 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: .
195 0.00000363 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
196 0.00024221 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: .
197 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
198 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
... lots of the same last 3 lines repeated..
370 0.00000363 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: .
371 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
372 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
373 0.00000335 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: .
374 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
375 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
376 0.00000363 javaw.exe IRP_MJ_READ USBSER000 SUCCESS Length 1: .
377 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
379 0.00000307 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
380 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
381 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
382 0.00000251 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
383 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
384 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
385 0.00000363 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
386 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
387 0.00000307 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
388 0.00000251 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
389 0.00000251 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
390 0.00000223 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
378 0.00000279 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
391 0.00021735 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
392 0.00000279 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
393 0.00016063 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
394 0.00000223 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
395 0.00021316 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
396 0.00000196 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
397 0.00021986 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
398 0.00000196 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
399 0.00021679 javaw.exe IRP_MJ_WRITE USBSER000 SUCCESS Length 1: .
400 0.00000223 javaw.exe IOCTL_SERIAL_SET_WAIT_MASK USBSER000 SUCCESS Mask: TXEMPTY
401 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
402 0.00000223 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
403 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
404 0.00030758 javaw.exe IOCTL_SERIAL_CLR_DTR USBSER000 SUCCESS
405 0.00000196 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
406 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
407 0.00000196 javaw.exe IOCTL_SERIAL_GET_MODEMSTATUS USBSER000 SUCCESS
408 0.00000196 javaw.exe IOCTL_SERIAL_GET_COMMSTATUS USBSER000 SUCCESS
409 0.00030730 javaw.exe IOCTL_SERIAL_CLR_DTR USBSER000 SUCCESS
410 0.00000196 javaw.exe IOCTL_SERIAL_CLR_RTS USBSER000 SUCCESS
411 0.00000223 javaw.exe IRP_MJ_CLEANUP USBSER000 SUCCESS
412 0.00036625 javaw.exe IRP_MJ_CLOSE USBSER000 SUCCESS


-Crawford
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: LukeS on May 27, 2010, 11:04:04 pm
I was able to update the FPGA rom bit stream but am not able to update the PIC.. here are the errors

Code: [Select]
C:UsersLukeDesktopLSv0.4>fw_update -e -w -m flash -vid 0x04D8 -pid 0xFC90 -ix OLSv1-firmware-v04.hex
U2IO flash erasing: FAILED.
Device is not found.
Operation aborted.

C:UsersLukeDesktopLSv0.4>pause
Press any key to continue . . .

It is on COM9 but how do I specify that to the fw_update.exe

Also what is the run_java_client.bat for, this is not mentioned in the tutorials?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 28, 2010, 12:18:47 am
@LukeS

The run_java_client.bat was just meant as a quick way to show people how to run a jar from the command line if they do not already know. I had to google it the first time.

Jack.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: LukeS on May 28, 2010, 12:21:48 am
@jack,
Do we need to use the analyzer.jar file and any idea on the PIc firmware update issue?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 28, 2010, 01:13:46 am
@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.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: LukeS on May 28, 2010, 01:57:21 am
Thanks swiss mac for the response, I tried put the board into boot mode with the pump-loader tool and with jumping PGC and PGD pins.  Both work and the ACT is on... I think I found the problem but have no idea how to fix it.

When I power on the device in boot mode after updating the FPGA firmware windows is unable to assign the device a COM port.  If I remove the jumper on the PGC and PGD pins windows assigns the OBLS to COM 9 no problem.  Attached is a picture of my device manage with the board in boot mode.

I have only updated the FPGA as stated in step 1 on the blog post but figured I would try the new drivers listed here with version 0.4 of the PIC firmware, that did nothing.

EDIT: GOT IT!! To others that have issues, make sure you remove ALL other attached USB devices except the essentials like the mouse and keyboard.  Some USB device was not playing nice with the fw_update.exe program
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on May 28, 2010, 08:07:53 am
Jack and Ian thanks for the latest updates (bitstream release 2.03 and 2.04 and firmware v0.4)!

I have updated my boards to firmware v0.4 and bitstream releases 2.03 and 2.04 and both versions work well. I encountered no communication problems so far.

One important hint to all who want to upgrade to release 2.04: make sure you install OLSv1-firmware-v4.hex (http://http://dangerousprototypes.com/forum/index.php?topic=580.0) (and not the firmware that comes with the 2.04TestRelease.zip package!!!). With firmware v0.2 and firmware v0.3 none of my boards would communicate with the (new) SUMP Java client when bitstream release 2.04 was loaded (I always got the "Device not found" message).

Firmware v04 was released by Ian (http://http://dangerousprototypes.com/forum/index.php?topic=580.0) after Jack put the 2.04TestRelease.zip package up!

Tested the test mode in release 2.04 (see below) and the inside and outside number schemes but I have not tested the 8k option (with channel groups 3 and 4 disabled!) yet.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 09:56:31 am
@LukeS -

Quote
It is on COM9 but how do I specify that to the fw_update.exe

The bootloader actually appears as a USB HID device, not a serial port. The normal mode and ROM update mode appear as a serial port.

@swissMac -

Quote
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.

That is consistent with the Windows version. My guess is that SUMP only scans for serial ports at startup. The windows version doesn't ever refresh the list so a new device won't even show up.

@crawford - thanks for the debug output. There may be a HEX format display setting that's disabled in your portmon, I don't see any non-ASCII values in the output. We can infer a lot anyways, maybe jack can comment too:

Code: [Select]
119   0.00028300   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .   
120   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
121   0.00030367   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
122   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
123   0.00033468   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
124   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
125   0.00038161   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
126   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
127   0.00031065   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
128   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
129   0.00032965   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
130   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   

First the port is setup and opened. In this section I guess the SUMP client sends 0 0 0 0 2 to get the ID. The FPGA responds:

Code: [Select]
131   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS      
132   0.00000391   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: 1  
133   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
134   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
135   0.00000335   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: A  
136   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
137   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
138   0.00000307   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: L  
139   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
140   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
141   0.00000363   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: S  
142   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
14

The FPGA responds 1ALS. This is correct. So now we know the problem isn't a bitstream that doesn't communicate, it's another issue. I guess we knew that from the Java output before, but this is even stronger evidence.

Code: [Select]
143   0.00039251   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: .....   
144   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
145   0.00035032   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: .....  
146   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
147   0.00035815   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: .....  
148   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
149   0.00036709   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: ..'..  
150   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
151   0.00036094   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: .....  
152   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
153   0.00031987   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 5: .....  
154   0.00000307   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
155   0.00043749   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
156   0.00000335   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   

Now the SUMP client sends the six 5byte setup commands and the 1byte trigger command. We can't see the values, which is unfortunate, but we can assume for now that they are the same as the values from the Java debug:

Code: [Select]
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: 10
10000010 00000010 00000000 00000000 00000000

These are the settings that configure channels and stuff.

Code: [Select]
158   0.09814823   javaw.exe   IRP_MJ_READ   USBSER000   TIMEOUT   Length 0:    
159   0.00000363   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
160   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
161   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
162   0.00000279   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
163   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
164   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
165   0.00000447   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
166   0.10928707   javaw.exe   IRP_MJ_READ   USBSER000   TIMEOUT   Length 0:   
167   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
168   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
169   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
170   0.00000279   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
171   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
172   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
173   0.00000447   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
174   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
175   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
176   0.00000223   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
177   0.00000196   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
178   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
179   0.00000447   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
180   0.10926277   javaw.exe   IRP_MJ_READ   USBSER000   TIMEOUT   Length 0:   
181   0.00000363   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
182   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
183   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
184   0.00000223   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
185   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
186   0.00000196   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
187   0.00000419   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
188   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
189   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
190   0.00000251   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
191   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
192   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
193   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     

The IRP_MJ_READ   USBSER000   TIMEOUT   Length 0:  are reads from OLS that timeout because there's no data. This is OK, this happens while the OLS is waiting for a trigger or capturing data.

Code: [Select]
194   0.04565999   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: .   
195   0.00000363   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
196   0.00024221   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: .  
197   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
198   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
... lots of the same last 3 lines repeated..
370   0.00000363   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: .  
371   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
372   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
373   0.00000335   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: .  
374   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
375   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
376   0.00000363   javaw.exe   IRP_MJ_READ   USBSER000   SUCCESS   Length 1: .  

Here the SUMP client has the first successful read, and then continues to read out the samples. It would be nice to see the sample data, and it would be helpful to know exactly how much data was read. I guess 198-370/3 is about 57 + the 5 we see is around 64 samples.

Code: [Select]
377   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS      
379   0.00000307   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
380   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
381   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
382   0.00000251   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
383   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
384   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
385   0.00000363   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
386   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
387   0.00000307   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
388   0.00000251   javaw.exe   IOCTL_SERIAL_GET_MODEMSTATUS   USBSER000   SUCCESS     
389   0.00000251   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
390   0.00000223   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
378   0.00000279   javaw.exe   IOCTL_SERIAL_GET_COMMSTATUS   USBSER000   SUCCESS     
391   0.00021735   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
392   0.00000279   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
393   0.00016063   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
394   0.00000223   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
395   0.00021316   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
396   0.00000196   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
397   0.00021986   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
398   0.00000196   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   
399   0.00021679   javaw.exe   IRP_MJ_WRITE   USBSER000   SUCCESS   Length 1: .  
400   0.00000223   javaw.exe   IOCTL_SERIAL_SET_WAIT_MASK   USBSER000   SUCCESS   Mask: TXEMPTY   

Here's the weird part. If it were a timeout error, I'd expect a place where the SUMP client reads and the read times out. It would look like the previous IRP_MJ_READ   USBSER000   TIMEOUT   Length 0:  . Instead, SUMP just stops reading, sends 0 0 0 0 0 to reset, and closes the port. That is all normal behavior for a capture, but something is aborting it, maybe in the Java client?

Can you try with the .net client from the forum http://dangerousprototypes.com/forum/in ... opic=564.0 (http://dangerousprototypes.com/forum/index.php?topic=564.0) and see if you get the same results?

I'll make a new firmware that stuffs more data in a single USB packet, maybe that will help feed any sensitive rxtx drivers a bit better.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 09:59:44 am
A note on Portmon: you can put the filter *WRITE;*READ in the include box at startup for less verbose output. You might miss something more detailed, but it's helpful for a first pass.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 28, 2010, 03:21:18 pm
@ian
looks like the 1st capture under OSX always fails with 'device not found', thereafter its OK

needed to use the camera this morning so took some 'additional feel good shots'
/mac


edit+ still with Firmware 04
exception generated with OSX after startup fail then  successful read/capture

mini:SumpJavaClient minimac$ 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-Modemklo
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)
Run started
Device ID: 0x7803
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)
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)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 03:43:31 pm
Thanks swissMac - can you please post the java debug output from the device not found runs?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 04:27:30 pm
Here's v05 and v06 firmware to test (moved to here: http://dangerousprototypes.com/forum/in ... 85#msg5285 (http://dangerousprototypes.com/forum/index.php?topic=576.msg5285#msg5285)).

v05 adds priority for reading data from FPGA. This fixes missed bytes when read flag is high but PIC hits the write loop. This was never a problem because SUMP and the OLS never talk at the same time, but it should guarantee against unpredictable behavior. (see attached image, the string used to return ALS because the 1 was lost while the second 0x02 was written) Also eliminates a potential buffer overflow (though never observed)

v06 adds a loop to the FPGA read. As long as the FPGA has data to read and there is buffer space, the PIC will read from the FPGA. At the end a full packet of 64 bytes will be sent, this will speed up data dumps a lot by better filling USB packets.

There are two consequences in v06. [s:]A cancel command (or any bytes) sent from the USB to the OLS will be ignored until the read flag on the FPGA is cleared and it can be clocked in.[/s:] (EDIT: looks like that's the way the FPGA behaves.) Second, depending on how fast the FPGA clears and sets the read flag we may need to finesse the timing to get rid of phantom bytes. Give it a test an let me know how it works for you.

EDIT: I attached an 'a' revision. I think the first may have the internal version numbers swapped, not sure. Just to be sure, here's a fresh compile.

EDIT 2: Sorry, I messed up when I reverted the v0.7 changes and recompiled. See my next post below this one for a -b revision release of v05 and v06.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 04:38:02 pm
[s:]Here's an untested v7 that takes it a step further and implements bi-directional transfers during SPI reads. That eliminates problem of the v05/v06 firmware not passing a cancel command during a download, for example.[/s:]

Never mind, it doesn't like that.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on May 28, 2010, 04:56:55 pm
Uhhh, what's wrong with it ... OLSv1-firmware-v07-20MHz.hex worked just fine for me - at least in Test mode

Code: [Select]
;Size: 191
;Rate: 100000000
;Channels: 32
;EnabledChannels: 65535
;CursorEnabled: false
;CursorA: 0
;CursorB: 0
;Compressed: true
;AbsoluteLength: 2048
00005555@0
00004001@16
00000000@17
00005555@32
00004001@48
00000000@49
00005555@64
00004001@80
00000000@81
00005555@96
00004001@112
00000000@113
00005555@128
00004001@144
00000000@145
00005555@160
0000eaab@176
0000aaaa@177
0000ffff@192
0000eaab@208
0000aaaa@209
0000ffff@224
0000eaab@240
0000aaaa@241
0000ffff@256
0000eaab@272
0000aaaa@273
0000ffff@288
0000eaab@304
0000aaaa@305
0000ffff@320
0000eaab@336
0000aaaa@337
0000ffff@352
0000eaab@368
0000aaaa@369
0000ffff@384
0000eaab@400
0000aaaa@401
0000ffff@416
0000eaab@432
0000aaaa@433
0000ffff@448
0000eaab@464
0000aaaa@465
0000ffff@480
0000eaab@496
0000aaaa@497
0000ffff@512
0000eaab@528
0000aaaa@529
0000ffff@544
0000eaab@560
0000aaaa@561
0000ffff@576
0000eaab@592
0000aaaa@593
0000ffff@608
0000eaab@624
0000aaaa@625
0000ffff@640
0000eaab@656
0000aaaa@657
0000ffff@672
0000eaab@688
0000aaaa@689
0000ffff@704
0000eaab@720
0000aaaa@721
0000ffff@736
0000eaab@752
0000aaaa@753
0000ffff@768
0000eaab@784
0000aaaa@785
0000ffff@800
0000eaab@816
0000aaaa@817
0000ffff@832
0000eaab@848
0000aaaa@849
0000ffff@864
0000eaab@880
0000aaaa@881
0000ffff@896
0000eaab@912
0000aaaa@913
0000ffff@928
0000eaab@944
0000aaaa@945
0000ffff@960
0000eaab@976
0000aaaa@977
0000ffff@992
0000eaab@1008
0000aaaa@1009
0000ffff@1024
0000eaab@1040
0000aaaa@1041
0000ffff@1056
0000eaab@1072
0000aaaa@1073
0000ffff@1088
0000eaab@1104
0000aaaa@1105
0000ffff@1120
0000eaab@1136
0000aaaa@1137
0000ffff@1152
0000eaab@1168
0000aaaa@1169
0000ffff@1184
00000000@1201
00005555@1216
00004021@1232
00000000@1233
00005555@1248
00004021@1264
00000000@1265
00005555@1280
00004021@1296
00000000@1297
00005555@1312
00004021@1328
00000000@1329
00005555@1344
00004021@1360
00000000@1361
00005555@1376
00004021@1392
00000000@1393
00005555@1408
00004021@1424
00000000@1425
00005555@1440
00004021@1456
00000000@1457
00005555@1472
00004021@1488
00000000@1489
00005555@1504
00004021@1520
00000000@1521
00005555@1536
00004021@1552
00000000@1553
00005555@1568
00004021@1584
00000000@1585
00005555@1600
00004021@1616
00000000@1617
00005555@1632
00004021@1648
00000000@1649
00005555@1664
00004001@1680
00000000@1681
00005555@1696
00004001@1712
00000000@1713
00005555@1728
00004001@1744
00000000@1745
00005555@1760
00004001@1776
00000000@1777
00005555@1792
00004001@1808
00000000@1809
00005555@1824
00004001@1840
00000000@1841
00005555@1856
00004001@1872
00000000@1873
00005555@1888
00004001@1904
00000000@1905
00005555@1920
00004001@1936
00000000@1937
00005555@1952
00004001@1968
00000000@1969
00005555@1984
00004001@2000
00000000@2001
00005555@2016
00004001@2032
00000000@2033

Forget about the glitches ... I am testing cables/clips for crosstalk etc. ... it has nothing to do with the v07 PIC code
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 05:16:36 pm
Quote
Uhhh, what's wrong with it ... OLSv1-firmware-v07-20MHz.hex worked just fine for me - at least in Test mode

It should work fine as long as SUMP doesn't send bytes while the FPGA is being read. I thought the FPGA would accept input bytes while the read flag is high, that does not appear to be the case. The bytes sent with the bidirectional code in v0.7 are lost. Compared to the test shown in the image attached to my previous post, the second 0x02 is missed entirely and only one 1als is returned.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: phdussud on May 28, 2010, 06:34:17 pm
Both new versions (0.5, 0.6) of the firmware result in no communication with the device.... V0.4 works fine for me.
Here is the stack trace from analyzer:
Attaching to: COM6 (115200bps)
Run started
Device ID: 0x7f7f7f7f
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Unknown Source)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 28, 2010, 07:14:00 pm
Sorry about that. I messed something up when I recompiled. Here's a fresh compile without the error.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on May 28, 2010, 07:21:34 pm
ok, but I think it doesn't really matter as long as the client does not send commands (except for reset) while the SUMP samples and transmits the sampled data. Btw., XON/XOFF may have been removed in the latest SUMP version (0.7) ...

Quote
quoted from "FPGA VHDL Model" (http://http://www.sump.org/projects/analyzer/fpga/)
EIA232
Allows to communicate with the core using a EIA232/RS232 interface. The module (de-)serializes commands and data and handles the XON/XOFF commands, which - up to version 0.6 - were detected by the decoder (see core).

Will take a look at the corrected v0.5 and v0.6 now - thnx :)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: phdussud on May 28, 2010, 07:58:35 pm
Ok, I can communicate. Like with the version 0.4, I don't see any error but I occasionally see this error *after* the communication is over(I assume it is a client problem):
Attaching to: COM6 (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: 10000110010
10000010 00110010 00000100 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: jack.gassett on May 28, 2010, 08:16:16 pm
For the record, I disabled the XON/XOFF commands in the SPI interface.

Jack.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 28, 2010, 09:42:36 pm
firmware 05
XP works!
OSX works but a bit flaky :

XP:

14-b08bin>java -jar  analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM1
COM11
Device Controller found: org.sump.analyzer.device
COM1
COM11
Device Controller found: org.sump.analyzer.device
Device Controller = FPGA Controller
Tool found: org.sump.analyzer.tools.I2CProtocolAn
Tool found: org.sump.analyzer.tools.SPIProtocolAn
Tool found: org.sump.analyzer.tools.StateAnalysis
Tool found: org.sump.analyzer.tools.UARTProtocolA
Attaching to: COM11 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed
Attaching to: COM11 (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: 10
10000010 00000010 00000000 00000000 00000000
Run completed
Attaching to: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed
Attaching to: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed


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)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 28, 2010, 09:52:27 pm
firmware06

XP raises exceptions :
OSX behaves similar to firmware 5 initial capture fails subsequent captures work, but all raise exceptions


XP:device always found
_14-b08bin>java -jar analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM1
COM11
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM1
COM11
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: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)
Attaching to: COM11 (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 00000011 11111111 00000011
Flags: 10000000010
10000010 00000010 00000100 00000000 00000000
Run completed
java.lang.InterruptedException
        at java.lang.Object.wait(Native Method)
        at java.lang.Thread.join(Unknown Source)
        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(FpgaDeviceControll
er.java:559)
        at java.lang.Thread.run(Unknown Source)

OSX: initial capture generates device not found
 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: 0x107f
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)
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 00000011 11111111 00000011
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)

(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 00000011 11111111 00000011
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 00000011 11111111 00000011
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)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: amramsey on May 29, 2010, 12:12:02 am
I just upgraded mine to PIC bootloader OLSv1-bootloader-v1.hex, PIC firmware OLSv1-firmware-v06-20MHz.hex, and the FPGA version 2.04TestRelease. My unit appeared to have a bootloader in it but wouldn't let me program it so I flashed the bootloader on with my pickit2. I uninstalled the detected USB device and reinstalled using the inf files included in the OLSv1-firmware-v04 firmware bundle.

I'm not 100% sure how to upgrade the java application. I simply copied the newer analyzer.jar file from the 2.04TestRelease archive over the old OB_Logic_Sniffer_CVS_Sep262008 installation of the java app. Didn't get any new options but it seemed to work ok.

I'm using XP on an old Toshiba laptop. The logic analyzer is connected to the laptop through an Elecom USB hub. Everything seems to be running fine for me. The only problem I see is RLE still only works when all 32 bits are enabled. Not a big deal right now for me.

That being said, the unit was working for me as shipped from Seeedstudios so I may have been one of the lucky ones right from the start.

** Note : if there is anyone in Ottawa that needs a bootloader programmed, I can give them a hand
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 29, 2010, 12:15:55 am
Quote
Device ID: 0x1e0003f

Thanks for the multi-platform update.

I'd be really interested to see a total capture of the Mac port for the first and second run. The client reads this both times. It should get 1ALS (0x534c4131), but it gets something else. I'm not even sure what would cause the OLS to output these bytes, so I wonder if the SUMP client or Mac rxtx are not clearing the buffer and it gets the wrong reply. The best way to tell would be a portmon like log, but I have no idea how to do that on a Mac.

I'm not familiar enough with the Java client to know what the exceptions are. Does anyone understand them?There is certainly the possibility of returning extra bytes or something because of the timing on the read loop. It may need to be adjusted. Could you please capture a run with 0.6 with portmon and post it here. I'll take a look and see if I can tell what's happening. Is anyone else seeing this with v0.6?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: Sjaak on May 29, 2010, 12:30:13 am
If you still run the .exe it will not execute the new jar. It posted this workaround in an other topic:

Quote
The simplest way to use the new client is to download and extract the BFP_Logic_Analyzer_1.0.zip from the gadgetfactory.com and copy the new analyzer.jar into this extracted directory (in my case  D:BFP_Logic_Analyzer_1.0 ). [s:]I also renamed the analyser.jar to analyzer2.jar[/s:]. I run the updated client with this command from a cmd-box:


Code: [Select]
D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jar analyzer2.jar
Linux/mac/bsd/* should be simular ( s/\/ //g ).


BTW: the rle does only work with 32bit streams
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: sdixon on May 29, 2010, 02:55:24 am
[quote author="Sjaak"]
If you still run the .exe it will not execute the new jar. It posted this workaround in an other topic:

Quote
The simplest way to use the new client is to download and extract the BFP_Logic_Analyzer_1.0.zip from the gadgetfactory.com and copy the new analyzer.jar into this extracted directory (in my case  D:BFP_Logic_Analyzer_1.0 ). I also renamed the analyser.jar to analyzer2.jar. I run the updated client with this command from a cmd-box:


Code: [Select]
D:BFP_Logic_Analyzer_1.0>jre1.6.0_14-b08binjava -jar analyzer2.jar
Linux/mac/bsd/* should be simular ( s/\/ //g ).


BTW: the rle does only work with 32bit streams
[/quote]

I put a note in another thread (http://dangerousprototypes.com/forum/in ... 08#msg5308 (http://dangerousprototypes.com/forum/index.php?topic=582.msg5308#msg5308)) regarding renaming analyzer.jar to any other name.  Basically, you need to change the Java code if you use any name other than analyzer.jar since the code explicitly opens that file while starting up.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: swissMac on May 29, 2010, 03:23:28 am
sniffing ports on OSX
http://homepage.mac.com/chen/w7ay/Seria ... index.html (http://homepage.mac.com/chen/w7ay/Serial%20Tools/index.html)

I'm going to try this tomorrow, will post findings with  OSX  and XP (using portmon)

EDIT
couldn't get the monitor software to monitor without breaking the connection between the OLS :-(
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 29, 2010, 08:13:21 pm
The java exception is a standard runtime exception that says the blocking call was interrupted by another thread.  This means that the thread in the rxtxeventlistener, was interrupted by another thread calling interrupt on it. I have assumed it was a race with the device close.  From the the stack in question a thread blocked on a mutex.  The sequence being close was called from detach and it is removing an event listener that appears to be a thread that is waiting to be notified.  This could be as simple as adding a catch for Interrupted in the try catch around the wait, but it looks like another thread is using interrupt when this thread expected to be notified instead.

Can't test anything at the moment, but if you want I will dive into the code tomorrow or monday.  Java is old school for me.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 29, 2010, 08:42:30 pm
Is the sump.org code base the one is use, or is there a separate repository I should grab it from?  The sources from sump.org don't match the stack traces.  FpgaDevice has change from the stack traces reported here and what is in the source pool there.  The line numbers are off by 35 or more lines.

Looking at the RXTX sources I suspect that multiple threads are closing the port or ports associated with the same PID at the same time.  I am not sure of the relationship of what RXTX calls a PID and the usb PID, I am doubting they are the same.  In short the detach is waiting for a monitoring thread rxtx created to exit, and while waiting someone else in the rxtx libraries interrupts the waiting thread.  Most of the places the interrupt could be coming from is a native method called interrupteventloop, or a termios method of a similar name.  The raw class also class interrupt, so I am not sure which is triggering it.  Debugging multiple thread signaling issues is worse in software than hardware, as any thing you do to monitor disturbs the test.  My guess is that this interrupt should be ignored in the module that catches it, and as a consequence shutdown may not be as orderly as it should be.  (A monitor thread might not be finished before the close returns.  The worst case this could do, as far as my quick analysis is cause a too many event listener error if it was reopened too quickly.  This code is pretty convoluted, but the exception is a very common one I am very familiar with.  Java exceptions and the like are a large part of my day job the last 10 years or more.

[quote author="ian"]
Quote
Device ID: 0x1e0003f

...

I'm not familiar enough with the Java client to know what the exceptions are. Does anyone understand them?There is certainly the possibility of returning extra bytes or something because of the timing on the read loop. It may need to be adjusted. Could you please capture a run with 0.6 with portmon and post it here. I'll take a look and see if I can tell what's happening. Is anyone else seeing this with v0.6?
[/quote]
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on May 30, 2010, 12:22:13 am
rhyde, the latest SUMP Java client was compiled by Jack. Jack implemented some extra features and commands to

a) select Test Mode

b) switch between 32 channel (up to 4k samples) and 16 channel (up to 8k samples) scans - 32 channels are activated in the capture setup by selecting/checking channel groups 0, 1, 2 and 3, 16 channels are activated by selecting/checking channel groups 0 and 1 only.

For the latest bitstream (release 2.04) the new SUMP Java client (included in 2.04TestRelease.zip (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=576.0;attach=816)) and firmware v0.4 (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=576.0;attach=832) (or newer) must be used.

The source for the latest SUMP Java client is available from Jacks SVN repository: svn checkout http://www.gadgetfactory.net/svn/butter ... lient_Sump (http://www.gadgetfactory.net/svn/butterflylogic/trunk/Java_Client_Sump) (user: 'anonymous', no passwd).
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alanbur on May 30, 2010, 01:09:55 am
I've upgraded to the 2.04 bits and my hitherto flaky as hell OLS is now rock solid - the SPI comms change seems to be a big step forwards.

One thing: It would be really nice if the Java client limited you to only the buffer sizes that are valid.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on May 30, 2010, 05:15:57 am
Thanks for the pointer.  From what I say in my dive into the code the exception is completely within the rxtx library, although sump could be triggering it by doing multiple closes on different threads.  Given what I could see of the old structure the only likely reasonable way sump would trigger this is if it detached  and reattached instantly or back to back as the rxtx driver is kinda globally going for connections in its hash table.  It has been awhile since I dealt with mach drivers so I can not recall if its scope is global or process limited.  That would resolve the question finally.  Given it is a non error exception in the close path, I would ignore it.  The exception is part of java's broken/poorly thought out set of runtime, informational, and error exception mess that is most visible in the IO facilities.  But generally causes shouts of pin head losers from my friends who deal with it daily.  (They may be the best pin head loser around that they let me use professional, but unless you compare java with C#, that is what they are.  If you compare the two they java dudes are years ahead and more together, but frankly that is easy enough to do given the competition.)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: robots on May 30, 2010, 11:48:38 am
There seems to be some problem with rapid restarting of capture. (FW 0.6, Bitstream 2.04).

If I restart the capture at rate of ~2-3 seconds it forks ok. If I want to capture sooner than 2seconds I get "Device not found" - retrying after second works.

Is it something related to the buffer filling in FW ?  (where the FW would still be waiting for data, and not receiving commands) Or some delay in FPGA? (not reseting from the sending mode fast enough)
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: LourensK on May 30, 2010, 08:20:40 pm
Just tried OLS in an live i2c environment (FW:06  and testrelease 2.04)

Working like a charm but the first one or two captures are wrong, after these the OLS is capturing i2c data repeadetly OK ! (see screen shots)

settings:
1 MHz sampling rate
32 bits
4 k recording size
Noise filter enable
RLE enable (same results with RLE disable)
Trigger 0/100 on CH0 (SDA) going to zero
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: terrymeyer on May 31, 2010, 04:45:07 pm
@Jack: Reply#4
@Ian: Reply #7

Thank you for your ideas. I have not been back here since Tuesday (see below).

Summary:
Where in the US can I order an OLS with the latest stable release (ROM and FW) that includes a bootloader?
Do I need a BL or do I want a Bus Pirate instead?
It appears there is a HW rev coming...true?

-------------------------------------------------------------------------
Detail:
Shortly after you responded Tuesday, I updated that evening (don't remember the version). The 1st thing was to look at I2C. The readings were much improved. But about 30 seconds into the session my home made 12V/5V P/S, started to crackle and smoke. Before I could yank any cable, the short fried the P/S, the OLS and the two USB ports on my T42 laptop. The breadboard circuit where the I2C readings originated was not harmed (?)    

This is not to imply the OLS is at fault. But I wondered, why would an admittedly home made P/S that has worked flawlessly for months, spark 30 seconds after being attached via circuitry to a device with a recent rev?
P/S<---->Breadboard<----->OLS<------>Laptop

I decided that keeping up with the OLS updates was outside my scope (N-P-I) and have looked at Saleae, ZeroPlus, USBee, etc. While trolling Hack-A-Day, I came across the concept of a “USB Isolator”. http://www.circuitsathome.com/mcu/usb/usb-isolator (http://www.circuitsathome.com/mcu/usb/usb-isolator). The author talks about scopes and LAs and ground loops.

So maybe I’m not crazy, or maybe there was a design flaw in my simple LM7805/12 board, or both.
Once again, no finger points, just data.

Hmmm…just found this thread: “Logic Sniffer v1.03 manufacturing update”

I actually thought about posting this issue Tuesday night as a warning to others. But because I could not state for-a-fact that the P/S was not at fault and had simply failed coincidently, no post was made.

I respect the Open Source mindset, but I really do not know what I am doing regarding the updates. It is unclear to me if I updated just the ROM or the ROM and FW. The updates work(ed) with the jumper installed. Does that mean my card had a bootloader?

And, maybe part of the cost of playing in the Open Source sandbox is the time one puts into make things work.
Seriously, would I be better off with a Saleae?

All thoughts welcome.

Thanks for reading….

Terry
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on May 31, 2010, 06:23:09 pm
Hi Terry - I'm sorry you had problems with your OLS.

[quote author="terrymeyer"]
Where in the US can I order an OLS with the latest stable release (ROM and FW) that includes a bootloader?
Do I need a BL or do I want a Bus Pirate instead?
It appears there is a HW rev coming...true?
[/quote]
In principal there is nowhere in the US to order an OLS. Sparkfun will have a few soon, but no guarantees on any versions of anything.
From your upgrade experience it sounds like bootloader was present. We're just making a Bus Pirate update utility because a lot of people have both so it's an easy way to do the repair. I'd say there's no reason to get a Bus Pirate.
There is a manufacturing update coming. This will have very minor tweaks to make it easier to manufacture and quality control, but nothing that effects features or reliability.

Quote
But I wondered, why would an admittedly home made P/S that has worked flawlessly for months, spark 30 seconds after being attached via circuitry to a device with a recent rev?

Hmmm…just found this thread: “Logic Sniffer v1.03 manufacturing update”

I'm sorry to hear about your loss. I'd need to hear more about the setup to be sure.

Aside from something metal making contact and shorting the power supply to ground through the OLS, I'm not sure how the OLS would be involved in a catastrophic failure. The buffered inputs are very well protected and high-impedance.  The inputs are usually connected to logic signals that are limited to pin output currents (<25ma) - you mentioned I2C which is through pull-up resistors and a few mA max. There are no voltage output pins on the OLS, but most USB ports are current-limited and won;t die from a simple short. The OLS is only a 3.3 volt system, but USB power is 5volts so even connecting the 5volt supply to the USB supply shouldn't be an 'instant death' situation.

Ground loops are a possibility, I've never run into them, maybe someone else can elaborate on that. I know of galvanically isolated USB hubs that can be used in these situations.

I certainly understand your concern about the upcoming manufacturing revision, but it is only a minor update to improve production yields and ease testing for Seeed. There aren't any changes to the existing circuit or layout, new features, or other major updates.

Quote
I actually thought about posting this issue Tuesday night as a warning to others. But because I could not state for-a-fact that the P/S was not at fault and had simply failed coincidently, no post was made.

Please never hesitate, we need all the feedback we can get.

Quote
It is unclear to me if I updated just the ROM or the ROM and FW. The updates work(ed) with the jumper installed. Does that mean my card had a bootloader?

Both the firmware and ROM should be updated. If the firmware update worked with the jumper then the bootloader was installed. You can (could) see the bootloader status in the ROM update step. The upgrade guide is here:
http://dangerousprototypes.com/2010/05/ ... rs-needed/ (http://dangerousprototypes.com/2010/05/26/logic-sniffer-major-update-testers-needed/)

Quote
I decided that keeping up with the OLS updates was outside my scope (N-P-I) and have looked at Saleae, ZeroPlus, USBee, etc. And, maybe part of the cost of playing in the Open Source sandbox is the time one puts into make things work.
Seriously, would I be better off with a Saleae?

It sounds like you're looking for a polished consumer product instead of an experimental prototype. I'm sorry the OLS wasn't what you were looking for. We'll keep working on it and maybe we can make it a more polished experience in the future. Thanks so much for your feedback and honesty.

There's a lot of good hardware out there, it looks like you've done your research. I know the ZeroPlus is popular right now, I use the Saleae as an alternative debugger all the time. Which device to get depends on your requirements. The Saleae is a basic 8bit data logger, it takes infinite samples but only works to 12MHz for me (24MHz theoretical max I think). The OLS (and ZeroPlus?) are sampling analyzers that take shorter samples but at much higher speeds. The more you spend, the less you have to trade between storage and speed :)

If you are having ground loop problems be sure to check if the Saleae, USBee, and ZeroPlus have some form of USB galvanic isolation. I took my Saleae apart and don't remember seeing anything (it doesn't have an external supply either), but I'm often wrong. I can't comment on the other two devices. You can also check out isolated USB hubs.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alm on May 31, 2010, 11:40:47 pm
[quote author="terrymeyer"]
Shortly after you responded Tuesday, I updated that evening (don't remember the version). The 1st thing was to look at I2C. The readings were much improved. But about 30 seconds into the session my home made 12V/5V P/S, started to crackle and smoke. Before I could yank any cable, the short fried the P/S, the OLS and the two USB ports on my T42 laptop. The breadboard circuit where the I2C readings originated was not harmed (?)    

This is not to imply the OLS is at fault. But I wondered, why would an admittedly home made P/S that has worked flawlessly for months, spark 30 seconds after being attached via circuitry to a device with a recent rev?
P/S<---->Breadboard<----->OLS<------>Laptop

I decided that keeping up with the OLS updates was outside my scope (N-P-I) and have looked at Saleae, ZeroPlus, USBee, etc. While trolling Hack-A-Day, I came across the concept of a “USB Isolator”. http://www.circuitsathome.com/mcu/usb/usb-isolator (http://www.circuitsathome.com/mcu/usb/usb-isolator). The author talks about scopes and LAs and ground loops.

So maybe I’m not crazy, or maybe there was a design flaw in my simple LM7805/12 board, or both.
Once again, no finger points, just data.
[/quote]
I'm really curious about this one. An 78xx is pretty bullet proof, simply shorting them to ground should be fine (they're protected against both over current and over temp). Did you do a post-mortem on the power supply, and find out what's destroyed? Was the 78xx connected to a cheap switcher or to a simple transformer? Was the bridge rectifier too light? The power supply is most suspect in my opinion, since I expect a power supply to survive abuse like shorting, but I don't expect the OLS or USB port to withstand something like 12VAC.

A ground loop doesn't usually destroy stuff, it only induces noise. The most likely to me seems that you shorted something with the clips, or accidentally connected a ground clip to a power supply line. Was there 12V on the board, maybe the buffer shorted when you connected an OLS channel to 12V? Maybe 12V and 5V got shorted, and the reverse current destroyed the 7805? A reverse diode over the 78xx is often included to protect against this.

It seems unlikely that the firmware/bitstream update has anything to do with this, especially for the buffered channels. It's not like the firmware can suddenly make the buffer low-impedance. But anything can fail.

It does suck that it fried the (only?) USB ports on your laptop, since that's the most expensive to replace, although a PC-card USB adapter might be a solution. For that reason, I would always design an isolated USB interface for test equipment, I expect them to be connected to the wrong voltage at some point, and I don't want them to destroy the computer. It's not that hard, just a magnetic coupler device (i.e. AD iCoupler or similar) for the SPI/UART lines, and a separate wall wart (or power supply isolator) for the isolated part. But it would probably add a few dollars in parts.

[quote author="terrymeyer"]
And, maybe part of the cost of playing in the Open Source sandbox is the time one puts into make things work.
Seriously, would I be better off with a Saleae?
[/quote]
More time and hassle is definitely common for an open source project like this, especially a relatively immature one. Destroying hardware isn't usually part of the cost, although it can happen. After some more hardware and software development, it will probably become better. If you want a polished product right now, the Saleae is a good solution, and some day you might even see Mac/Linux support ;). Be sure to try the software before buying, I found the Zeroplus software horrible and the triggering useless, plus I disliked paying lots of money for extra protocols, I want an open architecture. So I got the Saleae logic, although the software is being re-written, so not much software updates the past half year or so.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: terrymeyer on June 01, 2010, 05:16:09 am
@ian / @alm

Thank you both for the responses, and now some good news.

In anger last week I placed the P/S on a shelf just to get it out of my sight. This is an improvement for me, as failed equipment often finds itself across the yard. Maturity paid off.  Wearing a magnifying glass headset, very small bits of copper clad PCB were found in the P/S. Careful inspection did find where the short occurred on the wall wart’s exposed circuitry inside the P/S case. While the 12V supply was not in use, and not hooked up to the bb, it appears that alm’s theory regarding a 12V/5V short is correct. Indeed, the 7812 is cracked in half.

Fearing something like this is why I wanted to be clear the P/S was home made.
It was the coincidence of the FW update and P/S failure that flummoxed me, prompting my post.

So while there has been a loss of $45 for the OLS and $15 for a USB-to-PCCard adapter, I’m way ahead on the sixty bucks.

I’m self taught, so the wide ranging technical detail you both provided in these two posts is very, very helpful. Just the simple statement “A reverse diode over the 78xx is often included to protect against this.”….golden!

I now know of something called “galvanically isolated USB hubs” and why to use them
Direction on the Saleae and Open Source (Bus Pirate too) is comfortably clear.
There’s more, but you get it……and yes, I will treat my P/S builds with more care and respect.

I’ll get the consumer LA for now, and when ready to play in the sandbox again I’ll buy from DP/GF.
The support here is phenomenal.

Many thanks…

Terry
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alm on June 01, 2010, 06:16:03 am
Actually I would expect the 7805 to blow from the connection with the 7812. The 7812 should have no problem with the short circuit, but the 7805 could die from the reverse current. The fact that the 7812 is blown (and the 7805 is not?) suggests to me that something went wrong before the 78xx. My guess would be severe over voltage (>35V), probably because something went wrong in the wal wart, and it put out a rectified 110V/230V. Was the 7805 fed from the same rail? Then it should have died, too. The other option is that the 7812 blew up first, and shorted the wall wart, which subsequently died. But the question would be why the 7812 died, especially if it wasn't connected.

Short of other information, my guess would be that the cheap switcher in the wall wart (assuming it was not linear with a large transformer) somehow became unstable. My suggestion would be to use a simple transformer/rectifier/electrolytics in the future, as long as the bridge rectifier is large enough and you put a fuse on the primary side, this is much more stable and robust than a switcher.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rsdio on June 01, 2010, 07:34:40 am
[quote author="terrymeyer"]I now know of something called “galvanically isolated USB hubs” and why to use them[/quote]
I don't know if this counts for much, but as soon as I started on my first USB design, I went to Frys and purchased a $5 Full Speed USB hub.  It was really a laughable experience, because a couple of employees were really trying to talk me into a $50 High Speed hub, saying that I needed to future-proof my setup.  I tried to explain that all of my drives are FW800, and I wouldn't be buying a USB2 drive any time soon.  Most of all, I tried to explain that I was buying this hub specifically to guard against the risk of burning something out, so the $4.99 was more important than any other feature.

What I don't know is whether this would really protect my computer USB ports from damage. At the very least, it seems like the cheap hub would share the stress and hopefully burn out before my computer.

As for your incident, I suppose it had nothing to do with USB, but it's always worth considering ways that things might go wrong.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alm on June 01, 2010, 09:12:24 am
I can see how a hub might offer some protection, depending on how fast it dies and if it fails open or short circuit. If you buy a really crappy one, it might die really soon, thus protecting your computer ;). A powered hub might be even better, since at least the power line would be isolated from your computer.

Isolated USB hubs seem really expensive (the first one I found was like $300). You could design something yourself with something like the ADUM4160, which is still quite expensive and only does full speed USB, but not $300 ($6.6 for 100 at Digikey and no stock).

The real solution would be to add something like an ADUM1301 or Si8431 to isolate the PIC from the FPGA (SPI is easier and cheaper than USB), and provide separate power (either external wall wart or something like isopower if it can deliver enough current) to the FPGA. In my opinion this is a requirement for any piece of test equipment that's connected to a computer. But that would make it more expensive and increase the size of the PCB.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on June 01, 2010, 10:44:50 pm
First of all, I am very sorry to hear about the damage that was caused to your laptop and OLS while using the OLS.  On the other side I am impressed by your matter-of-factness and candidness  ...

A few days ago, while chatting with Jack (Gassett) and testing the OLS, I connected 3.3V on the SPI-ISP header with GND on the buffered header ... I didn't realize there was a problem before I saw and smelled the smoke rising from the MIC5205-3v3 VR ... the OLS was directly connected to an USB port on my PC, no external hub inbetween ... the VR burned out before I was able to pull the USB cable - total damage: one MIC5205-3v3. No damage to the PC, not even the over current protection of the USB root hub kicked in (according to the USB 2.0 spec the over current protection must be triggered at less than 5A).

Eventhough terrymeyer found the most probable cause for the accident inside his P/S I am mentioning my accident because it shows that even a forced short-circuit on the OLS obviously can't cause damage to a USB hub/controller that complies with the USB specification. However, the whole episode teaches us that using an external (and) powered (!) hub is a good idea not only when using an OLS but whenever using USB connections in an experimental environment! I am not convinced that an isolated hub or in case of the OLS an isolation between the PIC and the FPGA is required unless real high potential differences are to be expected - like when developing/testing buck/booster converters or other AC and high-voltage applications not referenced to ground on the USB device side. Microchip offers the MPLAB REAL ICE Isolator for their MPLAB RAEL ICE debugger/emulator to protect the REAL ICE and the PC against damage in such environments. For PICkit and ICD they don't offer such an option.

Looking at the logic analyzers in the range of up to US$ 400 shown on the sigrok LA software site (http://http://sigrok.org/wiki/Main_Page), I can see no indication for isolation (magnetics or opto-couplers) on any of the boards ... they all draw power from the USB port and show only one power converter/no extra power connector/no visible separation in the PCB layout.

Btw. the sigrok site lists some more interesting LAs than the ones you mentioned ... I'd take a look at the Intronix Logicport (http://http://www.pctestinstruments.com/) ... and if you are willing for some more experiments that can either save you $$$ or send an other LA to te grave check this mod report on the ZEROPLUS Logic Cube LAP-C (http://http://www.openschemes.com/modules/wordpress/2010/03/27/zeroplus-logic-cube-the-modification/). :D

[quote author="alm"]
.... A ground loop doesn't usually destroy stuff, it only induces noise. [/quote]

I am inclined to disagree with the above statement and if only with the implied generalization "it only induced noise". Ground loops

In terrymeyers case the damage was obviously not caused by a ground loop but I have seen quite a few RS232 <--> 20mA converters as well as 20mA and RS232 ports/adapters on RS/6000 system that had fallen victims to ground loops and would keep on getting damaged after they were repaired until they were replaced by opto-isolated converters/transceivers. This happend mostly in huge industrial plants with numerous DNC/CNC controllers, shop floor data collection and time & attendance terminals spread out all over the facility that used 20mA interfaces and shielded telephone wires to communicate with the host (RS/6000). Total cable length was up to a mile but due to the usage of the telephone infrastructure the cabels would not always run directly from the controller/terminal to the host but go through multiple patch panels. At each patch panel the shield of the cable was grounded. While searching for the reasons for the damaged interfaces I touched the at that moment and at my side unconnected shield of the wire and received a strong electric shock, similar to touching a 220VAC power line ... when measuring the voltage, I got a reading of 130V! A thorough test along the full length of the cable showed no damage of the shield (no connection with power lines) but various crossings and parallel traces with 230VAC and 380VAC (3-phase) lines in cable ducts. Furthermore it was established that there were differences in the ground potential between the foundations of the buildings. After replacing the non-isolated 20mA <--> RS232 converters and 20mA adapters on the host side with opto-isolated converters damage by ground loops was eliminated. Only during extreme thunderstorms lightning would occasionally blow opto-couplers chips in the converters.

@rsdio: Unless your $4.99 unpowered hub really burns out before your host's root hub gets effected it will not provide any protection against shorts in the power circuit as unpowered hubs have neither built-in over-current protection nor any protection against overvoltage in the power circuit - they may only protect you against overvoltage on the data lines. As alm said, get an external powered hub it will protect you against shorting the power circuit and the data lines and against overvoltage to the point the isolation of the circuitry including the USB hub chip itself can provide. Opto-isolated hubs make only sense if your circuitry bears the risk of inducing high-voltages into your digital circuitry and the USB power line.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rsdio on June 01, 2010, 11:44:58 pm
[quote author="IPenguin"]@rsdio: Unless your $4.99 unpowered hub really burns out before your host's root hub gets effected it will not provide any protection against shorts in the power circuit as unpowered hubs have neither built-in over-current protection nor any protection against overvoltage in the power circuit - they may only protect you against overvoltage on the data lines. As alm said, get an external powered hub it will protect you against shorting the power circuit and the data lines and against overvoltage to the point the isolation of the circuitry including the USB hub chip itself can provide. Opto-isolated hubs make only sense if your circuitry bears the risk of inducing high-voltages into your digital circuitry and the USB power line.
[/quote]
The $4.99 hub does have external power, but I have not plugged anything into the power jack. My question would be whether the computer is actually isolated from device power when the hub is externally powered, and if so, whether it might be reasonably isolated even when self-powered.

The power jack does have 3 pins, so it could be interrupting the power when there is a plug. However, I don't see a regulator unless the MCU has one built in, so that probably means it's passing raw power down the line.  The weird thing is that it looks like the upstream power connects to the four ports before the power jack, and that the power jack goes nowhere. Maybe it's a power outlet!  In any event, I should probably stop thinking of this thing as any sort of protection.

The moral of the story is that you should examine any powered hub to confirm that power is isolated, at least if you're using it with the intention of protecting against power shorts. The USB universe is full of devices that are not designed to spec, including many examples of devices which place power on the data lines before the device has been enumerated.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alm on June 02, 2010, 12:31:28 am
[quote author="IPenguin"]
A few days ago, while chatting with Jack (Gassett) and testing the OLS, I connected 3.3V on the SPI-ISP header with GND on the buffered header ... I didn't realize there was a problem before I saw and smelled the smoke rising from the MIC5205-3v3 VR ... the OLS was directly connected to an USB port on my PC, no external hub inbetween ... the VR burned out before I was able to pull the USB cable - total damage: one MIC5205-3v3. No damage to the PC, not even the over current protection of the USB root hub kicked in (according to the USB 2.0 spec the over current protection must be triggered at less than 5A).
[/quote]
But you can't expect a computer to be designed with the same protection as lab instruments, some devices use polyfuses (limited lifetime, they become slower with age) or even soldered fuses. Protection is something that can easily skimped on with extremely low margin consumer products.

[quote author="IPenguin"]
I am not convinced that an isolated hub or in case of the OLS an isolation between the PIC and the FPGA is required unless real high potential differences are to be expected - like when developing/testing buck/booster converters or other AC and high-voltage applications not referenced to ground on the USB device side. Microchip offers the MPLAB REAL ICE Isolator for their MPLAB RAEL ICE debugger/emulator to protect the REAL ICE and the PC against damage in such environments. For PICkit and ICD they don't offer such an option.
[/quote]
Not sure if you really need a high voltage to damage a USB root hub. What if it gets +12V or -12V on its signal lines? What are the guaranteed max breakdown voltages? What if you accidentally touch the probe to some other voltage (eg. vacuum fluorescent display), or the power supply of your device shits itself (as in this case) and puts out a high voltage (high enough to kill a 7812)? The fact that you are debugging it means something is not working right, so you should expect more abuse than consumer devices like MP3 players.

[quote author="IPenguin"]
Looking at the logic analyzers in the range of up to US$ 400 shown on the sigrok LA software site (http://http://sigrok.org/wiki/Main_Page), I can see no indication for isolation (magnetics or opto-couplers) on any of the boards ... they all draw power from the USB port and show only one power converter/no extra power connector/no visible separation in the PCB layout.
[/quote]
I think some of them have protection diode arrays and inline resistors (not sure about the rating), but no isolation, that's correct. Fast protection diodes and damping resistors are a probably a reasonable solution, the advantage of magnetic/optical isolation is that you get almost unlimited isolation (a few kV) for not much money (SI8431 is $1.65 for 100 at Mouser, although that doesn't take care of the power). Not sure if I'd consider any of them professional tools, although the LogicPort comes close. I'd expect the $$$ ones from Agilent and Tek to have better input protection, but in that case I probably would be more worried about the analyzer than my PC ;).

[quote author="IPenguin"]
Btw. the sigrok site lists some more interesting LAs than the ones you mentioned ... I'd take a look at the Intronix Logicport (http://http://www.pctestinstruments.com/) ... and if you are willing for some more experiments that can either save you $$$ or send an other LA to te grave check this mod report on the ZEROPLUS Logic Cube LAP-C (http://http://www.openschemes.com/modules/wordpress/2010/03/27/zeroplus-logic-cube-the-modification/). :D
[/quote]
Yeah, the Intronix Logicport is by far the best (not very familiar with the Sigma and XLA) if you want to spend that much and can live with the limited memory (in many cases enough because of the sophisticated triggering). For Zeroplus, make sure that you can stand the software and the lack of custom protocols. Also, they might block the mod in future software versions (which might be required for newer Windows versions).

[quote author="alm"]
In terrymeyers case the damage was obviously not caused by a ground loop but I have seen quite a few RS232 <--> 20mA converters as well as 20mA and RS232 ports/adapters on RS/6000 system that had fallen victims to ground loops and would keep on getting damaged after they were repaired until they were replaced by opto-isolated converters/transceivers. This happend mostly in huge industrial plants with numerous DNC/CNC controllers, shop floor data collection and time & attendance terminals spread out all over the facility that used 20mA interfaces and shielded telephone wires to communicate with the host (RS/6000). Total cable length was up to a mile but due to the usage of the telephone infrastructure the cabels would not always run directly from the controller/terminal to the host but go through multiple patch panels. At each patch panel the shield of the cable was grounded. While searching for the reasons for the damaged interfaces I touched the at that moment and at my side unconnected shield of the wire and received a strong electric shock, similar to touching a 220VAC power line ... when measuring the voltage, I got a reading of 130V! A thorough test along the full length of the cable showed no damage of the shield (no connection with power lines) but various crossings and parallel traces with 230VAC and 380VAC (3-phase) lines in cable ducts. Furthermore it was established that there were differences in the ground potential between the foundations of the buildings. After replacing the non-isolated 20mA <--> RS232 converters and 20mA adapters on the host side with opto-isolated converters damage by ground loops was eliminated. Only during extreme thunderstorms lightning would occasionally blow opto-couplers chips in the converters.
[/quote]
I agree, my generalization was too broad. In industrial environments and with runs between multiple floors/buildings, ground potential differences (not sure if I'd call them loops) can be damaging to even not-so-sensitive equipment (I don't expect an RS-232 to 4-20 converter to be very delicate). It does surprise me that there was enough inductive pickup of those mains lines to induce currents large enough through the shield to create a 130V potential difference, but I guess a few hundred meter of parallel runs makes a pretty good transformer. I was thinking more about ground loops on your workbench, the potential differences are usually below 100mV or so in that case.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: bash on June 02, 2010, 05:57:17 am
[quote author="alm"]
Yeah, the Intronix Logicport is by far the best
[/quote]

I have a Intronix LA1034 , but packed it and use my Saleae to work...  Because Intronix soft is so stupid (like 80´s one) and is very confused for simple things... LA1034 are a very good hardware, but have a very bad soft...

So... today I received my BusPirate and my OSL (YES, I LOVE LAs lol )  and try it some captures... after 1hour testing, I like it... For use when I need travel... nice!
Now upgrade to 2.04 and fw 0.6 to give some help to community..

Ian, nice work brotha ...very nice.. I tried to got a SD card SPI protocol communication and OSL got all bytes...
I see that is more fast with this fw... but got some inconvenient states (got more now with new fw) ... but I try one more time and the capture is nice... (50 different captures... 45 OK - 5 with wrong states...)
But I see some problem here, (I think that I don´t have all knowledge about OSL only in one night hehe) ...
I checked only group 0..( use only 4 channels ( 0 to 3 )) ... checked Noise Filter...Internal 10Mhz.. and selected 2K size capture.. (configure my trigger too) ...
2K size...very good..
but above 2K capture are wrong... show me nothing ! .. What´s wrong? Some configuration that I don´t set?

Congratulations one more time, OSL project have a big future!

Regards

Bash
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on June 02, 2010, 07:26:13 am
[quote author="bash"]
[quote author="alm"]
Yeah, the Intronix Logicport is by far the best
[/quote]

I have a Intronix LA1034 , but packed it and use my Saleae to work...  Because Intronix soft is so stupid (like 80´s one) and is very confused for simple things... LA1034 are a very good hardware, but have a very bad soft... [/quote]

sigrok says they will support the Intronix with their multi-platform software soon ... the bundle Intronix/sirok may give you the total killer LA package in the price range of under US$ 500 ;)

Quote
I checked only group 0..( use only 4 channels ( 0 to 3 )) ... checked Noise Filter...Internal 10Mhz.. and selected 2K size capture.. (configure my trigger too) ...
2K size...very good..
but above 2K capture are wrong... show me nothing ! .. What´s wrong? Some configuration that I don´t set?

FW v0.4 or v0.6/Bitstream rel. 2.04 currently  support only 3 main capture configurations:
   - up to 4k samples for 32 channels
   - up to 8k samples for 16 channels (if channel groups 3 and 4 are disabled in the capture menu)
   - test mode (needs to connect channels on the unbuffered header with channels on the buffered header with patch cables i.e.)

The RLE option does not work properly, captures will show wrong/invalid data.

But that doesn't explain why you will receive only 2K captures ... try to run following capture configuration:

Inside, Internal 10MHz, check only Channel Groups 1 & 2, Recording size 4k (and then 8k), Noise Filter Enable, RLE Disable (!Enable) 

[quote author="alm"]
Not sure if you really need a high voltage to damage a USB root hub. What if it gets +12V or -12V on its signal lines? What are the guaranteed max breakdown voltages? What if you accidentally touch the probe to some other voltage (eg. vacuum fluorescent display), or the power supply of your device shits itself (as in this case) and puts out a high voltage (high enough to kill a 7812)? The fact that you are debugging it means something is not working right, so you should expect more abuse than consumer devices like MP3 players.[/quote]
1. I expect the USB root hub to die when it gets +12V/-12V on the signal lines ... but then the OLS will die first ... the FPGA will for sure if you don't use the buffered header. But then the unbuffered header is actually intended for a wing like a DSO extension and any other protection of the lines but with serial resistors (which is no real protection against cases we talked about) would make it unsuitable for this.
2. Same when you touch VFD power with a probe - VFD voltag is typically over 50V and qualifies for "high-voltage" in the meaning of better using opto-isolated interfaces (not in the meaning of saftey regulations)
3. In the end even the best lab equipment is only protected to certain limits - it's up to the user not to abuse it (like I did) and it's not protected against (possibly) 60-110VAC (or more if the switcher in the wall mart went into resonance before it died) inducted into the circuitry (terrymeyer) because of a failing wall mart - like if you buy a B6 armoured Mercede-Benz GL but drive it over a cliff into an abyss or get run over by a 40 ton truck the armore won't keep it from getting damaged.

Quote
I think some of them have protection diode arrays and inline resistors (not sure about the rating), but no isolation, that's correct. Fast protection diodes and damping resistors are a probably a reasonable solution, the advantage of magnetic/optical isolation is that you get almost unlimited isolation (a few kV) for not much money (SI8431 is $1.65 for 100 at Mouser, although that doesn't take care of the power). Not sure if I'd consider any of them professional tools, although the LogicPort comes close. I'd expect the $$$ ones from Agilent and Tek to have better input protection, but in that case I probably would be more worried about the analyzer than my PC ;).
Yes, some have protection diodes and resistor arrays - it is one suggestion for the next redesign of the OLS to implement a protection diode at least in the USB power line. When saying they have no protection I was actually responding to your suggestion to use opto-couplers between PIC and FPGA (my bad, I didn't quote the exact reference). opto-isolation is more or less close to useless if you don't seperate your circuitry completely into two electrically independent sections (no electrical connections, two truely independent power sources, one for each section). For the OLS this would mean to add at least 2 high-speed 3 channel opto-couplers, a power plug and one more 3.3V VR plus a complete redesign of the PCB (separation), not to forget the extra wall mart/power supply the user will need regardless if he needs the opto-isolation or not. All this would raise the cost by at least US$ 10 .... the main problem will be PCB space ... Ian wants to stick with the free version of Eagle CAD for good reasons, I think.

For professional lab equipment there are usually two options (and in most cases they are not standard) to protect test equipment like LAs, scopes etc. OR the equipment they are connected to against over-currents and high-voltages:
a) magnetics or opto-isolated interface towards the PC/network - does not protect the test quipment itself
b) opto-isolated (active) probes - this is the recommended way to go if the opto-couplers can provide enough bandwith for the application because it provides the maximum protection for the test equipment as well as for the operator.
In case of the OLS this may lead to the option an opto-isolated probe project for I²C, SPI, RS-485/422, RS232 etc.

Quote
In industrial environments and with runs between multiple floors/buildings, ground potential differences (not sure if I'd call them loops) can be damaging to even not-so-sensitive equipment (I don't expect an RS-232 to 4-20 converter to be very delicate).
Today all RS232 <--> 20mA converters for industrial environments I know of are opto-isolated ... what I described was back in the 80's.

Quote
I was thinking more about ground loops on your workbench, the potential differences are usually below 100mV or so in that case.
I agree that "typical" ground loops encountered in home audio and TV equipment or on stanges in electronic audio equipment cause a potential difference of some 10mV to 1V, maybe 2V. The ground loops I described in industrial environments are extreme but not uncommon with line lengths of hundreds of meters or more ... Ian asked for examples of ground loops causing damage to electronics so I picked the example with the data lines in industrial environments ... I could have described ground loops I experienced with cable-based communication equipment running through a military communication headquarter with high-power HF transmitters not following basic grounding rules on some of the equipment ... the example from the industrial environment would pale in comparison. I have no idea what else to call an unwanted current in a conductor that's supposed to be on the same potential at both ends but a ground loop?
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: alm on June 02, 2010, 12:18:13 pm
[quote author="IPenguin"]
sigrok says they will support the Intronix with their multi-platform software soon ... the bundle Intronix/sirok may give you the total killer LA package in the price range of under US$ 500 ;)
[/quote]
As soon as sigrok itself becomes usable ;). I tried it recently with a Saleae Logic, and it seemed really immature, but I would really like it to become better.

[quote author="IPenguin"]
1. I expect the USB root hub to die when it gets +12V/-12V on the signal lines ... but then the OLS will die first ... the FPGA will for sure if you don't use the buffered header. But then the unbuffered header is actually intended for a wing like a DSO extension and any other protection of the lines but with serial resistors (which is no real protection against cases we talked about) would make it unsuitable for this.
[/quote]
I was mainly referring to the buffered inputs. It's fine if the buffer or FPGA dies ($50 worst case to replace the OLS), but does that mean the root hub will survive (a much more expensive replacement, especially in a laptop)? Voltages like that are pretty common in analog circuits, and might be close to digital lines in mixed-signal designs.

[quote author="IPenguin"]
2. Same when you touch VFD power with a probe - VFD voltag is typically over 50V and qualifies for "high-voltage" in the meaning of better using opto-isolated interfaces (not in the meaning of saftey regulations)
[/quote]
It was just an example of not power-supply related work that might benefit from isolation, that you might encounter in regular hobbyist circuits.

[quote author="IPenguin"]
3. In the end even the best lab equipment is only protected to certain limits - it's up to the user not to abuse it (like I did) and it's not protected against (possibly) 60-110VAC (or more if the switcher in the wall mart went into resonance before it died) inducted into the circuitry (terrymeyer) because of a failing wall mart - like if you buy a B6 armoured Mercede-Benz GL but drive it over a cliff into an abyss or get run over by a 40 ton truck the armore won't keep it from getting damaged.
[/quote]
Yes, I don't expect a logic analyzer to survive hundreds of volts or even mains, although I would expect my computer to survive the latter (OLS connected to mains voltage). Lab equipment tends to be more robust than normal equipment, almost any signal source or power supply is short-circuit proof, unlike some wall warts ;).

[quote author="IPenguin"]
Yes, some have protection diodes and resistor arrays - it is one suggestion for the next redesign of the OLS to implement a protection diode at least in the USB power line. [...] For the OLS this would mean to add at least 2 high-speed 3 channel opto-couplers, a power plug and one more 3.3V VR plus a complete redesign of the PCB (separation), not to forget the extra wall mart/power supply the user will need regardless if he needs the opto-isolation or not. All this would raise the cost by at least US$ 10 .... the main problem will be PCB space ... Ian wants to stick with the free version of Eagle CAD for good reasons, I think.[/quote]
I was actually thinking about clamping diodes from any signal line to power/ground (I'd probably do that on the input side), I think at least the Saleae Logic has them. Diodes to prevent reverse current in the power line might cost too much voltage, and aren't that useful if you consider the OLS as an enclosed piece of equipment, since the power lines are not usually connected to the DUT. Some of the AD iCoupler devices (look at us, we're modern and using trendy names) have an integrated isolated power supply up to 100mA or so, but they are quite expensive, and any other form of isolated DC-to-DC converter could also be used. I think $10 is a bit pessimistic, the 3 channel (2 out, 1 in or visa versa) isolator that I mentioned is less than $2 (do you really need two of those?). A DC power jack is probably under $1. Add extra costs for assembly and PCB. The need for an extra power supply without requiring isolation could be fixed with some sort of jumper. But your point about extra board space is true, one of the reasons why I'd prefer that the design was done in something open source like kicad, but this isn't exactly the right time to change.

[quote author="IPenguin"]
For professional lab equipment there are usually two options (and in most cases they are not standard) to protect test equipment like LAs, scopes etc. OR the equipment they are connected to against over-currents and high-voltages:
a) magnetics or opto-isolated interface towards the PC/network - does not protect the test quipment itself
b) opto-isolated (active) probes - this is the recommended way to go if the opto-couplers can provide enough bandwith for the application because it provides the maximum protection for the test equipment as well as for the operator.
In case of the OLS this may lead to the option an opto-isolated probe project for I²C, SPI, RS-485/422, RS232 etc.
[/quote]
Yes, isolating at the probes is also a good solution. Not sure if I see the point of active probes for I[sup:]2[/sup:]C and SPI, since they don't have any particular electrical interface. And the GPIB/RS-232/LAN interfaces are often isolated (at least for function generators, oscilloscopes and multimeters) on professional equipment, they often have a separate isolated micro-controller for communication. With LAN, you even get some isolation for free since an isolation transformer is mandatory for 10baseT/100baseTX/1000baseT, although you probably shouldn't rely on this.

[quote author="IPenguin"]
Quote
In industrial environments and with runs between multiple floors/buildings, ground potential differences (not sure if I'd call them loops) can be damaging to even not-so-sensitive equipment (I don't expect an RS-232 to 4-20 converter to be very delicate).
Today all RS232 <--> 20mA converters for industrial environments I know of are opto-isolated ... what I described was back in the 80's.
[/quote]
But even without opto's, RS-232 transceivers can usually withstand at least +/- 25V or so, and I can't imagine a 4-to-20mA converter (which is mainly used in industrial environments) to be very delicate either. Not like CMOS inputs that blow up when you sneeze.
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: rhyde on June 04, 2010, 02:07:14 am
I can now report successful BP upgrade done, communication seem to be reliable with initial test.


[quote author="rhyde"]
...
No bootloader so I did not update the PIC, I am not sure if that was required.  I do have a bp so if Ian can point the script for that method I am willing to try that.


$ /cygdrive/c/Program Files/Java/jdk1.6.0_20/bin/java.exe -jar analyzer.jar
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
COM1
COM14
Device Controller found: org.sump.analyzer.devices.FpgaDeviceController
COM1
COM14
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: COM14 (115200bps)
Run started
Device ID: 0x0
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(FpgaDeviceControll
er.java:546)
        at java.lang.Thread.run(Thread.java:619)
[/quote]
Title: Test Release 2.04 - SPI mode - My Own Full test on my new received OLS
Post by: TitanMKD on June 06, 2010, 12:27:41 am
Hi,

I have just received my OLS v1.01 from Seed Studio and it seems all work fine (at least using Test Mode and with some previous test using BusPirate+PWM) !!!

I have logged everything in Test Mode (configuration HW/SW used ...) in the attached zip file (containing OpenOffice .odt full description).

Best Regards

TitanMKD
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: IPenguin on June 06, 2010, 08:36:57 am
TitanMKD, thank you for the detailed report.

On a side note, you must have used the new SUMP Java client contained in the bitstream release 2.04 package (2.04TestRelease.zip).
Unfortunately the client (analyzer.jar) still shows the old version from 2008 (... analyzer.jar that comes in 2.04TestRelease.zip is the
correct one for bitstream release 2.04 from the same package).
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on June 09, 2010, 04:48:18 pm
Here is an experimental package that can program the bootloader into the Logic Sniffer using a Bus Pirate. This should help out a few people who got an OLS without a bootloader. Read more here (http://http://dangerousprototypes.com/forum/index.php?topic=620.0).
Title: Re: Test Release 2.03 and 2.04 - SPI mode.
Post by: ian on June 15, 2010, 11:23:13 am
A rescue package and instructions for reprogramming the Logic Sniffer bootloader with a Bus Pirate are now posted here (http://http://dangerousprototypes.com/2010/06/15/open-logic-sniffer-bootloader-rescue/).

If you don't have access to a Bus Pirate or PIC programmer to replace your bootloader please contact me. I'll put you in touch with someone nearby who can reprogram the bootloader, or send a Bus Pirate, depending on your location.

I'm sorry about this bug, it really hit us by surprise. We're still not sure how it happened, or the extent of the problem. Hopefully it was a minor mistake that doesn't effect too many people.