Skip to main content ↑ ↓
Topic: [solved?]***Possible solution to intermittent communication problems*** (Read 12707 times) previous topic - next topic

[solved?]***Possible solution to intermittent communication problems***

Update: my suggestion to reconfigure the driver doesn't seem to help, but some have had great success with robots updated SUMP file with a longer read timeout. Get it here.

I thought of a possible solution for intermittent communication problems with the OLS.

Problem:
When I made the Bus Pirate SUMP mode there were communication/connection errors too. SUMP is kinda simple in the way it determines a connection error. It reads bytes from the serial port and if there's no byte right away it throws the error. This might work on a serial port, but on a USB->serial connection bytes are queued up and sent to the PC in packets. Sometimes there's no byte immediately available and then SUMP reports an error even though the data is actually on it's way.

This could be effecting the following cases:
1. Random PCs with different chipsets, OS driver versions, number of connected USB peripherals, system USB latency
2. Hubs, where data has to be queued and repeated to the PC a second time
3. VMs with layers of abstraction that slow down the responsiveness of the virtual serial port.

This will not explain these cases:
1. Certain bitstreams don't work (there is a bitstream problem still)

Solutions:
The best solution would be to modify the SUMP client to poll for data over a timeout period before throwing an error. Kicking out an error after a single miss is not really a good solution for a USB-based device.

The alternate solution isn't as great because it slows transfers way down, but it doesn't require any coding. When I had a similar intermittent communication error with the BP SUMP support, I ended up changing the FTDI driver settings to be more responsive. The OLS uses a CDC virtual serial port, it doesn't have as many nice settings, but it should have a buffer size adjustment slider (shown in the image below).

My recommendation for people with intermittent connection problems is to test with these sliders all the way to the left (smallest value possible). If you have any success with this, or no success, please let me know. This may solve some *intermittent* com problems, especially for Windows users, if the problems are similar to what I experienced with the Bus Pirate. Again, it will not solve problems where you can't communicate with certain bitstreams at all - a logic capture shows that certain bitstreams just don't respond when programmed into certain FPGAs - we're still working on this.
Got a question? Please ask in the forum for the fastest answers.

Re: ***Possible solution to intermittent communication problems***

Reply #1 –
If this was the case then why is the FPGA bitstream upload rock-solid even on boards that Sump can't talk to?  It sounds like a bug in Sump to me, rather than the board...

Re: ***Possible solution to intermittent communication problems***

Reply #2 –
The FPGA uploading software (pump-loader) has rather high timeouts (~10x100ms) so the HW has enough time to transfer the data through USB. I think you are describing the same problem as Ian.

There is a way in the RXTX library to tell the serial port to wait for data with timeout, simple fix could be to increase this delay.

Edit:
org/sump/analyzer/devices/FpgaDevice.java:489:
Code: [Select]
port.enableReceiveTimeout(100);
This makes the timeout 100ms. Could someone try to increase to 500-1000? and see if the error goes away ?

Re: ***Possible solution to intermittent communication problems***

Reply #3 –
[quote author="robots"]
This makes the timeout 100ms. Could someone try to increase to 500-1000? and see if the error goes away ?
[/quote]

I would happily give it a try, but I don't seem to be able to pull from the SVN repo:

$ svn checkout --username anonymous http://www.gadgetfactory.net/svn/butterflylogic OBLS
svn: OPTIONS of 'http://www.gadgetfactory.net/svn/butterflylogic': could not connect to server (http://www.gadgetfactory.net)
$

Re: ***Possible solution to intermittent communication problems***

Reply #4 –
This is definitely a problem with my unit.  I get the "Device not found" error quite often.  When I put a serial-port spy on it I found that all communications were taking place as expected.  Unfortunately, I don't think the source code for the windows EXE version is posted.

Re: ***Possible solution to intermittent communication problems***

Reply #5 –
I am not quite sure what OB_Logic_Sniffer.exe exactly is or does ... o.O. ... seems like a launcher for the Java client analyzer.jar. Maybe Jack can shed some light on it.

robots pointed at line 489 the java source file Fpga.Device.java which is available from the Gadgetfactory OpenBench Logic Sniffer SVN repository at /trunk/Java_Client_Sump/org/sump/analyzer/devices. Maybe Jack could give it a try, change "port.enableReceiveTimeout(100)" to "port.enableReceiveTimeout(500)" in FpgaDevice.java:489 and recompile analyzer.jar since he must have a working development environment for the SUMP Java client ... ;)

Re: ***Possible solution to intermittent communication problems***

Reply #6 –
I guessed wrong that people here have JDK installed :) ]

I have compiled the version with timeout of 700ms. See attached zip file. It should work just by replacing the analyzer.jar, with the one in the zip file.

Re: ***Possible solution to intermittent communication problems***

Reply #7 –
Hello, sorry I have been slow on responding. I have been knee deep in troubleshooting the new SPI mode and should have it ready very soon. The OB_Logic_Sniffer.exe is the analyzer.jar file wrapped up as an executable.

Jack.

