Prevent Serial monitor from resetting the arduino

[andy370]

Hi there,

I was looking at the solution here: Prevent Serial Monitor from Resetting the Arduino - Programming Questions - Arduino Forum for the problem i have, however, for some bizzare issue it does not work for me on my Nano.

I put a 4.7uF cap between the RST and GND, and it still being reset every time i start a serial terminal. Anyone has any suggestions how to make the nano not reset? The extra cap was looking as a useful solution though in the beginning, however, since that does not work, i'm looking for a better one for my nano.

I tried cap in all 3 places as in the attached picture with no success whatsoever...

Thank you!

--Andy

[dlloyd]

Try 10µF or 2 x 4.7µF. If that doesn't work, also add a strong pullup resistor of about 220Ω to 330Ω.

[Nick_Pyner]

Having the monitor reset is normal, and also a reasonable thing to do. I believe the serial monitor can be configured not to do this, and there will be suitable instruction on this forum. Further, if you use a proper terminal programme, like RealTerm etc., all freebies, you should not have this "problem". I think you will find that fartarsing around with res and caps is absurd, and something you will surely regret later....

[dlloyd]

I think you will find that fartarsing around with res and caps is absurd, and something you will surely regret later....

This is commonly done on programmers (Nano as a jtag2updi programmer) to disable the auto-reset circuit and allow the Nano to act as a programmer.

In my opinion, nothing to regret as this will actually help protect the ATMEGA328P from entering high voltage programming mode. The +10V spike that happens when DTR returns high is quite close to the 11.5-12.5V that triggers HV programming mode ... yikes! Perhaps what's absurd is there's no diode to clamp the voltage to 5.6V.

The Nano's reset circuit is just a 0.1µF cap in series from DTR to the Nano's RESET pin. Less chance of regret with the 10µF cap (RESET to GND) than without.

[andy370]

Nick_Pyner:
Having the monitor reset is normal, and also a reasonable thing to do. I believe the serial monitor can be configured not to do this, and there will be suitable instruction on this forum. Further, if you use a proper terminal programme, like RealTerm etc., all freebies, you should not have this "problem". I think you will find that fartarsing around with res and caps is absurd, and something you will surely regret later....

Hi Nick,

thank you for your help!

I agree, and i originally wrote, that this behaviour is likely by design. If i were to use the stuff myself, then it might work, however, let me give you a little bit of the use case scenario, and, perhaps you can help me and provide with alternative that will work in my particular case.

purpose - Nano collects the input through serial interface and is controlling motor based on that input. Nano is connected via USB interface to Raspberry PI 3A+. RPI runs apache as an interface to send the info to Nano and check on the status. at the same time there is a mobile App that coneects via TCP to the RPI to get the status as well.

current inplementation:
RPI connects USB to IP via socat:

socat TCP-LISTEN:4444,fork,reuseaddr FILE:/dev/ttyUSB0,b19200,rawer

This works perfectly, however, every time someone connects to port 4444, it resets Nano, and all the info is lost with reset.

what else i tried:
i tried using phpserial, however that part does not have an option to disable DTR.

what else i think about:
perhaps i can write my own implementation of socat and make it not reset the USB, however, it also might be the case, where USB is reset by the driver on RPI.

[UKHeliBob]

It is not using the Serial connection that causes the reset, rather it is opening the Serial connection

Can you open it and leave it open ?

[andy370]

dlloyd:
Try 10µF or 2 x 4.7µF. If that doesn't work, also add a strong pullup resistor of about 220Ω to 330Ω.

Hi dlloyd,
Thank you very much, i will try that and post my results. i saw a few posts on the cap usage, and the caps discussed there are between 1uF and 10uF.

Thank you

--Andy

[pert]

Nick_Pyner:
I believe the serial monitor can be configured not to do this, and there will be suitable instruction on this forum.

You're right that it can be configured. However, this feature was only recently formally documented, so you might not find mention of it on the forum.

