Uno sending serial data becomes un-connectable to Serial Monitor

[I had the bad timing to post this a few hours before the old forum closed. I'm re-posting it here because I would really like to get this issue solved for me and everyone who's had a similar one, from the looks of my search results! I hope this is the correct new area.]

I've had an exceptional amount of difficulty getting the serial monitor working reliably in the arduino software v22 under Ubuntu Linux. It sometimes works if the amount of data coming over is very low or very intermittent (e.g., once per second or slower). First, the background:

I have a new Arduino Uno. It appears to work normally. I am powering the Arduino over USB (no external power.) I am using the arduino IDE v22 under Ubuntu Linux ~9. I'm using java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) I have added myself to the "dialout" group. My Uno always appears as /dev/ttyACM0, as follows:

ls -l /dev/ttyACM0 crw-rw---- 1 root dialout 166, 0 2011-01-23 16:34 /dev/ttyACM0

dmesg: [243199.131605] usb 4-1: new full speed USB device using uhci_hcd and address 29 [243199.342928] usb 4-1: configuration #1 chosen from 1 choice [243199.345892] cdc_acm 4-1:1.0: ttyACM0: USB ACM device

I can load, compile, and upload most sketches without difficulty. However, if a sketch sends more than a trivial amount of data with Serial.print(), things go haywire. I will describe in detail below, since I've managed to find a few other posts describing similar symptoms but I didn't see any posts that got to the bottom of it. Hopefully I can help the experts drive this to ground and get it sorted for all of us. I am happy to do additional debugging on my side if it will help.

To set a baseline, I called up the Blink example (which does not use any Serial communications) and loaded it in to the Uno. After the sketch loads, the "L13" led blinks slowly at ~0.5Hz as expected. At this point, with the Uno connected to the laptop and the arduino software running, I can open the serial monitor window and close it as much as I like. I can change the settings and the settings are recalled the next time I open the window. I don't see anything in the serial monitor window, but because Blink does not send anything, I don't expect to. I can use the mouse to select menus in the IDE and make selections with good responsiveness. I can quit the Arduino IDE and start it back up again, and it quits and loads quickly. In fact, I can load my own complex sketches that don't write serial data back to the PC and everything works OK. I belabor all of these points only because they contrast with what happens when I load a sketch using heavy Serial output.

With the Uno loaded with Blink, I called up the example Examples/Basics/AnalogReadSerial and made one small change: I added a delay(1000); to the start of the loop (in order to observe and test some things which I will note below). I sent this slightly modified Blink sketch to the Uno. The sketch loads (Uno RX/TX lights flash, Uno resets) and starts running. The Uno's TX light blinks slowly, about once per second, (which is expected since I added the delay(1000) line to the loop). The interesting thing here is that the TX light stays on for about half a second each cycle, then turns off. I click on the serial monitor icon in the Arduino IDE, and after a second or so, the window comes up and I start to see the output of the sketch. ALSO, the TX light on the Uno has changed its behavior: It still comes on once per second, but it only stays on for a few ms. It's more of a brief flicker than a blink. When I see this behavior I know the Uno has achieved some sort of "happy" state for serial comms with the host. I can open and close the serial monitor with the sketch running on the Uno; whenever the serial monitor window is closed, the TX light duty cycle is about 50%; whenever the serial monitor window is open, the duty cycle is maybe 1%. I can open and close the serial monitor window as often as I like. I can use the menus in the IDE and they are very responsive; I can quit the Arduino IDE and re-start it very quickly.

Now, if I take the "delay(1000)" line OUT of the sketch and re-upload it in its stock form, the situation changes dramatically.

I open the AnalogReadSerial example again and press the Upload button in the Arduino IDE and the sketch loads. The sketch starts running as soon as it's done loading, as expected, and the Uno's TX light turns on solid. It does not turn off, ever. Now I click the serial monitor button, and after a few seconds, I get the following error: " Serial port '/dev/ttyACM0' already in use. Try quiting any programs that may be using it." Taking a cue from another thread, I do a "lsof | grep ttyACM0" at this point; the grep returns zero rows (no hits.) The /dev/ttyACM0 device is still present, but there is a new line in the dmesg dump:

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

At this point, the IDE is very sluggish and unresponsive. Menus do not drop down for seconds at a time. I can quit the IDE, but it takes some time to actually respond to the close box click. (The Uno is still on this whole time, BTW.) When I start the IDE back up, it takes a long time for the GUI window to come forward. Before it does, on the command line from which I start the IDE, this message appears:

RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyACM0

Now when the IDE finally does come up and I hit the serial monitor button, I get a different error: " Serial port '/dev/ttyACM0' not found. Did you select the right one from the Tools > Serial Port menu?" At this point I verify that the device still exists with an ls -l /dev/ttyACM0, and sure enough it is still listed and has not changed. I check dmesg to see if a different port has appeared, but there are no more USB connect messages. There are, however, a whole lot more of these:

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

(After some poking around after this line of experimenting, I can report that this line appears a few seconds AFTER the serial monitor button is pressed and almost immediately before the "port not found" error message is printed. It also appears after a failed upload of any sketch when I try to replace the problematic one running in the Uno.)

Now I am in a tough spot. I can't just open the Blink example and upload it, because the IDE claims it can't find the serial port /dev/ttyACM0.

Furthermore, at this point the Arduino Uno RESET button does not appear to work quite right. When I press it, the "L13" LED blinks three times in rapid succession, but the TX light never goes out. If I hit the upload sketch button in the IDE and then hit the Uno's hardware reset button after just the right fraction of a second delay, I can successfully load a replacement sketch. There is a very small time window that if I am lucky, I can hit and have the Blink sketch reload into the Uno and things return to normal.