Re: ***Possible solution to intermittent communication problems***

Reply #8 –
[glow=red,2,300]BINGO!!![/glow]

WORKS ALL THE TIME EVERY TIME!!!

Thank you Thank you Thank you!!!

Re: ***Possible solution to intermittent communication problems***

Reply #9 –
I've extended the RX timeouts in SUMP (tried up to 10s), but I'm still seeing problems.
I've yet to have a successful capture - it always quits after about 25% saying "error while trying to communicate with device".
I've tried USB direct to my MacBook and via a powered hub, neither work.

I haven't looked at the FPGA or PIC code, so haven't a clue if this is useful - but, I put a scope on FPGA_AUX1. While the progress bar in SUMP is moving, there's activity on the pin. Once SUMP freezes, the activity stops also. That might rule out a PIC/USB side issue?

For anyone trying to build SUMP, here's some notes (debian linux):

add non-free to /etc/apt/sources.list

Code: [Select]
apt-get install sun-java6-jdk sun-java6-jre librxtx-java subversion
svn co http://www.gadgetfactory.net/svn/butterflylogic/trunk/Java_Client_Sump

Makefile:
Code: [Select]
all: class jar

JAVAC=javac -d . -cp /usr/share/java/RXTXcomm.jar

class:
        $(JAVAC) org/sump/analyzer/*.java 
        org/sump/util/*.java 
        org/sump/analyzer/tools/*.java 
        org/sump/analyzer/devices/*.java 
        
jar:
        jar cfm analyzer.jar 
                Manifest.txt 
                org/sump/analyzer/*.class 
                org/sump/analyzer/tools/*.class 
                org/sump/analyzer/icons/*.png 
                org/sump/analyzer/devices/*.class 
                org/sump/util/*.class

Code: [Select]
make

Code: [Select]
java -cp /usr/share/java/RXTXcomm.jar:./analyzer.jar -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM0" -Djava.library.path="/usr/lib/" org.sump.analyzer.Loader

Re: ***Possible solution to intermittent communication problems***

Reply #10 –
TheMattster - great to hear that this was a workable solution for someone. [s:]Maybe the updated SUMP with extended timeouts will help too so you can go back to 'normal' USB timing.[/s:] Just read your post on another thread and realized what helped :) I'm glad the updated SUMP helped. I hope it helps others with this problem too.

jrt - which bitstream and how many samples do you have setup in SUMP? Is it possible to try it on a windows PC and run a serial port capture program like portmon? If you upload the traffic log from portmon or similar (sorry, not sure of the equivalent on Mac) I'll take a look at it for clues.
Got a question? Please ask in the forum for the fastest answers.

Re: [solved?]***Possible solution to intermittent communication problems***

Reply #11 –
:( Unfortunately, I spoke a little too soon.

An untriggered capture works great, but as soon as I turn triggers on it never captures a trigger.  When I set-up triggers in RealTerm it works.  It seems that it sets up for the trigger, but never even tries to read the data.

It's still working better though, and I appreciate everyone's help.

-Matt

Re: [solved?]***Possible solution to intermittent communication problems***

Reply #12 –
Here is some sample data for anyone wanting to access the OSL via RealTerm (http://sourceforge.net/projects/realterm/)

1) Open RealTerm, on the Display tab set "Hex[space]"
2) On the "Port" tab select the OSL serial port and 115200 baud - click "Change"
3) On the "Send" tab enter 2 in one of the boxes and click "Send Numbers"
    - the unit should respond with "31 41 4C 53" (ASCII: 1ALS (mirrored: SLA1))

One of the Analyzer sessions (with comments)
To OLS:
00 00 00 00 00 - Reset 5 times (00)
02 - Ask ID, four byte response: 31 41 4C 53, Literally, 1 A L S, swap bytes: SLA1
C0 00 00 00 00 - Trigger mask
C1 00 00 00 00 - Trigger values
C2 00 00 00 08 - Trigger Configuration
80 00 00 00 00 - Clock divider
81 FF 01 FF 01 - Read and Delay (0x1FF, 0x1FF)
82 02 00 00 00 - Flags
01 - run

From OLS:
Port opened by process "javaw.exe" (PID: 8744)

 31 41 4C 53 00 00 00 00 00 00 00 00 00 00 00 00   1ALS............
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

Re: [solved?]***Possible solution to intermittent communication problems***

Reply #14 –
I have two OLS, one works in the OSX or XP the other always fails with "device not found"
I have tried the analyser.jar file from the 19th with no joy as well as altering the advanced port settings.

FYI, all LED appear to provide the correct feedback, making the assumption that all is good.
 It is recognised in the device manager ports, I can upload different bit streams to it, but as soon as i hit 'capture' the device not found' rears its ugly head.

I would now assume that this is not software based but hardware based issue we have here as one OLS functions faultlessly and the 2nd doesn't?

Using realterm asan interface, when sending "2" I get feedback with the working OLS, the other OLS that gives "device not found" with sump offers me nothing (empty display)

How can I tell if the PIC is working properly?