I'll provide the link here for anyone who is interested:

https://arduino.github.io/arduino-cli/latest/platform-specification/#serial-monitor-control-signal-configuration

This requires modifying the board definition that is in the boards platform's boards.txt file.

The naive approach would be to edit that boards.txt file directly. That will work fine, but the problem is that you would need to redo the modification after every time you updated to a new version of the boards platform. There are a couple of better alternative approaches, which I will describe below. You can pick whichever one of the two is most convenient for you:

"Extension" platform

The Arduino boards platform system has a nice feature where you can reference resources from other installed platforms:

https://arduino.github.io/arduino-cli/latest/platform-specification/#referencing-another-core-variant-or-tool

This allows you to create your own platforms that can be as minimal as a few lines in a single text file.

In this case, your custom platform can consist of a single board definition in a boards.txt file, which references all other resources from the official "Arduino AVR Boards" platform of the Nano:

nano_no_sm_reset.name=Arduino Nano (disable Serial Monitor reset)

nano_no_sm_reset.upload_port.0.board=nano

nano_no_sm_reset.upload.tool=arduino:avrdude
nano_no_sm_reset.upload.tool.default=arduino:avrdude
nano_no_sm_reset.upload.tool.network=arduino:arduino_ota
nano_no_sm_reset.upload.protocol=arduino

nano_no_sm_reset.bootloader.tool=arduino:avrdude
nano_no_sm_reset.bootloader.tool.default=arduino:avrdude
nano_no_sm_reset.bootloader.unlock_bits=0x3F
nano_no_sm_reset.bootloader.lock_bits=0x0F

nano_no_sm_reset.build.f_cpu=16000000L
nano_no_sm_reset.build.board=AVR_NANO
nano_no_sm_reset.build.core=arduino:arduino
nano_no_sm_reset.build.variant=arduino:eightanaloginputs

## Arduino Nano w/ ATmega328P
## --------------------------
nano_no_sm_reset.menu.cpu.atmega328=ATmega328P

nano_no_sm_reset.menu.cpu.atmega328.upload.maximum_size=30720
nano_no_sm_reset.menu.cpu.atmega328.upload.maximum_data_size=2048
nano_no_sm_reset.menu.cpu.atmega328.upload.speed=115200

nano_no_sm_reset.menu.cpu.atmega328.bootloader.low_fuses=0xFF
nano_no_sm_reset.menu.cpu.atmega328.bootloader.high_fuses=0xDA
nano_no_sm_reset.menu.cpu.atmega328.bootloader.extended_fuses=0xFD
nano_no_sm_reset.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

nano_no_sm_reset.menu.cpu.atmega328.build.mcu=atmega328p

## Arduino Nano w/ ATmega328P (old bootloader)
## --------------------------
nano_no_sm_reset.menu.cpu.atmega328old=ATmega328P (Old Bootloader)

nano_no_sm_reset.menu.cpu.atmega328old.upload.maximum_size=30720
nano_no_sm_reset.menu.cpu.atmega328old.upload.maximum_data_size=2048
nano_no_sm_reset.menu.cpu.atmega328old.upload.speed=57600

nano_no_sm_reset.menu.cpu.atmega328old.bootloader.low_fuses=0xFF
nano_no_sm_reset.menu.cpu.atmega328old.bootloader.high_fuses=0xDA
nano_no_sm_reset.menu.cpu.atmega328old.bootloader.extended_fuses=0xFD
nano_no_sm_reset.menu.cpu.atmega328old.bootloader.file=atmega/ATmegaBOOT_168_atmega328.hex

nano_no_sm_reset.menu.cpu.atmega328old.build.mcu=atmega328p

# Don't reset when Serial Monitor is opened
nano_no_sm_reset.serial.disableDTR=true
nano_no_sm_reset.serial.disableRTS=true

## Arduino Nano w/ ATmega168
## -------------------------
nano_no_sm_reset.menu.cpu.atmega168=ATmega168

