starting IDE monitor reboots Arduino

Hi,

I have a simple program loop based on the fade example to which I've added an analogRead()

after each read it outputs the value via Serial.println(). I'm watching the output with the IDE monitor.

However, if I close , then restart the monitor the restart causes the arduino to reboot, losing all the data in RAM.

I get similar behaviour when interfacing with screen instead of the monitor.

Where should I look to fix this?

thx

it is perfectly normal that the arduino resets when you open the serial monitor, if that's what you mean. it also happens when you change the configurations from the dropsownlists in the monitor

This is a side affect of the Arduino IDE's ability to reset the reader to perform sketch uploads.

If you need to keep the data then perhaps consider storing it in the EEPROM?

Where should I look to fix this?

You can defeat the auto DTR reset by using a ~100 ohm resistor between the reset pin and +5v pin, or a large capacitor between the reset pin and ground.

You can defeat the auto DTR reset by using a ~100 ohm resistor between the reset pin and +5v pin, or a large capacitor between the reset pin and ground.

Ah thanks, how does that affect ability to program using the boot loader? A quick test indicates that the IDE reports Arduino "out of sync". Does this need to be switchable?

Nicely fixed the reset losing my data on connect. :D

Presumably this reset is created by the U16 firmware and I'd guess it's a one byte patch to remove the reset. Has anyone hacked this already or is the source code available for the firmware?

Thanks all.

Rather than remove the auto reset capability which makes doing uploads painful, the better thing to do is to simply not use DTR for auto-reset. DTR gets dropped when the port opens. This is done by the OS before the IDE could do anything about it. RTS is not messed with when the port is opened. The IDE (and now avrdude) toggles both when an upload is done. So if you use RTS instead of DTR , IMO, you get the best of both worlds. reset on upload but no reset when the serial interface is opened.

I use 3rd party "arduino" boards with no on-board USB to serial conversion. But I use RTS for auto-reset on my USB to serial cables which don't have the auto reset issue when the serial port is opened like DTR does. (so there is no auto reset from the IDE serial monitor starting up or any other serial monitor tool) I have no idea why DTR is still used now that avrdude has support for toggling RTS.

I've looked at the U16 code and it should be a as simple as changing 1 line. (I can't test it because I don't own any boards that use it)

Change CDC_CONTROL_LINE_OUT_DTR to CDC_CONTROL_LINE_OUT_RTS in function EVENT_CDC_Device_ControLineStateChanged() of file arduino-usbserial.c

this:

    bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_DTR);

becomes this:

    bool CurrentDTRState = (CDCInterfaceInfo->State.ControlLineStates.HostToDevice & CDC_CONTROL_LINE_OUT_RTS);