So, it seems that there is something going on in the USB interface on the Uno and its relationship with the host-side driver that makes connecting to the Uno impossible if the Uno is already trying to send a lot of serial data to the host.

I am working with an MSGEQ7 and seeing the data quickly is important to figuring out how my circuits are behaving, so the (delay(1000)) is not really a solution. Can anyone help?! I am happy to do investigations and testing on my side if someone can point me in the right direction. I have some java and c/c++ development experience.


This is a perfect description of the Uno firmware bug. The good news is that it can be completely cured with a firmware upgrade and I wrote a post on the old forum showing how to do it. Bad news is I can't remember where the post is :) But keep searching and you should find it, if not I'll try and re-write it tomorrow. Or maybe someone bookmarked it.

You might find that on Ubuntu 9 your version of dfu-programmer (the firmware uploading program) is too old, but I think on the same thread someone else had instructions on how to compile the latest one from source.

Here iti is:

the right firmware is now in the 22 arduino version package look inside subdir of your install

Sweet! Thanks so much. I will try that first thing this weekend during my arduino project time! :grin:

Ok, I couldn't wait until this weekend to try it. IT WORKS! Caloo, Calay, happy day!

Thanks again. :-) I am very much looking forward to working with my fully-functional Arduino Uno now. :-)

I've experienced same problem. Before try to upload new firmware for the usb chip (as described here: i'd like to know if the above mentioned method is the same as the one describer in newest arduino package, where (in hardware/arduino/firmwares/) there's a correct firmware, and (in the README.txt file) i can read the following istructions for upload:

Arduino Uno and Mega 2560 Firmwares for the ATmega8U2
To burn (Uno):
avrdude -p at90usb82 -F -P usb -c avrispmkii -U flash:w:UNO-dfu_and_usbserial_combined.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

So i'm wondering if the two methods (the one described in the forum and the one in the README) are equivalent or whic one is preferable.

Thanks, Giovanni

They aren't the same. To use the method described in the Arduino package you need to use an ISP programmer and you need to connect it to the ISP header for the 8u2 (the one on the corner of the board, NOT the 328 one which is on the bottom middle) But most original UNOs don't have the header soldered in place, so you would need to solder it in yourself.

I'd say it would be the preferable method if you have an ISP programmer and the header soldered in place. If not, the DFU method is easier and the end result is just as good. (The ISP method would update both serial and DFU firmwares, whereas the DFU method only updates the Serial firmware. But since the DFU firmware hasn't changed, the end result is the same)

Also you need different HEX files for the two methods, the correct one for the DFU method is in the arduino-usbserial directory from IDE 0022 or later, or you can download it from the repository.

ok, now it's perfectly clear. So in the week end i'll go with the DFU method (whit fingers crossed ;) ) Thanks for replaying.


When I try to access the page describing the method, I get "Error: You are not allowed to access this section.", probably because I don't have an account on the old forum. Would anyone be able to repost the method described by stimmer? The inaccessible URL is

This is the copy of the thread that was imported into the new forum:,111.msg759.html#msg759

Much appreciated


This sure beats adding this to the beginning of my code to force the transmitting to stop so I can upload a new sketch.

if (digitalRead(StopPin)==HIGH) { return; }

Also see the tutorial here:

Hi Everyone !

Thanks tribble for this accurate description, since I've experienced exactly the same problem. It's good to know there's a solution somewhere!

I was testing a simple serial transmission when the TX led turned on, everything got stucked like you described. Even the reset button didn't modify this behaviour. USB plug/unplug didn't either !

After a few hours of head scratching (and forums wandering), I have succeeded to get the control back on my Arduino. I can now upload some programs, and they run correctly.

Now, (as a consequence I suppose), my reset button doesn't seem to work : the Uno gets back to its previous behaviour before reset. If I "advanced" reset (press reset / plug usb in / release reset), the Led13 blinks three times continuously.

Since my previous experiences were with the Duemilanove, I thought that a reset button press would get the UNO back to a "factory reset", which is the blink program in the Duemilanove case.

I have a question : what do these three blinks mean ? This is not a major issue, I just want to know if I miss something !

Again, thank you to all of you for help on this topic !



(Ubuntun 10.04 + Uno)

This is a seperate bug with the Uno (Sketch Amnesia), this time in the bootloader.

Optifix is the cure :

Thanks !

Hello all--

I'm a complete noob, and I'm having the exact same problem with my new Arduino (it looks exactly like this one

The procedure to fix it looks straight-forward, but I can't figure out how to get it into dfu mode. The documents say "...all that's needed to enter DFU mode is to briefly short enough to short pins 5 and 6 of the 8U2 icsp connector..." but that doesn't seem to do anything (I connected pins 5 and 6 with a wire, is this the correct method?)

Can anybody point me to more detailed documentation, or offer a better procedure? I need something that a slow-witted 4 year old could follow. Thanks in advance

I haven't got a Uno SMD but yes, it should go into DFU mode just by shorting pins 5 and 6 on the 8u2 ICSP connector (the leftmost two pins on the 6-pin connector on the top left of the picture - NOT the digital pins numbered 5 and 6)

to test if it worked, type lsusb in a terminal. If you see 03eb:2ff7 it worked, if you get 2341:0001 (or similar) it didn't work.

It worked; thank you.

I was shorting out the wrong pins; the correct pins aren't numbered, and I assumed they would start numbering at 0, like the labeled pins, so that means I expected they should have been labeled 0-5. Since there was no pin 6 in that block (according to my bad assumption), it couldn't possibly be the correct set, so I tried the other ones. D'oh!

Thank you very much