Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

A cheap logic analyzer. Get one for $50, including worldwide shipping. A collaboration between the Gadget Factory and Dangerous Prototypes.

Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby IPenguin » Mon May 24, 2010 2:01 pm

I am starting this thread to merge the various reports/posts from other threads that deal with a conflict between the SUMP Java client (analyzer.jar/OB_Logic_Sniffer.exe) and some COM port devices (like Arduino) - the problem was reported first by ben51 and decribed as resetting/putting an Arduino in bootloader mode when starting the SUMP Java client and/or starting captures with the SUMP Java client while an Arduino was connected to the system via a USB virtual COM port.

ben51 wrote:HI,

Besides the instable working of the OLS  I found an other issue while testing it.

Using an Arduino to generate waveforms the Arduino automatic reset was triggered every time I capture a waveform.
The Arduino uses this reset to activate the bootloader if you want to flash it.

The OLS sits on COM19. The Arduino on COM5. COM19 for the OLS due to using Blue Tooth which inserts a lot of additional comports.

Portmon from  Sysinternals showed that requests to VCP0 (the Arduino device) were made by java.exe which triggered the Arduio reset.

The log shows:

0 0.01975857 javaw.exe IRP_MJ_CREATE VCP0 SUCCESS Options: Open
1 0.00000608 javaw.exe IRP_MJ_CLEANUP VCP0 SUCCESS
2 0.11812187 javaw.exe IRP_MJ_CLOSE VCP0 SUCCESS

Is this a from the SUMP client or a JAVA issue?

If this is from the SUMP client then please remove resetting additional comports. Its annoying.

Toshiba Qosmio/Windows 7 32bits.


ian wrote:... Hi ben51 - I'm not sure who is causing that, but I doubt it's the OLS hardware resetting the additional ports. Bug reports for SUMP should be directed to the SUMP project, we're don't maintain that project.


ben51 wrote:Ian,

Your right, i'll do that. ...


IPenguin wrote:
@ben51: thanx for the info - from the info you gave it looks to me like this: ...

2.  I attached an USB Arduino (actually a Freeduino) to my PC (Windows XP Pro) and performed a quick test running some "fast blinky LED" test on the Arduino (using COM 16) and then connected an OLS (using COM 19) and launched the SUMP Java Client .... BANG the blinking LED stopped and the Arduino performed a reset .... next I started a capture .... BOOM the blinking LED stopped and the Arduino performed a reset again. Whenever I started a capture from the SUMP Java client the Arduino would reset. However, after loading a new sketch to the Arduino - while keeping both the Arduino IDE and the SUMP Java Client open - starting a capture from the SUMP Java client would not reset the Ardino anymore. Next I tried to connect the SUMP client to the COM port the Arduino was using and ... BANG the Arduino was reset. When trying to connect the SUMP Java Client to the OLS I saw for the first time the "device not found" message :D

I don't think the OLS board has anything to do with the reset of your virtual Arduino COM port, at least not directly - However, I assume that you had absolutely no problem to run the SUMP Java client on your Mac and to connect to the OLS when you launched it the first time since librxtxSerial.jnilib and RXTXcomm.jar were already installed with your Arduino/Processing IDE prior to connecting the OLS for the first time. I would have to test it myself but I assume that your Arduino (actually the connection/virtual COM port) will be reset every time the SUMP Java client is started, at least whenever it opens the COM port to the OLS to initiate a capture ...
I have hardly any Java experience but checking the code for public boolean attach(String portName, int portRate) in FpgaDevice.java it seems that a general detach performed before attaching the COM port to the device may actually cause the input stream and the output stream of the "first" open port in the COM port list to be closed ... in your case it's the Arduino's COM port - anyway, I could be wrong here.

I agree with Ian that the SUMP Java client is not maintained by the OLS project ... and the issue does not qualify for an OLS fail.

On the other side there will be a considerable number of OLS users who will want to use the OLS in Arduino development. Since the problem is not restricted to Mac OSX (as shown above) and appears to origin from the SUMP Java client there should be a general interest to get it fixed. Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar.
I will seperate this part of my post along with ben51s posts and merge them into a new "Conflicts between SUMP Java Client and Arduino IDE" thread later.


