OLS preorder 1 fail wall

Topic: OLS preorder 1 fail wall (Read 16958 times) previous topic - next topic

Re: OLS preorder 1 fail wall

Reply #15 – May 23, 2010, 03:06:56 am

rhyde: I think it is normal for OSX to change /dev/usbmodemXXXX name every time you move a USB serial device to a different port or hub. Since you can plug more than one OLS into your Mac at the same time, OSX needs a way to keep them all separate. As far as I know, you must manually change the special device file name in the Java client every time you move the USB device to a different topology (i.e. different port or hub).

There are ways for OSX programs to directly attach to a USB device by VID/PID without using the /dev/usbmodemXXXX special file, but so far there are no OLS client programs to do this.

I've been working on a client program for the USB IR Toy, but I'm still using the /dev/usbmodemXXXX special file for convenience. I hope to make a future client which uses the better OSX API for USB. If I ever do that, and if I get an OLS (hopefully with DSO wing), then I might write another client. I'm making no promise, but it's at least theoretically possible that things could become more convenient on the Mac that they are right now.

Meanwhile, I don't think you're seeing a bug, just an inconvenience with non-native Mac applications.

Re: OLS preorder 1 fail wall

Reply #16 – May 23, 2010, 03:55:50 am

Okay that makes some sense. I may have to write that client myself, but I have yet to get to deep into the current Macos design and interfaces.

Re: OLS preorder 1 fail wall

Reply #17 – May 23, 2010, 06:51:45 am

Anyone wanting to write an OSX client should start with Xcode and be sure to look at /Developer/Examples/Kernel/IOKit/usb/ (don't be fooled by the subdirectory name - you don't have to write kernel code to grab a USB device)

Re: OLS preorder 1 fail wall

Reply #18 – May 23, 2010, 11:53:59 am

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.

Re: OLS preorder 1 fail wall

Reply #19 – May 23, 2010, 05:52:55 pm

Quote

How about using the unbuffered pins to generate a test pattern?

That is the current plan for the next batch. Jack has this implemented in the FPGA bistream (send 0x03), but Seeed wanted an easy way to trigger it so I updated the firmware to send 0x03 on startup if there is a jumper between the TX and RX pins of the UART header.

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.

Re: OLS preorder 1 fail wall

Reply #20 – May 23, 2010, 08:38:28 pm

Ian,

Your right, i'll do that.

Btw Now I am using a 2.5 inch external disk usb cable with two usb connectors.
So I use 2 usb port on my laptop now. Seems to be more stable in a way that I need lesser resets to get the OLS working.
New is that it some times registers as an unknown usb device with 2 ports. Reconnecting a few times will get it recognized again.

Re: OLS preorder 1 fail wall

Reply #21 – May 24, 2010, 01:23:39 am

Hmmmm, this thread is getting a bit off-track. It's the main fail wall for the OLS but we see a lot of posts that are not or mostly not related to OLS failures. I admit that I made some off-topic comments myself but I will try to clean this up later - no posts will be deleted, just moved to either new threads or existing threads that cover the relevant subject. However, let me address a few questions/comments first:

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

1. the instability of your OLS relates most likely to the general communication problem (UART interface between PIC and FPGA) that haunts users on Windows, Linux and Mac OSX based systems alike - it wil be addressed in a soon to be released update of the FPGA bitstream.

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

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 [font=courier:]public boolean attach(String portName, int portRate)[/font:] in FpgaDevice.java it seems that a general [font=courier:]detach[/font:] 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.

@rsdio & rhyde: I agree that a generic Linux/Mac OSX client for the OLS would be great. However, I think that the client application should be split up into two parts (pretty much like the infamous gdb debugger for example) - a communication server/device driver that acts as an interface on the PC side, handling the USB communication and providing a socket based API to the application. This would relieve application programmers of dealing with all USB related issues, allow for commonly maintained generic source code of the server for all supported platforms and prevent conflicts with other Java based applications like the Arduino IDE.

Like for the prvious subject (conflicts between SUMP Java Client and Arduino IDE) I will seperate the relevant posts and merge them into a new thread later.

@rhyde: thank you for reporting all the details ... I will address them in random order:

1. Interesting enough you don't seem to have had or noticed conflict(s) between the SUMP Client and the Arduino IDE but some part of what you may have described as USB madness may relate to conflicts between the SUMP Java client and the Arduino IDE ... unless you ran them on different systems or not at the same time ...

2. I am quite sure your connection/device not found problems with your OLS are related to the timing problem in the UART part of the SUMP VHDL code Jack has found. It should get solved with the next bitstream update Ian announced above and Jack has been working on. It will address and solve what is commonly known as "intermittent communication problems" best described as the OLS will enumerate and get a virtual COM port assigned but the Java client fails to communicate with the OLS (displaying "Device not found").

@Sjaak: you got the whole concept of using the unbuffered channels/ports as a signal generator to test the SPI flash, FPGA and buffer chip absolutely right! As Ian said, the code will be implemented in the bitstream that will ship with the next batch and it will be made available for all who have a preorder 1 OLS so they can flash the bitstream into the SPI flash with pump-loader - no special programmer required.

Re: OLS preorder 1 fail wall

Reply #22 – May 24, 2010, 03:04:56 am

Thanks for the status. 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.

As for usb drivers, I have no interest in writting a macos client, but if a new java usb connection is really needed I will take a look at it. (I program for a living and use to do drivers. Java is how I earn my pay, but I would consider helping if needed. First lets get the new bitstream, and see what is needed. If anyone finds a working 64bit rxtx for mac I would be greatful. (sry off topic but I am still getting getting too many crashes.) RXTX seems the right way to go and be platform independent, but the current version is old and broken. If there is a better /proper place to post status info please point me to it.

Re: OLS preorder 1 fail wall

Reply #23 – May 24, 2010, 06:27:37 am

[quote author="rhyde"]
If anyone finds a working 64bit rxtx for mac I would be greatful. (sry off topic but I am still getting getting too many crashes.) RXTX seems the right way to go and be platform independent, but the current version is old and broken. If there is a better /proper place to post status info please point me to it.
[/quote]
Is there a particular reason why you need the 64 bit version? At least for SUMP, it seems like 32 bits would be fine. I know that Arduino and Processing both are currently running 32 bit and they are probably the biggest users of RXTX on OS X. So there probably isn't a lot of pressure to get the 64 bit version working. But if there is an advantage to 64 bit, then perhaps it would be a different matter. It isn't hard to run a particular program under the 32 bit JVM even if you generally run things in 64 bit (as I imagine you know).

Re: OLS preorder 1 fail wall

Reply #24 – May 24, 2010, 06:06:20 pm

Quote

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.

Re: OLS preorder 1 fail wall

Reply #25 – May 24, 2010, 06:36:58 pm

[quote author="ian"]
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.
[/quote]
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.

Re: OLS preorder 1 fail wall

Reply #26 – May 24, 2010, 08:24:47 pm

[quote author="ian"]

Quote

How about using the unbuffered pins to generate a test pattern?

However generating your own test pattern will not discover every problem (like timing glitches someone experienced)

Just for the record my OLS appears to function OK and has also the bootloader present.

Re: OLS preorder 1 fail wall

Reply #27 – May 25, 2010, 01:29:13 am

[quote author="sdixon"]
Is there a particular reason why you need the 64 bit version? At least for SUMP, it seems like 32 bits would be fine. I know that Arduino and Processing both are currently running 32 bit and they are probably the biggest users of RXTX on OS X. So there probably isn't a lot of pressure to get the 64 bit version working. But if there is an advantage to 64 bit, then perhaps it would be a different matter. It isn't hard to run a particular program under the 32 bit JVM even if you generally run things in 64 bit (as I imagine you know).
[/quote]
It is pretty clear that apple is moving away from 32bit everything they can, and there is no reason the 64bit shouldn't work, other than the out of date, and broken rxtx driver. I have yet to find a patch/updated binary that does not generate surpious stack traces, and occassional panics. After 18 months of blissful stability I now panic several times an evening. This got old real fast.

Re: OLS preorder 1 fail wall

Reply #28 – June 09, 2010, 04:48:06 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.

Re: OLS preorder 1 fail wall

Reply #29 – June 15, 2010, 11:23:26 am

A rescue package and instructions for reprogramming the Logic Sniffer bootloader with a Bus Pirate are now posted here.

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.