I didn't have much need to pay attention to a recent post that I thought said if an externally powered and running Arduino is connected to the USB it resets. Is this true?
I haven't cared if the Arduino resets when connected to USB, until shortly. I have a project about to finish that will be logging data and will need to connect to USB to transfer the data and do not want the Arduino to reset when the USB is connected. I am looking for confirmation that it does or does not reset when the USB is connected to a running Arduino.
The Arduino is reset by opening the serial port (auto reset) and/or on power up. You can prevent the auto reset from the serial port, temporarily, by connecting a 10uf cap between the reset pin and ground. If using an electrolytic cap, make sure to observe polarity. Some Arduinos have a jumper that you can cut to permanently disable the auto reset.
An Arduino resets via the DTR line of the usb connection, the Arduino IDE has no option to disable it when opening the Serial but you could just use another Serial tool or make your own Serial tool.
Else you can use a "FTDI" - TTL Serial convertor, and just wire the FTDI to the serial 0 lines, then if you want to be able to reset the Arduino your need to connect the DTR to the reset pin along with a reset circuit, which consists of a 101 ceramic cap and a resistor.
I have made a few Serial programming tools with Visual studio, its actually quite easy.
To be specific, I am using Arduino UNO and MEGA 2560 boards that each have UDB B [programming] ports.
The consensus says the Arduino does reset. But is it due to opening the serial monitor or the physical fact of connecting the USB cable?
Going off of the previous post, if I connect a second data-only FTDI board and connect only VCC, GND, Tx and RX and do not connect DTR and CTS; will I be able to communicate with the Arduino? Will the Arduino reset when the USB is connected and/or the serial monitor opened?
adwsystems:
if I connect a second data-only FTDI board and connect only VCC, GND, Tx and RX and do not connect DTR and CTS; will I be able to communicate with the Arduino?
Yes
adwsystems:
Will the Arduino reset when the USB is connected and/or the serial monitor opened?
It resets due to the serial connection being opened by Serial Monitor. But that's not unique to Serial Monitor, another serial terminal program would do the same. I have heard that some programs allow you to configure how DTR is controlled. If so, it would be possible to open a serial connection to an Arduino board with that program without resetting it.
Note that the boards with native USB (Leonardo, Pro Micro, etc.) are not reset when a serial connection is opened. That behavior only occurs with the boards that have a separate USB to TTL serial chip such as your Uno and Mega.
pert:
It resets due to the serial connection being opened by Serial Monitor. But that's not unique to Serial Monitor, another serial terminal program would do the same. I have heard that some programs allow you to configure how DTR is controlled. If so, it would be possible to open a serial connection to an Arduino board with that program without resetting it.
The real solution would be to stop using DTR to auto-reset the Arduino as it is controlled by the OS driver at port open() and use RTS instead.
The OS driver drops DTR before open() returns to the application which before the application can do anything to alter the behavior.
The OS does not mess with RTS so the application can use it as it sees fit.
From past history:
The original Arduino boards did not support auto reset for uploading. You had to bash the reset button then do the upload.
The original FTDI cable used RTS and not DTR. DTR was not even available.
While using RTS is to auto reset the board is the ideal solution, it required s/w changes in either the IDE or avrdude.
The solution that the Arduino team came up with was a hardware solution for a s/w problem.
DTR is lowered by the OS driver when the serial port is opened.
Autoreset needs to briefly toggle the AVR reset signal low rather than low signal to work.
However, DTR could be used with some additional h/w to create an auto reset capability without having to modify
any s/w. This is the reason for the capacitor on the auto reset circuit.
It changes the DTR signal from being a constant low while the port open to a pulse that can be used for auto reset.
Roll forward a bit and people still wanted to use the FTDI cable, which only has RTS not DTR. The DTR signal is simply not available on that cable.
To resolve that, the IDE was modified to toggle RTS just before doing the upload.
That created the ideal solution as autoreset didn't happen when the serial port was opened by the serial monitor but did happen when upload was done.
Roll forward a bit more, and a new protocol was added to avrdude to support Arduino.
It was the same as the stk500 other than
it included some messing with RTS (and DTR when possible) to provide auto reset regardless of whether DTR or RTS were used.
So as of right now, the Arduino software supports using DTR or RTS for autoreset when uploading.
RTS is the ideal solution as it can offer the ability to open the serial port without resetting the arduino.
I suggested quite some time ago about changing the AVR chip (16u8/16u2) that does the USB to serial conversion to use RTS than DTR.
It requires a s/w change to the firmware inside that avr chip and is 2 lines of code since it is looking at a different bit in the messages. This would allow the possibility to open the virtual serial port without resetting the Arduino board.
It could also allow the creation of a [reset] button in the serial monitor GUI that could be used to manually reset the Arduino.
At this point in time I see no reason to continue to use DTR over RTS as DTR has limitations that RTS does not have with respect to using the signal for controlling auto reset on the Arduino.
The Arduino Serial monitor is pulling the DTR LOW then HIGH as it opens the serial connection, it would be so easy for them to add a checkbox to disable it.
I have made an advanced Serial tool that you can disable the auto reset which you can use, but your be the first to use it apart from me so if you get any problems please reply in this post.
And please do not redistribute, or modify my program or sell it without consulting me first, All right are reserved by me.
When sending a file a 250 ms delay is added between each line to give the MCU time to process the data such as saving it to the EEPROM, and a \n\r is added to the end of the very last line of the file, and when just sending some text from the input box a \r is added to the end.
I could add a box to change the delay time...
Just ask if you have any more questions.
Oh its windows only too.
One minor bug so far is that some MCU models or variants hang on the reset, but i think that was my knock off Mega being funny as i am unable to recreate the issue on another mega.
KawasakiZx10r:
The Arduino Serial monitor is pulling the DTR LOW then HIGH as it opens the serial connection ...
Not normally. The ability to control DTR from an application is not available in all OS's.
Windows often plays games and does things and allows things that are very non standard.
Over the past 3+ decades in various Windows releases I've witnessed it really screw up how it handles the serial control signals
and even radically change the behavior between releases or even updates within the same Windows version.
DTR is normally controlled by the OS driver and the driver drops it low the entire time the serial connection is open.
That is the normal behavior of a DTR signal that should be expected.
This is why the Arduino boards have a capacitor on the board that connects to the DTR signal. It changes the DTR signal
from a single falling signal that goes from high before the serial port is open to low once the port is opened, to a momentary low when the DTR signal drops.
i.e. the auto reset circuit on the Arduino changes a falling edge DTR signal to a pulse that is only momentarily low which can be used to pulse reset on the AVR to cause it to be reset.
The main problem is that the OS driver drops the DTR signal to low when the serial port is opened by the application which is before the application can do anything to control the serial port or its control signals.
Assuming the OS and driver even allows the application to control DTR, applications should not be designed to expect the ability to control the DTR signal behavior particularly before the serial port is opened.
The best solution is to leave DTR behind and switch to using RTS for autoreset which could ensure that the Arduino is never reset unless the application explicitly toggles the RTS signal as the application can have full control over the RTS signal and it is not messed with during the open() call to open the serial port.
I found this thread when searching for info on a Nano just resetting without reason.
I wonder now, if with Windows 10 and the Nano connected via USB if Windows or Arduino IDE perhaps sends signals at totally random times that cause the reset.
With this project, I'd be doing something else, to find the Nano resetting at totally random times.
Of course, I suspected that I had something stupid in my code that was causing this OR
if the Nano was defective OR THIS MORE SO,
if the little ST7735s display was causing this since it seemed to just reset itself as well.
SEEMED.... is the word here.
After doing a lot of investigation and even adding code to let me know if things had reset, I came to realize that this was ONLY happening while plugged into USB.
When not plugged in, no problem.
On this project, I have 4 buttons.
The screen itself would blank out (basically reset itself) when I sometimes pressed a button.
Interestingly, this only happened when plugged into USB.
If on the 5V power supply, no problem.
I even monitored voltage and current draw to see if there was something dragging things down.
But nope. Max current draw, with screen at full brightness was only 50mA.
Well, at least with this thread, I now know that it is in fact the USB connection that's causing this issue.
I can work around that.
Does your windows machine hibernate? Mine's either doing that or going into a low power mode, with the consequence that anything using USB power loses it.