Go Down

Topic: Problems with 0021 on Ubuntu 10.04 Lucid Lynx (Read 29408 times) previous topic - next topic

rgm

Oct 03, 2010, 08:41 am Last Edit: Oct 03, 2010, 09:29 am by rgm Reason: 1
I'm having serious problems with 0021 under Ubuntu 10.04 Lucid Lynx.
I seem to only be able to upload code once, then if I plug/unplug the Uno I can never get serial communication to work with it again (or maybe it has to do with the program it's running, see below).

dmesg shows that every time I plug my Arduino in it *is* registering as /dev/ttyACM0.  Every plug/unplug increases the address:
Code: [Select]

[ 1008.289135] usb 3-1: USB disconnect, address 2
[ 1010.764454] usb 3-1: new full speed USB device using uhci_hcd and address 3
[ 1010.961880] usb 3-1: configuration #1 chosen from 1 choice
[ 1010.964741] cdc_acm 3-1:1.0: ttyACM0: USB ACM device

Then, a bit later:
Code: [Select]

[ 1095.042640] tty_port_close_start: tty->count = 1 port count = 0.
[ 1140.802645] tty_port_close_start: tty->count = 1 port count = 0.
[ 1164.386670] tty_port_close_start: tty->count = 1 port count = 0

(not sure if that matters)

Furthermore, the IDE acts very unfriendly when trying to activate the "Tools" menu.  There is a 5-6 second delay during which the GUI locks up (menus should never block the main thread!), then the menu appears with the "Serial Port" option greyed out (I have no other serial ports in my system).  During this delay, a user is apt to click twice -- which causes the menu to instantly disappear after it finally appears.

I tried using RXTX 2.2 (unstable) but that didn't help.

My troubles seemed to start after I loaded some Serial.print() statements into my setup() function (after a Serial.begin of course).  The TX light is steady-on -- I've made a typo in the setup() routine and the arduino is stuck in an infinite Serial.print("*") loop -- this is verifiable by using minicom to connect to the port -- when minicom feels like opening the port.  Most of the time it says:

minicom: cannot open /dev/ttyACM0: No such file or directory

Does anyone have any suggestions?

rgm

#1
Oct 03, 2010, 08:45 am Last Edit: Oct 03, 2010, 10:37 am by rgm Reason: 1
Update:  I was finally able to upload new code to the board by repeatedly clicking the Upload button, and ignoring the /dev/ttyACM0 errors.  On the 4th or 5th click it worked, and my Arduino is no longer stuck in an infinite Serial.print loop, which makes it behave much better.

In summary, Arduinos that have programs that stream out serial data are very difficult to program / work with, even outside of the IDE, as evidenced by minicom's issues.

cr0sh

Quote
In summary, Arduinos that have programs that stream out serial data are very difficult to program / work with, even outside of the IDE, as evidenced by minicom's issues.


Probably the best way to handle this is to insert a pause in your setup before initiating the serial setup and such.

Another (and possibly better) alternative would be to set things up so that you can send a command to start/stop the streaming (and store the setting in the EEPROM); that way, you could turn off the streaming before doing a new upload, then re-enable it for your testing.
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

rgm

Yes, I ended up adding code to not start the streaming until told to, but once the streaming starts, it still causes undesirable behavior on the computer side of things -- the serial port is "unavailable" most of the time, at the OS level.  I can't help but think that this means that the 8u2 on the Arduino Uno needs some smarter code on it, but I haven't had a chance to verify how FTDI Arduinos function in this situation.  Maybe they suffer from the same "limitation."

As a naive user, I would expect the port to always be available regardless of whether the uC was streaming serial data or not.

In any case, the IDE shouldn't hang for so long looking for ports every time the "Tools" menu is clicked.

cr0sh

Quote
In any case, the IDE shouldn't hang for so long looking for ports every time the "Tools" menu is clicked.


I don't remember where, but somewhere on this forum, I recall somebody either finding and posting where this occurs on the java source, and/or a patch (which I think they submitted upstream)...
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

2u55.44

I'm having the same problem with 0021 under Ubuntu 10.04 Lucid and Arduino boards (both Uno and Duemilanove).

Serial communication from the Arduino board locks up the IDE and other serial monitors won't recognize the port - if I unplug the board the IDE comes back online. The IDE locks up so bad that I can't upload other sketches - I had to move to a mac (with 0021) to comment out the Serial.print(); in the offending code. Once that was removed I was able to go back my linux machine and everything worked fine.

Any ideas?

rgm

Quote
The IDE locks up so bad that I can't upload other sketches - I had to move to a mac (with 0021) to comment out the Serial.print(); in the offending code.

In my experience the IDE didn't lock up for longer than 6 seconds -- go slow and be patient (and don't click the Tools menu).  I was able to reprogram it from linux by repeatedly clicking the "Upload" button a few times (waiting between clicks), ignoring the error about /dev/ttyACM0 -- it got through eventually.

