Arduino reset upon serial Java connection


There's already quite some text written about this subject, but none provided a real proper solution on how to solve this structurally. Let me first explain briefly: I use an Arduino Mega Rev3, and connect from a PC (Windows 7 64bit) via the USB/serial port with a Java program using the RXTX library. My friend is doing the exact same thing from a Mac (same Arduino, same Java...).

Each time when I open() the serial port in Java, the Arduino reboots (this is the same with many other serial programs). Note that the issue is not related to the Java code (no code posted here), but simply that upon opening the serial port, the DTR line on the Arduino asserts (=goes low). This resets the Arduino via the 100nF cap. This reset is done by design by the Arduino folks, so that the bootloader starts and checks if new code need to be loaded.

HOWEVER, when you are in full running with the Arduino, and want to make a serial connection (for monitoring, control through Java, whatever, ...), you do NOT want to have the Arduino rebooting in the middle of your program. This would be very bad practice.

So I'm looking for a structural solution to this. There are many proposals circulating around the web, many of those changing the Arduino HW. I do not want to make such changes, because the HW should remain untouched. Yes I know there is a solder-jumper that you could cut, but then you loose the ability to be able to load the sketches without pushing the reset button. I'm looking for a transparent solution to all that.

Given the Arduino folks have designed a custom-made solution for sketch upload (DTR asserting to Reset line), and that the recent models of the Arduino boards are no longer using the FT232RL, but an atMega16u2 (or 8u2), I believe it would be more appropriate to update the firmware one way or the other, so that it detects whether there is sketch-upload needed, or any other serial connection, and make decision to assert or not the DTR line.

Any thoughts or ideas are welcome.

Regards, -Dan

The solution is to use a USB / serial driver that does not assert the DTR when it is opened. That will require you to either:- 1) Rewrite the Java driver / computer's OS driver. 2) Use a silicon Labs USB / serial chip, on a Mac, which does not support DTR on connect, and wire directly into the TX & RX pins. 3) Write your java code so it does not keep opening and closing the serial port.

Now are you sure that cutting a link or fitting a switch on the arduino, or smothering the pulse with a capacitor is not a whole lot easier? Most people would disagree which is why there is not a ready written alternative. If you do write one then please make the code available to others.

but none provided a real proper solution on how to solve this

They are real proper solutions, only you chose not to find them acceptable.

Hi Mike,

thank you for your considerations.

The first solution (rewrite driver) is not really an option, as these drivers are generic. Changing this would entail that I have customized drivers. These drivers are also used by many for many other types of communications.

About the second solution (serial chip), we use the existing build-in USB ports (PC & Mac). Again the solution must remain standard. There are many folks out there having similar problems with Arduino DTR, so we should avoid telling them they need another type of USB port.

About your third solution, yes this is possible, and I will check into this. Good practice says that you first need to poll if the port of available before you allocate it to your own application.

I truly understand what you are trying to say, and I appreciate your thoughts. I was also hoping there would be someone who would be willing to go through the Arduino mega16u2 firmware and check if this can be adapted.

regards, -Dan

I was looking at this problem recently (I will explain in a moment why the problem has gone away). I tried adding capacitors and resistors as some web pages suggest but nothing would prevent my Uno R3 from rebooting. I had decided that I would cut the special trace to disable auto reboot and connect the two connections to a simple switch which I could close if I wanted to upload more code. This seems to me a very practical solution to the point where I wonder why better provision isn't made for it on the R3 board and I wonder why the Arduino website recommends other solutions.

However in the end I didn't cut the trace because another solution presented itself (and consequently I don't know if cutting the trace works as I expect).

As I was designing a stripboard layout for a shield that would hold various bits and pieces - leds, resistors, transistors etc - I realized that it would actually be easier to build the stripboard with a standalone 328 programmed with a FTDI cable (both of which I had). I have put two headers for the FTDI cable on my stripboard. One connects all 6 pins and is used for programming. The other doesn't connect the RTS pin and I use that when I just want to read data from the 328 without it resetting.


Is software serial not a possibility? Simply stay away from the hardware UART. You could also "lift" the DIP pin on the 328 uC so that physical pin #1 is not in the socket - crude, but certainly feasible for a UNO that will be in a project for some time but eventually returned to the shop/lab for future use.


Hello moderators,

I suggest this topic be moved to improvments arduino because it has nothing to do with personal project !

This issue seems strong tabou for lot of people worldwide wether arduino or not arduino, the real issue being of RXTX java not being maintained, still open sourced and the DTR effect has been solved so far always using Quick & Very Dirty tricks which will create more and more confusion through time.

One suggestion would be that arduino community rewrite a specific RXTX where it will be parametered (DTR rise or not) so arduino IDE or whatever other Java GUI would software program the behaviour of DTR.

Just my 2 cents, Albert