rhyde wrote:... The reason I have not seen the arduino interaction problem is I only have one usb port, and have failed on all attempts with powered hubs.  So it is clear why I did not hit it.


ian wrote:
Actually the conflicts will not be restricted to the Arduino IDE but extend to all/most Java applications that will make use of librxtxSerial.jnilib and RXTXcomm.jar.


I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added.


sdixon wrote:
ian wrote:I hadn't thought of this. Both SUMP and the Arduino IDE use the java rx/tx library. Both the FTDI chip and the OLS appear on the system as a serial port. COuld be an interaction there, but ti seems like no system should reset one serial port when another is added.

Ian-
The way most Arduino boards are set up, the processor is wired to reset to the boot loader whenever the DTR line is toggled, which generally happens when the port is opened.  This is used by the Arduino IDE to automatically put the processor into the boot loader to load new code (it avoids requiring the user to manually reset the processor each time).  So it perhaps isn't surprising that SUMP would cause an Arduino reset when it starts up since it seems to go through all of the available serial ports looking for the FPGA.  But it doesn't really make sense that the reset happens each time a capture is started, as people are reporting.  Once the correct serial port is selected in SUMP, it shouldn't be messing with any other port.
Last edited by IPenguin on Mon May 24, 2010 2:17 pm, edited 1 time in total.
User avatar
IPenguin
Global Moderator
Global Moderator
 
Posts: 430
Joined: Mon Nov 16, 2009 3:16 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby IPenguin » Mon May 24, 2010 4:27 pm

So at first it looked like there might be a conflict between the SUMP Java client and other applications running the RXTX Java library I come to a slightly different conclusion after reading over the reports and looking at the SUMP Java client code again. Now I think
- that any COM port device (regardless if using a physical (RS232) COM port or a virtual (USB) COM port) and is connected to a system (by RS232 or USB cable)
- BUT either NO application has opened a port connection to
- OR an application making use of the RXTX library has opened a port to 
may be affected when starting the SUMP Java client and possibly whenever a capture is started.

In general any device that will change his behavior when the DTR line is toggled or it receives 1 to 5 times 00h may be affected - Arduinos with USB and RSR232 and Sparfuns NXP LPC2148 based boards like the Dev Platform for LPC2148 - Uberboard, the Logomatic v2 Serial SD Datalogger or the MP3 Development Board that make use of the Sparkfun LPC2148 bootloader via a COM port for example. On the other side devices that use a (reset) switch to enter bootloader mode like the USB Bit Whacker family (UBW, UBW32) and the Pinguino family will not be affected unless they have an other application than the bootloader running that is sensible to toggling of the DTR signal or receiving 00h ...

I will assemble an Arduino Serial Board (RS232) V2.00 board now and perform some tests to see if physical COM ports are affected as well.

I think we should address this issue by fixing the SUMP Java client code as a number of affected devices are commonly used development platforms OLS users will have in their "arsenals" and want to use the OLS on.
User avatar
IPenguin
Global Moderator
Global Moderator
 
Posts: 430
Joined: Mon Nov 16, 2009 3:16 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby alanbur » Mon May 24, 2010 4:30 pm

A simple fix would be to allow the com  port to be specified on the SUMP command-line.
alanbur
Newbie
Newbie
 
Posts: 37
Joined: Thu May 13, 2010 4:11 pm

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby sdixon » Mon May 24, 2010 7:31 pm

alanbur wrote:A simple fix would be to allow the com  port to be specified on the SUMP command-line.

It appears that using the command line switch -Dgnu.io.rxtx.SerialPorts should set which serial port rxtx uses.
I just tried
java -Dgnu.io.rxtx.SerialPorts=/dev/tty.usbmodem1d11 -d32 -jar analyzer.jar

and the console output seemed to indicate that rxtx only looked at that particular serial port (none of the others was listed as they normally are).  But I don't have time at the moment to set up an arduino and check if that fixes the problem.  It did collect data from the OLS though.
sdixon
Jr. Member
Jr. Member
 
Posts: 99
Joined: Fri Apr 30, 2010 6:01 pm

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby wayoda » Tue May 25, 2010 7:57 am