nano_no_sm_reset.menu.cpu.atmega168.upload.maximum_size=14336
nano_no_sm_reset.menu.cpu.atmega168.upload.maximum_data_size=1024
nano_no_sm_reset.menu.cpu.atmega168.upload.speed=19200

nano_no_sm_reset.menu.cpu.atmega168.bootloader.low_fuses=0xff
nano_no_sm_reset.menu.cpu.atmega168.bootloader.high_fuses=0xdd
nano_no_sm_reset.menu.cpu.atmega168.bootloader.extended_fuses=0xF8
nano_no_sm_reset.menu.cpu.atmega168.bootloader.file=atmega/ATmegaBOOT_168_diecimila.hex

nano_no_sm_reset.menu.cpu.atmega168.build.mcu=atmega168

boards.local.txt

You can make modifications to an existing boards platform without having to edit the files of the platform by putting your modifications in a file named boards.local.txt and then placing that file in the root of the platform:

https://arduino.github.io/arduino-cli/latest/platform-specification/#boardslocaltxt

# Don't reset when Serial Monitor is opened
nano.serial.disableDTR=true
nano.serial.disableRTS=true

You will still need to replace your boards.local.txt file after every update you make to the platform. If you save a copy of your boards.local.txt file in a safe place, this will be as simple as just copying the existing file to the platform folder.

[andy370]

UKHeliBob:
It is not using the Serial connection that causes the reset, rather it is opening the Serial connection

Can you open it and leave it open ?

Hi UKHeliBob,