As I mentioned before, I suspect that the code running on the new Atmega8u2 chip on the Arduino Uno boards is to blame, simply because there are problems accessing the port outside of the Arduino IDE entirely (verified with minicom).  Perhaps it's only using half-duplex serial, so while it's busy sending it can't do anything else -- that's just a guess though.  I suppose the bootloader (optiboot) might be involved too, but now I'm really taking shots in the dark.

rgm

The FTDI based boards don't seem to run into this problem because it appears that they don't stream out serial data unless the port is accessed.  On my Arduino Duemilanove, with the following code:
Code: [Select]
void setup()  {
 pinMode(13,OUTPUT);
 Serial.begin(9600);
 delay(100);
 Serial.println("Here we go, duck.");
}

int count = 0;
void loop()  {
 digitalWrite( 13, HIGH );
 Serial.print("*");
 count++;
 if ( count == 80 ) {
   digitalWrite( 13, LOW );
   Serial.println();
   count = 0;
   delay( 200 );
 }
}


The LED blinks whenever the board has power, but the TX light only goes on when the port is accessed with the serial monitor, minicom, or "cat < /dev/ttyUSB0".  The means that the FTDI based arduinos are not subject to this issue -- they're able to be reprogrammed easily, even if they contain a program that hammers the serial port.  The Arduino Uno behaves differently in that the TX light is always on.

rgm

#8
Oct 06, 2010, 09:05 am Last Edit: Oct 06, 2010, 08:48 pm by rgm Reason: 1
Like an idiot I did it again (tight Serial.print loop) -- but this time I've had no luck repeatedly smashing the "Upload" button in the IDE  -- I guess the delay in the code is too small for me to "catch" it.  I can no longer reprogram the Uno since it won't listen to me / present the OS with a working port for long enough to talk to it.

I'll try again on Windows or Mac later this week.

Edit (an hour later): This got me past my "bricked" condition, but after intentionally re-bricking I could not duplicate its success, so I think it was coincidence.
(IDE is open)
Step 1: rm /var/lock/LCK..ttyACM0
Step 2: Click "upload" again.

rgm

Nobody on the Arduino team reads these?  I cross-posted in the bugs forum:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286350399

I put optiboot on a Duemilanove and it still works fine in this scenario, so it's not the bootloader.
It's a pretty serious usability regression compared to the Duemilanove.  I hope they're focused on releasing the code for the 8u2 chip so that some progress can be made here in the community (although apparently the community of Linux Arduino Uno users is very small and non-vocal?)

I feel frustrated and with ever dimming hope of a solution.

mellis

I don't have a good understanding of what's going on here, so I'm hoping someone from the community can help figure out a good fix.  The code for the 8U2 has been available since the Uno started shipping.  It's in the hardware/arduino/firmwares directory of the release and online here: http://github.com/arduino/Arduino/tree/master/hardware/arduino/firmwares/.  Maybe we can find a change that stops the 8U2 firmware from relaying serial data until a program on the computer opens the port?

F.Munerotto

The same happens to me!

Upload works 1 time out 7-9 times, serial monitor never (I use gtktty).

I use Ubuntu 10.04
Code: [Select]
mune@lello:~$ uname -a
Linux lello 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 GNU/Linux


and, despite the CPU is an AMD 64 dual core, it is a 32 bit system (more software).

The only non-standard thing is that I use already a USB-serial converter (/dev/ttyUSB0) to communicate with a little UPS; the system for my arduino uno creates a /dev/ttyACM0 device.

I use the latest (0.21) IDE
Code: [Select]
mune@lello:~/Apps/arduino-0021$ ./arduino
Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7

Jamexcb

I have the same problem.
My arduino uno works well on my Mac and in windows 7 on parallels.
But on my desktop with Ubuntu 10.04 no!
I use 10.04 because is the LTS version.
The  launchpad.net/~arduino-ubuntu-team/ version is a old version and don't have Arduino Uno interface.
After i connect arduino to USB Port and open 0021 the menus, like tools, are really slow to open. More than 15sec..

marlar

I have the same problem. It locks up when addressing the serial port from within the Arduino program.

Has any one found a fix?

Note: the delay fix after Serial.begin() does not work.

K-MOB

Add me to the list.  My Duemilanove has/had no issues.  Just got an Uno, and I'm seeing all of the same things.  Uploads are now through ACM instead of USB, Tools menu is very sluggish.  However, repeating does not ever seem to push the program through.  The TX button seems to be permanently lit, and after each try, I have to delete the lock file from /var/lock and reselect ACM from Tools.

I'm running 10.04 as well.  Suggestions would be very much appreciated!


Go Up