Problems with 0021 on Ubuntu 10.04 Lucid Lynx

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:
https://github.com/arduino/Arduino/tree/master/hardware/arduino/firmwares/arduino-usbserial/(click 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:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285962838/10#10

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.
[smiley=vrolijk_26.gif]

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
TIA

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)
processing.app.SerialException: Error opening serial port '/dev/ttyACM0'.
at processing.app.Serial.(Unknown Source)
at processing.app.Serial.(Unknown Source)
at processing.app.debug.Uploader.flushSerialBuffer(Unknown Source)
at processing.app.debug.AvrdudeUploader.uploadViaBootloader(Unknown Source)
at processing.app.debug.AvrdudeUploader.uploadUsingPreferences(Unknown Source)
at processing.app.Sketch.upload(Unknown Source)
at processing.app.Sketch.exportApplet(Unknown Source)
at processing.app.Sketch.exportApplet(Unknown Source)
at processing.app.Editor$DefaultExportHandler.run(Unknown Source)
at java.lang.Thread.run(Thread.java:636)
Caused by: gnu.io.UnsupportedCommOperationException: Invalid Parameter
at gnu.io.RXTXPort.setSerialPortParams(RXTXPort.java:171)
... 10 more
processing.app.debug.RunnerException: 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).

I've also been able to fix the Arduino UNO not working on Archlinux using the procedure from post #34.

I'm now able to upload code and use the serial monitor without problems.

Anyway, the tx led still remains on when no program is reading the serial port. Is this normal or also happens to you guys?

My reference to the bootloader is related to this issue from before optiboot became 'official' : Google Code Archive - Long-term storage for Google Code Project Hosting.

It never seemed to be resolved. It uploads code fine and runs the serial out OK until its disconnected and hooked up to my 'live' home monitoring system when it appears to forget the sketch and returns to the default blink pattern. It does it on either Uno or Duemilanove if I put the Uno (optiboot) bootloader on either. Both work Ok with the Duemilanove bootloader. The USB 8U2 problem with the old firmware on the Uno is a seperate issue (or non issue with the new firmware).

Device Firmware Update is a USB standard, and is safe to use. If you mess up, you can dfu reset and try again. I'm cross posting stimmer's post from here:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285962838/10#10

To here in order to make the information available to non-forum members in the interest of free, wide dissemination of information. The other forum requires login, this one doesn't.

-rgm

Here's a way to get the Uno into DFU mode without any soldering. Put two wires into GND pins on either side of the board. Then put the other ends of the wires on the board as follows:

The sequence is, hold the first wire on the top left 8u2 ICSP pad, then touch the second wire against the left side of the capacitor below the RX LED. Then remove both wires. It's slightly different to the sequence in the instructions but it seems to work.

Be careful with the second wire as the capacitor is quite near a 5v track. You can try using a low-value resistor instead of a wire if you are worried about blowing up your board.

To get back to normal mode, hold wire 1 in place as above, press the reset button, then remove wire 1. Or just unplug the USB cable and plug it back in.