Hi,
since about 2 years these USB-2-Serial bridges are used by almost every development board and many other DIY projects.
Here is the situation on Ubuntu. A OLS will present itself to the OS as  a type 'modem' USB device. The operating system creates a device-file with the name /dev/ttyACM* .
The RXTX-lib is a bit limited in the device names it accepts, so it doesn't even see the device, but the are ways to create a link with the name /dev/ttyUSB[number] to this device-file so this can be solved (but clashes with all arduino boards).

The next problem is the the USB-device-descriptor gives no clue to the device actually being a OLS.
The vendorID / productID is shared with many other devices (for instance the atmel XPLain devlopment board, and my GPS tracker ).

On Linux we could still identify a OLS if the 'Manufacturer' and 'Product' Strings where set ("DangerousPrototypes" "OLS") in the Device Descriptor.
An udev rule can create a link (like '/dev/OLS' ) based on these Attributes.

If there is a (user-) configurable iSerial-String too (read from the DataFlash??) we are also able to tell two OLS-boards apart.

The other solution would be to move away from the USB2Serial approach and use a custom class USB device descriptor. But this would also require a custom (libusb)-driver for this to work.

sdixon wrote:It appears that using the command line switch -Dgnu.io.rxtx.SerialPorts should set which serial port rxtx uses.
I just tried
java -Dgnu.io.rxtx.SerialPorts=/dev/tty.usbmodem1d11 -d32 -jar analyzer.jar
and the console output seemed to indicate that rxtx only looked at that particular serial port (none of the others was listed as they normally are). 

I use the same feature on Linux
java -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0 -jar analyzer.jar
which works fine unless I have my XPlain board plugged in too.

Eberhard
wayoda
Jr. Member
Jr. Member
 
Posts: 78
Joined: Thu May 06, 2010 5:59 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby rsdio » Tue May 25, 2010 10:39 pm

You are basically right about everything, Eberhard.

The one thing I would point out is that on OSX you would not need a custom driver for a custom class USB device. It's entirely possible to write a user (not kernel) application which connects to a specific VID/PID (and Serial Number) to send and receive custom USB packets.

I realize that people like cross-platform development, but when something like libusb puts high hurdles in the way of getting things done, sometimes it's fine to just take the shortest path.

What I particularly like about the OLS hardware design is that it should not be that hard to have a couple of options for firmware. Although it's best to offer one solution that works for everyone, that still doesn't mean we're stuck with just one solution. As I keep saying, I hope to help design the second revision of the OLS and then purchase a board so that I can work on firmware and maybe a front end.
User avatar
rsdio
Developer
Developer
 
Posts: 1404
Joined: Sun Feb 28, 2010 10:53 pm
Location: Seattle

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby ian » Wed May 26, 2010 5:07 am

The next problem is the the USB-device-descriptor gives no clue to the device actually being a OLS.
The vendorID / productID is shared with many other devices (for instance the atmel XPLain devlopment board, and my GPS tracker ).


The OLS does have two unique PIDs. The bootloader VID/PID is 0x04D8 0xFC90, the firmware PID is 0xFC92. It looks like there are some development firmwares floating around that include the default, the next firmware release will include the correct PID and a better descriptor text.
Got a question? Please ask in the forum for the fastest answers.
User avatar
ian
Crew
Crew
 
Posts: 10578
Joined: Mon Jul 06, 2009 6:14 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby wayoda » Wed May 26, 2010 7:29 am

Hi,
ian wrote:The OLS does have two unique PIDs. The bootloader VID/PID is 0x04D8 0xFC90, the firmware PID is 0xFC92.

