Problems with 0021 on Ubuntu 10.04 Lucid Lynx

I bricked my UNO by uploading the DigitalReadSerial example (Ubuntu 10.10, IDE 21)! I have tried all the suggestions listed here, and have even tried Windows to restore it (by uploading a sketch without serial print), but without success.

Question: If I get a USBtinyISP and re-burn the bootloader, is that also going to wipe out the existing serial sketch?

Note: serial communication under Ubuntu with the Duemilanove works without any problems.

I bricked my UNO by uploading the DigitalReadSerial example (Ubuntu 10.10, IDE 21)! I have tried all the suggestions listed here, and have even tried Windows to restore it (by uploading a sketch without serial print), but without success.

So after you loaded the DigitalReadSerial sketch using a linux machine, you couldn't get the Arduino to communicate with a windows machine?

Is this a compilation error with linux avr-gcc? :-/

Is this a compilation error with linux avr-gcc?

Probably not. The problem is this: When you look at the code

/*  DigitalReadSerial

void setup() {
  pinMode(2, INPUT);

void loop() {
  int sensorValue = digitalRead(2);
  Serial.println(sensorValue, DEC);

you'll notice that as soon as the sketch starts, it starts sending data through the serial port (converted to USB). In addition, there is no delay in the loop so that the Arduino keeps sending data without a break in between ("tight loop").
Unfortunately, this is the same connection through which you want to upload a new sketch, so there is a collision. The upload just does not get a chance to get through because the sketch occupies the port. The only chance is to catch the period after a reset where the bootloader has enabled the USB/serial port, but before the sketch starts.

The situation would be better if the sketch had a delay before the Serial.begin(9600) command and a delay in the loop.

In addition, there seems to be a problem with the way Ubuntu handles the Uno USB port which it recognizes as ttyACM0. Ubuntu recognizes the Duemilanove USB port as ttyUSB0, and I have had no problems with that.

Well, how loose should the loop be? Right now I have 5000 millisecond delay between Serial.writeln() commands and it's still fubared 4/5 times.

I agree, loose loops are neither a perfect nor particularly effective workaround to this issue. Although somewhat tolerable, it's extremely unpleasant to use, not to mention incredibly limiting, especially when attempting to communicate with a Processing sketch (or anything else using serial). I hope that someone can share a better solution soon. It's been a long time, and the Arduino Uno is effectively br0ken on GNU/Linux. I'm sick of unplugging, replugging, slow IDE UI, removing lock files, and jamming the reset button and upload code buttons repeatedly.

Does anyone know how the efforts to "fix the linux kernel CDC ACM driver" are going? Are there any efforts to validate the behavior of the 8u2 implementation of a CDC_ACM serial device?

I saw that a new Uno firmware had been uploaded to the Arduino repository. I've been trying it out, it seems pretty good so far, tools menu and serial monitor are much more reliable and it only failed to program once. (Although the Duemilanove was never perfect either)

I got the firmware from here: on the right firmware, then click raw, then save it)

Reflashing the firmware on the 8u2 is a little tricky. Don't try this unless you are prepared to risk bricking your board completely!

You need the dfu-programmer utility:
sudo apt-get install dfu-programmer

Then follow the instructions here to get the Uno into DFU mode:

Then to flash the firmware, do this:
sudo dfu-programmer at90usb82 erase
sudo dfu-programmer at90usb82 flash --debug 1 Arduino-usbserial-uno.hex
sudo dfu-programmer at90usb82 reset

Finally unplug the USB plug, wait a few seconds, plug back in.

The only semi-reliable way I've discovered is this:

  • delay(2000) BEFORE Serial.start in the setup function
  • Start the serial monitor IMMEDIATELY once you have programmed the board, and leave it running the entire time
  • When you want to reprogram, hit the "Upload Sketch" button on the IDE without closing the Serial Monitor manually.
  • Serial monitor closes automatically when you try to upload the sketch, and apparently the timing is perfect to allow the sketch to upload.
  • Restart the serial monitor as soon as you get an "uploaded successfully" message.

It's almost as if any amount of serial output that is not monitored will induce the failure state.

FIXED! It works!

Following the procedure in reply #34 worked well for me (uploading new firmware to the 8u2 via dfu-programmer). My IDE is responsive, minicom and screen have no trouble opening /dev/ttyACM0, and I can use the serial monitor and upload code without issue, even while streaming serial data constantly at 115200 bps.

Thank you stimmer for sharing, and a big thank you to Dean Camera at the LUFA project and David Mellis @ Arduino / MIT, and everyone else who's worked on this.

Just followed the excellent instructions and I can report success as well! :smiley: :smiley:

Thank you! Thank you! Thank you!

Hi all,

Dean Camera here, author of LUFA (the USB stack code the Arduino Uno uses).

Firstly, sorry to everyone for the wait in getting this bug fixed; I was not made aware of it (not owning an Arduino board - I collaborated with my own hardware with the Arduino folks to get the Uno board working) until last week. From then I was able to quickly provide a fix, but it took a few days for remote testing and integration.

The new firmware should be much, much more reliable; the Arduino folks disabled a critical compile flag accidentally in their code fork that would cause "control requests" made by the host to be delayed while serial data was being processed. That led to the troubles you have found; constantly sending serial data would break the virtual serial port.

I hope everyone is able to update their board firmware soon; don't be shy; It is impossible to break your board permanently if upgrading through the DFU bootloader. The worst that can happen is you erase the USB chip's application area without loading in the new firmware, which is very easily fixed just like erasing the main Arduino processor through the bootloader.

My apologies again for the wait, and in future if you have found a bug please don't hesitate to contact me directly so I can produce a fix quickly.

  • Dean

PS: I'll be making some alternative firmwares for USB-MIDI, USB-HID and other classes soon.

I suggest you visit the most.

Do you think gclub was created to test man or gclub was created to destroy mankind, anyway.

Thanks for the advice, - I'm brand new to arduino and am just trying to get my first board up and running. I reckon I put the board into DFU mode and ran the three commands

sudo dfu-programmer at90usb82 flash --debug 1 Arduino-usbserial-uno.hex responded with:

"Error parsing the line.
Something went wrong with creating the memory image."

dmesg now shows the board is detected on connect, but no
"cdc_acm 2-2:1.0: ttyACM0: USB ACM device" msg is produced, and of course the IDE does not recognise the board.

Would welcome any advice

Possibly the file got corrupted when you downloaded it. Could you run:

md5sum Arduino-usbserial-uno.hex

You should get 5680a78c5a9c386914923e39022318cc or 8e01ee236e70bbea43f7eb4e11c9688a, if you got anything else then download it again.

The checksum of the file I've newly downloaded is:
b19b169d3bbe069d847830b0d6ec67c6 Arduino-usbserial-uno.hex

Looks like the downloaded files have changed in the last 8 hrs or so.
The result is still the same.

The second checksum I gave was the one updated a few hours ago. It's definitely getting corrupted on download. What does the file look like in a text editor? (It is an ascii file)

Problem partly solved

The file I was saving was actually the html file pointing to the hex file and it was named ' Arduino-usbserial-uno.hex'. Worked out that "raw" was the actual hex file to download.

However the IDE will still not write to the serial port. On powering up a second time both the IDE and dmesg indicate that ACM0 is the active port.

However compiling and attempting to upload the sketch "Fade" results in the following error:

Binary sketch size: 1230 bytes (of a 32256 byte maximum) Error opening serial port '/dev/ttyACM0'.
at Source)
at Source)
at Source)
at Source)
at Source)
at Source)
at Source)
at Source)
at$ Source)
Caused by: Invalid Parameter
... 10 more Error opening serial port '/dev/ttyACM0'.

At which point /dev/ttyACM0 drops from the IDE.
Restarting the IDE restores /dev/ttyACM0.

Another success for reflashing the Uno USB chip. Transformed the beast completely with my serial heavy sketch :slight_smile:

Muscatelle: It sounds like the firmware has uploaded correctly and now you just have the usual problems people have getting the IDE to upload. Make sure you have read/write permission on ttyACM0. It might be worth rebooting the machine in case there is some other process trying to open the serial port (the command "killall -KILL avrdude" is quite often necessary after a failed upload)

Now just reflash the main bootloader with a Duemilanove version and it might work 'live' as well...........

In your preferences.txt file (whose location is shown in the preferences dialog in the Arduino software), what is the serial.debug_rate? It sounds like the IDE is trying to open the serial port with an invalid baud rate (or some other serial port parameter).