Why does the Arduino restart its program, when I connect a terminal program?

[system]

I've built one of these boards,

Prototino

With this breakbout board,

SparkFun FTDI Basic Breakout - 3.3V - DEV-09873 - SparkFun Electronics

I've downloaded the following sketch to test the board
and monitor the serial output.

int count=0;
void setup()
{
  Serial.begin(9600);  
  Serial.println("PROTOTINO 5V/16MHZ TEST");
}

void loop()
{  
  count++;
  delay(300);
  Serial.print("Count=");
  Serial.println(count);
 }

To make it easy on the users who will be monitoring the Arduino when it will be running in the real project ,
I want use a plain Terminal program that they are familiar with (Hyperterminal, TeraTerm Pro, etc)
instead of the Arduino IDE to monitor the Serial output.

In the Arduino IDE, I've deselected the COMPORT used for downloading/monitoring the Arduino.

After connecting Teraterm to the COMPORT used by the cable connected to the Arduino,
the program running on the Arduino restarted, as if power had been cycled.
(Teraterm does see the serial output of the Arduino, though)

Why is this?
What causes the Arduino to restart when a program is connected to the COMPORT?

FWIW- The program in the Arduino also restarts- when I open the Serial Monitor in the Arduino IDE.
Is there a way to disable this? This is very disturbing behavior.

[floresta]

Why is this?
What causes the Arduino to restart when a program is connected to the COMPORT?

FWIW- The program in the Arduino also restarts- when I open the Serial Monitor in the Arduino IDE.
Is there a way to disable this? This is very disturbing behavior.

It has to do with the auto-reset circuitry used in conjunction with the bootloader. It's the price you pay in order to not have to press the reset button (a very arduous task) when you load a program into the Arduino. Use the search box at the upper left and search for "auto-reset".

Don

[system]

floresta:

Why is this?
What causes the Arduino to restart when a program is connected to the COMPORT?

FWIW- The program in the Arduino also restarts- when I open the Serial Monitor in the Arduino IDE.
Is there a way to disable this? This is very disturbing behavior.

It has to do with the auto-reset circuitry used in conjunction with the bootloader. It's the price you pay in order to not have to press the reset button (a very arduous task) when you load a program into the Arduino. Use the search box at the upper left and search for "auto-reset".

Don

I understand how the Arduino IDE can trigger that response.

It's a shame they didn't make that a menu option- to trigger the reset or not.

[floresta]

It's a shame they didn't make that a menu option- to trigger the reset or not.

I believe they did make it a hardware option. Did you look at any of the 'auto-reset' posts?

Don

[system]

floresta:

It's a shame they didn't make that a menu option- to trigger the reset or not.

I believe they did make it a hardware option. Did you look at any of the 'auto-reset' posts?

Don

Yes, I'm reading through all of them, looking for the best solution.
I guess I can mount a slide switch- Program/Run.

Thanks!

[bperrybap]

The real problem is that the auto-reset is driven by DTR and the DTR line is controlled by the OS rather than
application software.
The DTR line is dropped whenever the port is opened.
This allowed auto-reset to work without having to modify avrdude.
Most OS's do have a way to disable this behavior, but it then would disable uploading
since auto-reset would no longer work until things were changed back.

There are other versions of the "auto-rest" circuitry that use RTS rather than DTR.
When RTS is used, there is no auto-reset when the port is opened because RTS does not toggle
or drop when the port is opened.
Auto-reset still works with the older avrdude because the IDE toggles it before calling avrdude.

The benefit of using RTS is that auto-reset works with the IDE when uploading but will
not trigger auto-reset when simply opening the port.
The only drawback of using RTS over DTR is that if you use avrdude from the commandline
rather than using the IDE, then auto-reset will not work unless you have the latest avrdude that has a "arduino" protocol type
that knows how to toggle RTS for autoreset.

Different USB to TTL serial boards are wired differently at the 6 pin connector.
Some wire up DTR and some use RTS and some are configurable by using a jumper or a solder bridge.
The USB board you have uses DTR and does not appear to have an easy way to change it.
The standard FTDI cable uses RTS instead of DTR.

This board is configurable. It ships with RTS but can easily be changed to use DTR:

FTDI Friend + extras

You have a couple of options to disable auto-reset when the port opens.

