How to prevent Nano Every from resetting upon connection to the serial port?

Hello everyone,

Whenever I start the Serial Monitor to talk to my Nano Every, it resets. The tricks used to prevent this behavior on the classic Nano don't seem to work here, which are:

  • 10, 100, and even 1000 uF cap between RST and GND
  • 120 Ohm resistor between +5V and RST

I looked up at the schematics but it seems like the RESETN line is only connected to passive devices, so I don't see how it could be resetting the micro, to begin with.

Can you help me understand and prevent this behavior?

Thanks in advance!

I don't have time to try it right now, but setting the build properties to disable the serial control signals might do it:
https://arduino.github.io/arduino-cli/latest/platform-specification/#serial-monitor-control-signal-configuration

nona4809.serial.disableDTR=true
nona4809.serial.disableRTS=true

boards.local.txt would be the ideal place to make this customization:
https://arduino.github.io/arduino-cli/latest/platform-specification/#boardslocaltxt

Another option might be to customize the "MuxTO" firmware that runs on the ATSAMD11 USB chip on the board:

Hello, pert!

Thanks for the very quick replies!
Both of your proposed solutions are quite advanced to me. I have absolutely zero knowledge of the CLI and re-programming the ATSAMD11 chip, but I will look carefully into those.

Best wishes,
Igor

igorfier:
I have absolutely zero knowledge of the CLI

The documentation I linked to is hosted in the Arduino CLI repository because it's Arduino CLI that implements these features. However, the Arduino IDE uses Arduino CLI, so all that information also applies to Arduino IDE.

Arduino CLI is a very useful tool for some purposes, but it's not required that you use it to try this out.

The summary of what it necessary to try it is to just create a file named boards.local.txt, add the text I shared in my previous reply, save that file to the same folder as the boards.txt for the Nano Every, then restart the Arduino IDE so it will recognize the file you added.

If it causes problems, you only need to delete that boards.local.txt file and you're back to where you were originally.

So the only really tricky part is finding the location of that boards.txt file.

You can do that by following these instructions:

  • Select a board from the hardware package you want to find from the Tools > Board menu
  • File > Examples > SPI > BarometricPressureSensor (or any other SPI example sketch)
  • Sketch > Show Sketch Folder
  • Move up folder levels until you reach the one that contains boards.txt

igorfier:
and re-programming the ATSAMD11 chip

That is definitely a more complex thing, and unfortunately there is not a lot of documentation on how to do it. I just thought I'd mention it as a possibility, but I don't necessarily recommend it. You can find information about it here:

I did just this. I found the boards.txt file in the following folder:
C:\Users\wa2pu\AppData\Local\Arduino15\packages\arduino\hardware\megaavr\1.8.6
I created a “boards.local.txt” file which contained the following:
nona4809.serial.disableDTR=true
nona4809.serial.disableRTS=true
I saved the file in the aforementioned folder.
I shut down and restarted the Arduinio IDE.
I recompiled the code and then uploaded it to my Arduino Nano every
I put the device in a particular mode where a reset would be obvious.
I opened my PComm Terminal Emulator and connected to the Arduino Nano every on the COM port.
It reset.
So…what did I do wrong, here?

OK, let me modify this a bit....
OK, the Arduino serial monitor does not cause the Arduino nano every to reset anymore.
BUT, if I connect to the Arduino Nano every using a terminal emulator, it does.
There is no flow control specified for the port.
I am going to be writing a C# program using Visual Studio to access this board.
The question is, how do I keep the reset from happening?

The ATmega4809 uses the "new" UPDI one-wire interface for programming rather than a bootloader or the ICSP, which is the SPI interface plus reset pin, in the other AVR microcontrollers. The SAM microcontroller, which provides the USB to serial interface, also drives the UPDI interface. The SAM is forcing the reset over the UPDI. You can either reprogram the SAM or somehow break the UPDI connection. If you do the latter the board would not be reprogrammable.