Depending on the OS there are also s/w solutions to disable DTR behavior at serial port open time. unix/linux can set it with the stty -hup option and there used to be setting in the com port advanced properties on XP to control DTR and RTS settings. (Not sure about the newer windows OS's)

The other fix is to buy more advanced 3rd party Arduino boards with a h/w jumper on it so you can disable it when you don't want it. This board has a switch: http://www.seeedstudio.com/depot/seeeduino-v221-atmega-328p-p-669.html

--- bill

I’ve looked at the U16 code and it should be a as simple as changing 1 line.
(I can’t test it because I don’t own any boards that use it)

Change CDC_CONTROL_LINE_OUT_DTR to CDC_CONTROL_LINE_OUT_RTS
in function EVENT_CDC_Device_ControLineStateChanged() of file arduino-usbserial.c

Thanks, that looks the best of both as you say.

If I follow you , I’d need to make one change to the U16 code and update the firmware then change arduino-usbserial.c to match.

Is that correct?

PS man stty:
[-]hup send a hangup signal when the last process closes the tty

seems to be about closing not opening :?

ardnut:

I've looked at the U16 code and it should be a as simple as changing 1 line. (I can't test it because I don't own any boards that use it)

Change CDC_CONTROL_LINE_OUT_DTR to CDC_CONTROL_LINE_OUT_RTS in function EVENT_CDC_Device_ControLineStateChanged() of file arduino-usbserial.c

Thanks, that looks the best of both as you say.

If I follow you , I'd need to make one change to the U16 code and update the firmware then change arduino-usbserial.c to match.

arduino-usbserial.c is the U16 code. Just change that line and rebuild the U16 code. That should be it. That change should cause the U16 to ignore the DTR signal in the USB CDC serial messages and look at RTS instead. The file and the makefile to build it is down in {installdir}/hardware/arduino/firmwares/arduino-usbserial

You will also need the LUFA library code. From a quick look it looks like LUFA has change significantly since this U16 code was written. (some header files have changed locations and names) so you will need an older version of LUFA as it looks like it won't be able to build with the latest LUFA.

PS man stty: [-]hup send a hangup signal when the last process closes the tty

seems to be about closing not opening :?

The way it really works is that you get a DTR signal level change when the port is first opened (by any process - as there could be multiple opens) and then again when the port is last closed.

hup processing controls whether these signal level changes happen or not.

But remember that the TTL signal level is inverted from the serial signal level. The serial signal level is dropped when the last close happens. Since it is inverted, the TTL signal is normally high (serial signal is low) and the TTL signal drops to low when the open happens. (because "hup" dropped the serial level to low on the last close - which causes the TTL level to go back high)

If you disable the hup signal, the net effect is that when using the TTL levels, the TTL signal level will remain high all the time. (or at least it should)

Given it can be a bit confusing, there are some OS's and even some linux drivers that get this wrong. But usually it works correctly on unix/linux machines. Windows, well????

Are you using linux?

--- bill

thanks for the detail. this is a bit of a head spin.

yes Linux.

So if I follow, I can just remove the -hup option from my stty ( I issue an explicit stty before using screen ) to prevent screen causing a reset on connection.

If I do the same before the IDE that should catch the monitor as well.

That seems simplest. Fixing the firmware would be the most permanent and portable, hence preferable. Do you have any specifics about version numbers for LUFA?

thx

PS can you comment on using U16 to provide simple USB host capability? It seems to be part of LUFA. Apart from arranging power on 5V, is there any hardware show stoppers?
http://arduino.cc/forum/index.php/topic,117456.0.html
http://arduino.cc/forum/index.php/topic,117456.0.html

Its been a long time (several years) since I’ve played with the hup options.
I think there were some issues with it remaining persistent. like if you removed the cable
it lost the setting. You may have to experiment a bit with it.

On LUFA, I’m not sure. I downloaded the most recent version ( before I posted ) and noticed
that the CDC_CONTROL_LINE_IN defines are in LUFA/Drivers/USB/Class/Common/CDCClassCommon.h
in the latest version (LUFA-120730)
vs in LUFA/Drivers/USB/Class/Common/CDC.h in LUFA-111009

The Arduino U16 code (Arduino-usbserial.h) uses
#include <LUFA/Drivers/USB/Class/CDC.h>

So it looks like it will not work with the latest LUFA but might work with the LUFA-111009 version which
is is the previous version.

— bill

Ok so I tried to build it. The needed LUFA release is in the README.txt file in the firmwares directory:

Both should be compiled against LUFA 100807

It is available on the LUFA site.

I'd recommend changing the name of the directory when you extract it to not have any spaces.

It does build ok.

--- bill

many thanks for taking a look. I'd got as far as downloading the source but have not had time to try building it.

removing -hup did not seem to make any difference, it still reset.

Fixing it in the firmware means it's fixed at the source and won't be a problem when other PCs connect.

Much better.

thx

Oh one more thing.
Since you are using linux, another thing to be careful/aware of is starting with Arduino 1.0.1
The Arduino IDE now includes a full avr-gcc toolset that it will use rather than an avr-gcc toolset that
you may have installed on your machine.
If you have installed your own, be aware that the one supplied by the Arduino
team is a bit old.

You can hide the IDE shipped compiler tools from the IDE by simply renaming its directory:
{installdir}/hardware/tools/avr

to something else.

— bill

thanks , I was aware of that. I was thinking that running the one they distributed would give a more controlled environment. I figured that if I reported any problems I may get shouted down if I had not used the supplied tool-chain.

However, having just discovered the fairly gross problems with their heap allocations, I may have been crediting them with a bit more professionalism than was merited.

I have two alternatives from Gentoo cross-dev package:

[1] avr-4.4.5 * [2] avr-4.5.3

Would you suggest I use one of those in preference to one that comes with 1.0.1 ?

thx