• Change the OS use of the DTR line - varies depending on os and it may be difficult to walk users though this.
  (I would't go this route)

• switch to a different USB to serial adapter cable/board that uses RTS instead

• Cut the DTR/RTS trace on the USB to serial adapter board so that it can never auto-reset the target.
  (makes it a monitor only adapter that can no longer be used for uploading)

• build an adapter cable that you use between your current serial adapter and your target board.
  This adapter cable would not connect the DTR/RTS pin so that auto-reset was disabled. So when
  you used this cable no auto-reset would happen but auto-reset would happen when the cable was not used.

• Change your target board to be able to disable auto-reset.
  In the prototino, C4 makes the connection from the DTR/RTS pin to the reset pin of the AVR.
  If you remove C4 then auto-reset is disabled. On thing that I've done on proto boards for this is to use
  a 2 pin machine socket or female header. Then you can insert the cap to enable auto-reset
  or remove it to disable auto-reset as needed.

When looking at other USB to seral boards, you can pick up some really cheap cp2102 based ones on ebay:
http://www.ebay.com/itm/USB-2-0-UART-TTL-6PIN-Module-Serial-Converter-CP2102-/370532286388?pt=PCC_Drives_Storage_Internal&hash=item564571ffb4

These work, but the pinout is very different so you have to be careful when you hook up the wires.
You can wire it up to use DTR or RTS (don't confuse RST with RTS the are definitely not the same)
or you could make a custom cable that has a six pin connector on the other end using a cable like this:
6-conductor 0.1 socket-socket cable [6 long] : ID 206 : $1.75 : Adafruit Industries, Unique & fun DIY electronics and kits to make it easier.

Note/Warning: If you are planning to use the VIN and the voltage regulator
on your prototino in your final project, you will need to make sure the 5v signal
from the USB to serial adapter/cable does not pass through.
You can either cut the trace to that pin, or cut that pin off the header on the prototino,
or make a custom cable that does not pass through the 5V signal.
Otherwise the 5v regulator and 5v FTDI signal will not be happy being shorted together.

Hope the information helps.

---- bill

[retrolefty]

Very nice write-up. This could make a very useful 'sticky'.

Lefty

[system]

bperrybap:

• Change your target board to be able to disable auto-reset.
  In the prototino, C4 makes the connection from the DTR/RTS pin to the reset pin of the AVR.
  If you remove C4 then auto-reset is disabled. On thing that I've done on proto boards for this is to use
  a 2 pin machine socket or female header. Then you can insert the cap to enable auto-reset
  or remove it to disable auto-reset as needed.

Note/Warning: If you are planning to use the VIN and the voltage regulator
on your prototino in your final project, you will need to make sure the 5v signal
from the USB to serial adapter/cable does not pass through.
You can either cut the trace to that pin, or cut that pin off the header on the prototino,
or make a custom cable that does not pass through the 5V signal.
Otherwise the 5v regulator and 5v FTDI signal will not be happy being shorted together.

Hope the information helps.

---- bill

Hope the information helps.

To say the least.
Thanks for the info and many options to choose from.

If you are planning to use the VIN and the voltage regulator
on your prototino in your final project, you will need to make sure the 5v signal
from the USB to serial adapter/cable does not pass through.

I'm actually using this to program my 328s.

SparkFun FTDI Basic Breakout - 3.3V - DEV-09873 - SparkFun Electronics

I need to run my 328's @ 3.3v, due to the logic that they are interfacing with.
This breakout board will power the boards @ 3.3V, while downloading the sketches.

I am still trying to get the bootloader reprogrammed to run @ 8Mhz.
@ 3.3V, I the frequency needs to be lower than 16Mhz. I've bought 8Mhz
crystals and 3.3V regulators to replace the 16Mhz crystals and 5V regulators in the Prototino boards.

[system]

why dont you use the internal oscillator ? that will free up 2 pins

and depending on the bootloader you want to use its pretty easy to recompile/upload it to the chip - i recommend the optiboot bootloader (cause its faster and smaller) just download the files from here https://github.com/WestfW/Arduino/tree/master/hardware/arduino/bootloaders/optiboot edit in the make file the AVR_FREQ to 800000L for atmega328 (if you decide to use the internal oscillator youll need to edit the the fuses too :P) and recompile the optiboot and burn it

[system]

putyn:
why dont you use the internal oscillator ? that will free up 2 pins

I've thought about that. Another user recommended using an external 8Mhz crystal. He said that he has had better results with it.
Since this is my first real project (for my job), I am taking the advice of people who have been using the Arduino longer than I have.

I'm not out of I/O pins for this project, I only need 6.

As far as the bootloader goes, I've downloaded the optiboot files, and they show up under the Board menu.
After reprogramming my Duemilanove to act as an ISP programmer, I was unable to program the target 328 with any bootloader.

The error message I was getting was

"avrdude: stk500_getsync(): not in sync: resp=0x15"

I appreciate your advice, I don't want to hijack this thread into bootloader issues.
I'll post a new thread and we can continue there.

Thanks!!

[system]

putyn:
why dont you use the internal oscillator ? that will free up 2 pins

If an external crystal isn't used, can pins XTAL1 & XTAL2 actually be used as I/O pins?

[system]

in theory yes but digital pin 13 (last digital pin marked on the arduino board) corresponds to PB5 so PB6 and PB7 (pins used for the crystal) would be digital pin 14 and digital pin 15 but im not sure if they are implemented in software

i think changing this functions something like this (functions located in pins_arduino.cc around line 382 )

const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
	PD, /* 0 */
	PD,
	PD,
	PD,
	PD,
	PD,
	PD,
	PD,
	PB, /* 8 */
	PB,
	PB,
	PB,
	PB,
	PB,
        PB,
        PB,
	PC, /* 16 */
	PC,
	PC,
	PC,
	PC,
	PC,
};

const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] = {
	_BV(0), /* 0, port D */
	_BV(1),
	_BV(2),
	_BV(3),
	_BV(4),
	_BV(5),
	_BV(6),
	_BV(7),
	_BV(0), /* 8, port B */
	_BV(1),
	_BV(2),
	_BV(3),
	_BV(4),
	_BV(5),
        _BV(6),
        _BV(7),
	_BV(0), /* 16, port C */
	_BV(1),
	_BV(2),
	_BV(3),
	_BV(4),
	_BV(5),
};

would allow you to use those pins - but i may be wrong and some things could be broken

[floresta]

in theory yes but digital pin 13 (last digital pin marked on the arduino board) corresponds to PB5 so PB6 and PB7 (pins used for the crystal) would be digital pin 14 and digital pin 15 but im not sure if they are implemented in software

NO! The analog pins are accessed by the 'digital' pin numbers 14 - 19. You would be better off accessing the extra pins by using 'direct port access'.

Don