Great that would solve the problem of detecting an OLS. Is there a chance for some kind of user-defined SerialNumber that is accessible in the USB-descriptors (or alternativly could be read with a custom command from the client-software? 

BTW:
That's what I have for both of my OLS (Ubuntu)
Code: Select all
Bus 001 Device 006: ID 04d8:000a Microchip Technology, Inc.


The VID and PID do not change when I force the board into Update-mode or reset it manually. But the hardware does reset, I can see that from the log-messages.
Forget what I wrote, I didn't go into bootloader mode...
 
Eberhard
Last edited by wayoda on Wed May 26, 2010 7:44 am, edited 1 time in total.
wayoda
Jr. Member
Jr. Member
 
Posts: 78
Joined: Thu May 06, 2010 5:59 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby Sjaak » Wed May 26, 2010 7:46 am

Wayoda, could it be you don't have the bootloader installed?

Just curious because you've got a different vid/pid then Ian says.
User avatar
Sjaak
Fellow
Fellow
 
Posts: 3039
Joined: Sun Jan 03, 2010 2:45 pm
Location: Hiero

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby wayoda » Wed May 26, 2010 8:46 am

Hi Sjaak,
Sjaak wrote:Wayoda, could it be you don't have the bootloader installed?

Just curious because you've got a different vid/pid then Ian says.

No the bootloader is on the boards. Just updated to the Test-Release 2.04. (The PIC-Firmware update to 2.04 didn't change the USB2Serial VID/PID, but the device enumerates as a USB-HID when forced into bootloader-update mode with the numbers given by Ian 04D8:FC90) 

Eberhard
wayoda
Jr. Member
Jr. Member
 
Posts: 78
Joined: Thu May 06, 2010 5:59 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby ian » Wed May 26, 2010 8:54 am

The update ROM mode and SUMP mode are the same driver and have the same VID/PID. It looks like it has the development PID still, I will make sure to change it in the next release and also add a custom description text and manufacturer text. Looking at my development branch, these things are already done, but I think maybe MPLAB is linking to a version in a different directory and I'm not getting the right files in the compile. One thing for me to remember is that we'll need a new .inf with the old and new PID for this upgrade.


The bootloader is a different device type (HID) and has a different PID so windows can tell the difference. It looks like that one is correct.
Got a question? Please ask in the forum for the fastest answers.
User avatar
ian
Crew
Crew
 
Posts: 10578
Joined: Mon Jul 06, 2009 6:14 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby IPenguin » Fri May 28, 2010 9:07 am

After assembling an Arduino serial v2.0a, I realized that the serial arduinos don't use DTR to reset/start the bootloader ... the rest button must be pressed to activate the bootlaoder shortly befor downloading the sketch. Found no conflicts between the OLS/SUMP Java Client and an Arduino serial v2.0a/Arduino IDE r0018 when running both at the samme time.
User avatar
IPenguin
Global Moderator
Global Moderator
 
Posts: 430
Joined: Mon Nov 16, 2009 3:16 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby ian » Tue Jun 29, 2010 1:12 am

I just found this doing search for another support question, its kind of related:

One cautionary note: because the automatic reset works by using the serial DTR hardware control line, boards will auto-reset whenever you open a serial connection (i.e. via the USB cable) to them. This should be fine in most cases, but you might want a second or two delay before sending data to the board.


http://arduino.cc/blog/?p=13
Got a question? Please ask in the forum for the fastest answers.
User avatar
ian
Crew
Crew
 
Posts: 10578
Joined: Mon Jul 06, 2009 6:14 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby IPenguin » Tue Jun 29, 2010 2:03 am

Yup, I finally got to build and test my Atmex v2.3 boards and the Java based Atmex loader (using RXTX as well) crashes the connection between the SUMP Java client and the OLS as well. It seems to be about how RXTX searches/initializes COM ports ... however, I assembled an old Arduino serial PCB with an ATmega8 and a RS232 port. With this board on a generic RS232 COM port I did not observe any problems withe OLS communication ... I will look into this once I have a little mor etime ... or maybe someone else gets a chance to take a look before ...
User avatar
IPenguin
Global Moderator
Global Moderator
 
Posts: 430
Joined: Mon Nov 16, 2009 3:16 am

Re: Conflicts between SUMP Java Client and COM port devices (like Arduino)

Postby LeissKG » Tue Jun 29, 2010 1:07 pm

IPenguin wrote:After assembling an Arduino serial v2.0a, I realized that the serial arduinos don't use DTR to reset/start the bootloader ... the rest button must be pressed to activate the bootlaoder shortly befor downloading the sketch. Found no conflicts between the OLS/SUMP Java Client and an Arduino serial v2.0a/Arduino IDE r0018 when running both at the samme time.

You can add one capacitor to your board and it will reset on DTR like more modern Arduinos.

http://www.arduino.cc/playground/Learni ... etRetrofit

Klaus Leiss
LeissKG
Newbie
Newbie
 
Posts: 33
Joined: Sat Nov 21, 2009 7:55 am

Next

Return to Open Bench Logic Sniffer