next topic »

[on:]

Apologies for the cross-post, but this is a more focused report than my other thread, which is at:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286088093

The Arduino Uno becomes extremely difficult to reprogram in Linux after uploading something akin to:

Code:

void setup() { Serial.begin(9600); }
void loop() { Serial.println("*"); }

Although the example above is contrived, it's not uncommon to "stream" sensor readings.
The device /dev/ttyACM0 is simply not accessible anymore (or only for fractions of a second once in awhile).  This is not a problem with the FTDI based units.

See linked thread for more details and some wild speculation (8u2 issues?  half-duplex serial?  OS driver issue?).

[Reply #1 on:]

Problems with DTR not resetting the atmega8u2 and the atmega328p to enter in the bootloader when you want to program?..
Maye pressing reset when you want to program it work.

[Reply #2 on:]

I would point the finger at the bootloader rather than the type of USB interface.  Theres reports popping up all over the place with problems with 'Optiboot' used on the Uno.  

[Reply #3 on:]

I don't think it's the bootloader.  To recover from my most recent test I swapped the ATmega328P from my Uno and put it into my Duemilanove.  I switched the "Serial Port" to /dev/ttyUSB0 but had to leave the board type as "Uno" or uploading would not work -- I figured this was because the ATmega328P had optiboot on it.

After that, I was able to reprogram the chip easily even though it had the tight serial loop code / optiboot.

@Senso:  pressing reset doesn't really help.  I tried varying my button push timing systematically (then randomly) and coudn't come up with a reliable procedure that I could say with certainty was responsible for the success of the upload, though I did get it to work once (but not with the example program in the OP of this thread).

[Reply #4 on:]

It looks like the most useful comments regarding this issue are on the Arduino blog on this post:
http://arduino.cc/blog/2010/10/02/arduino-0021-for-windows-mac-linux-fixes-pwm-bug-on-uno/#comments

[Reply #5 on:]

Plan B: kick the bootloader down the drain. Use an ISP. The bug searching for the bootloader costs to much time. In addition the ISP will allow to keep the serial monitor connected while uploading.

I did not use the bootloader for almost a year by now. I definitely do not miss it. Gives me a little bit more free memory and higher upload speed as well.

Udo

[Reply #6 on:]

Yes, a fine option for programming the Uno, but as I've previously outlined in this thread, the problem does not appear to be with the bootloader (see reply #3).  Additionally, not everyone has an ISP, so that is a bad option for democratizing the tool.

It appears that we need someone with Linux CDC / ACM kernel module experience, someone with LUFA / USB / 8u2 programming experience, or someone with an oscilloscope or logic analyzer to look into this and check out what's going on when the Arduino Uno is sending serial data that causes the /dev/ttyACM0 port to become inaccessible.  Bad symptoms happen completely independently of the Arduino IDE -- an Arduino Uno sending serial data hooked up to an Ubuntu Linux 10.04 LTS or 10.10 Meerkat (kernel version 2.6.35) computer is a PITA to use even without the IDE at all -- simply attempting to open the port with a program like "minicom" fails most of the time.

[Reply #7 on:]

I am no expert for Linux / Kernel issues. However I had significant issues with Ubuntu and the AVRISPmkII. The issue was caused by how Ubuntu handled USB. The issue disapeared after upgrade to 10.04. I did not upgrade to 10.10. So if you suspect the Kernel, then you have to tell which Kernel you are running.

Udo

[Reply #8 on:]

I've got Ubuntu 10.04 and got the same issue. I plug out the board, plug it in while holding the reset button and restarting the IDE. Then I get the message:
RXTX Warning:  Removing stale lock file. /var/lock/LCK..ttyACM0

And everything works fine until I open the Serial Monitor again. Sometimes I get this message:
RXTX fhs_lock() Error: creating lock file: /var/lock/LCK..ttyACM0: File exists

maybe this helps somebody to solve the problem...

[Reply #9 on:]

Hi all,
I have the same problem with my Arduino Uno / Ubuntu 10.04 LTS/64 bit (I can break the look with Win7, however).

Would it be a solution to add a switch to the setup and within the serial look check whether the switch is pressed. If the switch is pressed the serial loop is exited. This would be a software/cheap hardware solution to stop continuous data stream to the serial port.  Then it should be possible to send another sketch to the Arduino.

Cheers

Karl-Heinz

PS: I am not a programmer, but an endless loop without any control does not look like good programming practice to me.

[Reply #10 on:]

Hi all,
I just wanted to report that a quick test revealed that my suggestion is working.
Try it yourself... just a very quick test.

Code:

/*
 Button
 
 Just a proof, that it is possible to overcome the limitation of
 the current Arduino Uno to look when permanently sending serial data.
 
 Turns on and off a light emitting diode(LED, i.e. red) connected to digital  
 pin 13, when pressing a pushbutton attached to pin 2.
 Turns on and off a LED (i.e. green) connected to digital pin 12,
 when pressing a pushbutton attached to pin 3
 
 Reads an analog input on pin 0, prints the result to the serial monitor
 
 
 The circuit:
 * red LED attached from pin 13 to ground
 * green LED attached from pin 12 to ground
 * pushbutton attached to pin 2 from +5V
 * pushbutton attached to pin 3 from +5V
 * 10K resistor attached to pin 2 from ground
 * 10K resistor attached to pin 3 from ground
 * 10K resistor attached to pin A0 from ground
 * light dependent resistor attached to pin A0 from +5V
 
 * Note: on most Arduinos there is already an LED on the board
 attached to pin 13.
 
 
 created 2005
 by DojoDave <http://www.0j0.org>
 modified 28 Oct 2010
 by Tom Igoe
 modified 2.11.2010
 by KHK
 
 This example code is in the public domain.
 
 http://www.arduino.cc/en/Tutorial/Button
 */

// constants won't change. They're used here to
// set pin numbers:
const int buttonPin = 2;     // the number of the pushbutton pin
const int ledPin =  12;      // the number of the LED pin
const int buttonPin2 = 3;     // the number of the pushbutton pin
const int ledPin2 =  13;      // the number of the LED pin


// variables will change:
int buttonState = 0;         // variable for reading the pushbutton status
int buttonState2 = 0;         // variable for reading the pushbutton status

void setup() {
  Serial.begin(9600);
  // initialize the LED pin as an output:
  pinMode(ledPin, OUTPUT);      
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin, INPUT);  
 // initialize the LED pin as an output:
  pinMode(ledPin2, OUTPUT);      
  // initialize the pushbutton pin as an input:
  pinMode(buttonPin2, INPUT);  
}

void loop(){
  // read analog input and prints to serial line
  int sensorValue = analogRead(A0);
  //Serial.println(sensorValue, DEC);
  
  
  // read the state of the pushbutton value:
  buttonState = digitalRead(buttonPin);
  buttonState2 = digitalRead(buttonPin2);

  // check if the pushbutton is pressed.
  // if it is, the buttonState is HIGH:
  
  if (buttonState == HIGH) {    
    // turn LED on:    
    digitalWrite(ledPin, HIGH);
    Serial.println(sensorValue, DEC);
  }
  else {
    // turn LED off:
    digitalWrite(ledPin, LOW);
  }
  
  // button 2 has no meaningful function at this moment
  // besides switching on LED 2 when pressed
  
  // check if the pushbutton is pressed.
  // if it is, the buttonState is HIGH:
  if (buttonState2 == HIGH) {    
    // turn LED on:    
    digitalWrite(ledPin2, HIGH);  
  }
  else {
    // turn LED off:
    digitalWrite(ledPin2, LOW);
  }
  
}

Cheers....

Karl-Heinz

[Reply #11 on:]

Firmware update to the 8u2 chip fixed this.  Everybody that hit this issue should donate to Dean Camera's Pledgie fund via the LUFA project page at: http://www.fourwalledcubicle.com/LUFA.php

Here's his tweet with the link to the github page that hosts the new firmware:
http://twitter.com/abcminiuser/status/9731256052883456


The procedure to fix is detailed in:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286088093/34#34

[Reply #12 on:]

>>PS: I am not a programmer, but an endless loop without any control does not look like good programming practice to me.

Hi Karl-Heinz,

that is true. The reason this happened to me is that I uploaded an example from the example library: the DigitalReadSerial example in the Basics section. I did not look at the code in that much detail before I uploaded it, not expecting that a program in the Arduino IDE could brick my UNO.