Yes, i agree with you on the issue where "opening" actually resets it. This is the reason i was saying, that i could probably write my own implementation of socat having it being kept always open. I just think, that the effort in writing my own socat may not worth the result. at the worst case either cutting off the reset lead on atmega or ading cap will do just fine - at the end of the day, i will not need to upload another sketch (even though that would be a cool option

--Andy

[Blackfin]

If you don't need that reset function (i.e. development is done and the thing is deployed) just remove C4 and solder one side of it only to one of the pads to keep track of it.

[andy370]

dlloyd:
Try 10µF or 2 x 4.7µF. If that doesn't work, also add a strong pullup resistor of about 220Ω to 330Ω.

Hi dlloyd,

the 2 x 4.7 uF caps did not really work.... will try 330 Ohms pullup res as well.

[andy370]

UKHeliBob:
It is not using the Serial connection that causes the reset, rather it is opening the Serial connection

Can you open it and leave it open ?

Hi UKHeliBob,
I reached out to socat author, and he suggested the following:

try to swap the two addresses:

    socat FILE:/dev/ttyUSB0,b19200,rawer TCP-LISTEN:4444,fork,reuseaddr

This way the first address is opened only once, before the fork.

The interesting issue, that in this case, the socat does not reset nano, it works fine 1'st time connecting to port 4444, and second time i get a bunch of weird chars - just like if you mismatch the baudrate for serial interface, however, the third time is does not work at all. So, somewhere i miss something.
I will keep posting here as to my progress - i'm sure, there are a number of people, who would be trying to use arduino in the similar manner.

[dlloyd]

the 2 x 4.7 uF caps did not really work.... will try 330 Ohms pullup res as well.

Hmm ... just 4.7uF works here ... 9.4uF should definitely work for you.

Is this an official Nano board? If not, perhaps the reset-DTR or reset-RTS is hardwired and has a jumper or cutout on the PCB ... in this case a schematic or pictures would be helpful.

@pert ... awesome information / links.

[andy370]

dlloyd:
Try 10µF or 2 x 4.7µF. If that doesn't work, also add a strong pullup resistor of about 220Ω to 330Ω.

weird, at this point, i have 9.7 uF reset to GND and a 330 Ohms reset to VCC (5V).

as soon, as i added the resistor, the Raspberry PI quit recognizing Nano. the Reboot fixed it.

So, the caps does not work, the Res+Caps disables the USB on RPI alltogether (even the mouse dongle is not recognized - probably it feels shorted?) - even if res is removed the RPI will not recognize anything on the USB until after reboot.

well, it seems, i've discovered a way to disable usb on RPI with Nano

btw, windows will say this about the nano having 330 Ohm from reset to VCC:
Unknown USB device (Device descriptor request failed)

[dlloyd]

Raspberry PI?

Do you have a 3.3V Raspberry PI connected to a 5V Arduino Nano?

If so, I would start by immediately disconnecting the RPi from the Nano, then check that the Nano still works correctly on its own.

Look here for a connection scheme using a level converter.

[Nick_Pyner]

perhaps you can help me and provide with alternative that will work in my particular case.

I'm afraid not, as I haven't the faintest idea of what you are doing., I have never heard of a socat, and know nothing about raspberry pi. I understood that you wanted to avoid arduino resetting when you start the serial monitor and thereby, I assume, stuffing up a data stream. If that is indeed the case, all I can tell you is:

1. You are not the first. There has been discussion before, not so recently either, and I'm sure it didn't involve hardware hacking with res and caps, but I didn't pay much attention to it as I never used the serial monitor to collect data.

2. I have tried using RealTerm again, via USB cable. It resets Arduino too and I guess there should be no surprise there. There is no evident way of fixing this, so I think I was wrong about that all along. This may be because I used RealTerm connected via Bluetooth, thereby simply tapping into a continuous data stream.

3. I used PLX for a while and don't recall any resetting issues. The PLX thread is probably the biggest on this forum and, if this is your line, I'm sure you can check on this there.

[andy370]

dlloyd:
Raspberry PI?

Do you have a 3.3V Raspberry PI connected to a 5V Arduino Nano?

If so, I would start by immediately disconnecting the RPi from the Nano, then check that the Nano still works correctly on its own.

Look here for a connection scheme using a level converter.

Hi dlloyd,

yes, RPI to Nano 5V. The nano actually connected to RPI through USB and not GPIO, So, no level converter needed...

I actually made it work as i wanted without any HW modifications (no cap or res). i will post it here in a separate post

--Andy

[andy370]

Hi everyone,

As mentioned in my previous post i made it work the way i wanted

So, the scenario is the following:

Nano is connected through USB to RPi. The nano is reported to RPi as /dev/ttyUSB0. The requirement was to have nano be available over IP rather than direct serial, and have nano NOT reset when new client connects to read the data.

So, the solution is as follows:

supplies:

• Nano (not modified in any way, original or clone will work as well, as other usb-connected Arduino devices),
• sketch uploaded to Nano,
• Raspberry Pi 3A+ (other versions are likely to work the same way),
  -- Raspbian - official SUPPORTED version (others may work as well).

the following is needed to be done on Raspbian:

• with lsusb make sure the device is recognized
• with dmesg you will discover which device it is connected to (in my case was /dev/ttyUSB0).
  -- Be careful! the device name may change from boot to boot especially if you have other USB devices connected
• with the stty you have to make sure the port has the following attributes:

pi@raspberrypi:~# sudo stty -F /dev/ttyUSB0
speed 115200 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke
pi@raspberrypi:~#

pay a good attention to baud rate, and read stty manual to set the parameters as the above.

• use socat to channel the USB to IP port

socat FILE:/dev/ttyUSB0,b115200,raw TCP-LISTEN:4444,fork,reuseaddr

you must make sure the baud rate in the socat is the SAME as in stty

• at that point, you are done. you can now telnet to port 4444 on your system and get to interact with your Nano.

one thing that makes the above great, is NO modification needed to any hardware, therefore if you have this remotely somewhere, you can always SSH in to yout RPi system and upload new sketch to your Nano! all you have to do is to kill the socat process.

something you need to be aware of as well, is if you want to make this run unattended, you need to create a service for the stty and socat. getting this done is out of the scope of this article.

Credits has to be also given to socat author for his help!

--Andy