Problems with Arduino boards and serial communication on Linux: How to fix without soldering (rev. 3)

A little over a year ago, serious problems were reported when using Arduino Uno and other Arduino boards for serial communication on Linux systems, most reports regarding various Ubuntu variants from versions 9.10 through 10.10, including 64bit versions. Since this problem has not popped up much recently, I suspect that newer boards don’t have this problem anymore. However, I recently had to deal with Arduino Uno boards bought circa in mid-2010, so I ran straight into these troubles. Read below for a detailed description of the symptoms.

A few weeks after the problem was reported, a firmware upgrade with a fix was published. An article was posted on arduino.cc describing the problem and how to fix it. In order to understand what the problem is and how it is fixed in principle, you should first read this article at arduino.cc describing the problem and their proposed fix.

The instructions posted on arduino.cc require you to solder a resistor to the back of your Arduino in order to flash the DFU bootloader. However, there is another way, as outlined in this forum thread at arduino.cc, describing how fix the problem without having to solder on their board. I cannot say whether this way is safer or not, so (as always) read everything carefully and proceed at your own risk!

On a calming note, the author of the Uno’s USB stack says in a forum post:

“it is impossible to break your board permanently if upgrading through the DFU bootloader”

On a frightening note, the wire-touching procedure described below is commented thusly:

“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.”

Have you made up your mind about trying this? Okay, then let’s go:

Error messages and symptoms When plugging in the Arduino, it registers normally, as reported by dmesg:

[...] cdc_acm 3-1:1.0: ttyACM0: USB ACM device

However, when the Arduino is running a skech that uses even trivial serial communication, the TX LED hangs, and the Arduino IDE reacts very slowly to menu clicks (especially when trying to open the Tools menu). When trying to start the Serial Monitor, the IDE will hang for a moment and finally report errors like this:

processing.app.SerialNotFoundException:
Serial port '/dev/ttyACM0' not found. Did you select the right one
from the Tools > Serial Port menu?

I’m not 100% sure, but I think I also saw the following error message in this context:

avrdude: stk500_recv(): programmer is not responding

When the serial interface dies, dmesg will report this:

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

If you want to upload a ‘safe’ sketch (i.e. one without serial communication), so as to make the board temporarily usable again, you have a few chances:

  1. Use a Windows machine to upload a new sketch.
  2. Reload the cdc_acm kernel module that creates the ttyACM* device nodes (or just reboot your machine) and reconnect, then use some timing and feeling to upload the sketch with the IDE shortly after the Arduino boots.
  3. Play around with the Reset button on the Arduino board and use some timing and feeling to upload a new sketch.

Of course, that’s no real solution. So let’s get to fixing the board.

Downloading the firmware and preparing to flash You will need a tool called dfu-programmer. This is available fromthe Ubuntu repositories, but reports say you should have at least version 0.5.1. If can only get an older version from a repository, you should at least be able to compile 0.5.1 if you have the lubusb-dev package.

Get the right firmware code for your board from this page by selecting the correct board version (‘Arduino-usbserial-uno.hex’ or ‘Arduino-usbserial-mega.hex’), then save the file linked from the “Raw” button at the top right of the code display.

Putting the Arduino board in DFU mode and flashing This requires two short (about 5 centimeters or 2 inches) pieces of wire and two steady hands. First, put both wires into the GND sockets as shown in the picture. Then connect the board with a USB cable, then first hold the upper wire to the contact as shown, while touching and releasing the lower wire the the left side of the indicated capacitor:
Update: Contrary to what is pictured here, it seems that at least for some Arduino Mega 2560, the second wire is not required. Try just connecting the first wire as shown, and if the Arduino enters dfu mode immediately (see below for how to tell), you’re good without needing to connect the second wire.

The LED labelled “L” may give two short blinks, unless the board is running a sketch that uses the “L” LED. Even though it may seem like the Arduino is just normally running its sketch, if you have executed the procedure correctly, the Arduino is now in DFU mode. You can verify this by examining the output of lsusb. Instead of reporting with ID 2341:0001 as usual, the Arduino will report with ID 03eb:2ff7 Atmel Corp. if it is in DFU mode. When you have made sure the board is in DFU mode, run:

  1. sudo dfu-programmer at90usb82 erase
    1. the RX LED will come on and stay on
  2. sudo dfu-programmer at90usb82 flash –debug 1 Arduino-usbserial-uno.hex
    1. use the correct filename that corresponds to your board’s firmware!
    2. dfu-programmer should output something like:
      Validating...
      4058 bytes used (49.54%)
    3. the TX LED will come on and stay on, so now RX and TX will be glowing
  3. sudo dfu-programmer at90usb82 reset
    1. All LEDs are now off.

Now, unplug the Arduino and wait a second. After this, everything should work smoothly, even serial-heavy sketches!

Good luck, have fun and don’t hesitate to post a comment if you have new/more precise information!

5 Kommentare
  1. Jorge sagte:

    Thanks! Till now I’ve been using your third workaround for a Mega2560 (basically, I hold the reset button, connect the arduino board via usb, click upload and release the reset button while it’s compiling/about to start uploading) and it works quite reliably, but it’s also very annoying and time wasting.

    However, flashing firmware sounds a bit scary, so I wonder if it’s possible to back it up before flashing? I’ve also read that it’s possible to retry the process if it doesn’t work, right?

    By the way, do you know why this only seems to affect Linux?

    Danke!

    • Michael Büker sagte:

      Hey Jorge,

      you would be flashing the bootloader (‘firmware’ isn’t exactly the right word, I think), and indeed it is apparently possible to repeat the process (see the last post in this thread) and not dangerous for your Arduino to do so.

      I can understand you are sceptical of this process, but maybe some more information can encourage you – first, there is another blogpost from somebody who has apparently also successfully applied this procedure. Secondly, the transfer of the DFU file (with the dfu-programmer at90usb82 flash –debug 1 Arduino-usbserial-uno.hex command) goes very quickly, so you don’t really have to worry about a power failure, another program interfering or something like that. I have also successfully flashed a Mega 2560 with this method, not just an UNO. Also, remember that on the forums where I got this information, it was asserted that you cannot break your Arduino when updating the DFU.

      But it certainly is your decision, so if you are still unsure, you might want to search around and maybe find somebody else that has already performed this procedure to answer your questions.

      I’d love to hear back from you when you’ve decided what to do!

      • Jorge sagte:

        Wow, thank you very much for the fast and detailed answer!

        Actually, I’m a bit held back because I’m building a quadcopter with two friends and I’m the only one using linux and thus having this issue, but I’ll certainly let you know what I ended up doing.

    • Michael Büker sagte:

      Oh, and I don’t know in detail why only Linux is affected, but it’s plausible, since the internal code used to communiate with serial devices is completely different between Linux and Windows.

Hinterlasse eine Antwort zu Michael Büker Antwort abbrechen