setup runs twice on nano during sketch installation? (and again during compile!

I had learned to put up with and ignore the double-spew of initial data written to the serial monitor when installing new sketches. In case anyone hasn't seen it, the first several lines written to serial monitor always seem to get repeated.

But today, while trying to figure something else out, I added a line to light an led just to see if it was reached.

And the LED blinked twice.

After some tinkering, I stripped everything out of the program, and even switch boards.

And then added another LED and a delay.

The circuit is trivial; there are LEDs attached to pins 6 and 7 thorough 330ohm resistors to ground. (there are still a pair of buttons on the breadboard, but they're not connected).

I distilled code to

void setup() {

  //get the monitor going
  Serial.begin(9600);
  Serial.println("starting setup");

  //set input LED  modes
  pinMode(6, HIGH);
  digitalWrite(6, HIGH);
  delay(250);
  digitalWrite(6, LOW);

  pinMode(7, HIGH);
  digitalWrite(7, HIGH);
  delay(250);
  digitalWrite(7, LOW);

  Serial.println("***leaving setup***!");

} //end of setupairp.a

void loop() {}

The video starts as I hit compile. We see

  1. the green LED lights (after compile, at the beginning of the orange output in the IDE),
  2. the flickering of the board status LEDs a the sketch is installed,
  3. the two LEDs lit in sequence
  4. about a second later, they light again.

The sketch still in at the beginning had the red LED code commented out. Comment it out again, install again, and both will come on at compile, and then the green will blink twice. Etc.

What is going on?

It kind of makes sense that a reset is sent by USB to start programming, and at the end of programming to send it on its way, but that only accounts for two (and even so, letting it run a couple of seconds is odd!)

Also note that the initial "starting setup" prints twice (about a second apart). setup() is apparently stopped before reaching "leaving setup" (or, before it leaves the buffer).

This is consistent with past observations that only the initial output is double printed.

Until today, I'd assumed that this was simply a quirk of the IDE, rather than that the mcu was executing twice.

video: http://dochawk.org/ard/IMG_1638.m4v (I can't make it display here other than a high-flicker gif!)

I don't see a link to the video you mentioned.

I can't reproduce this, but something like it has been reported to the developers:

Are you getting a reset if you only do a compile, or are you getting it during the compilation that happens after starting an upload?

Which board are you using?

Which OS are you using?

Which IDE version are you using?

Do you have Serial Monitor open? Does the same thing happen whether Serial Monitor is open or closed?

I see the video now.

I also see from your title that you're using a Nano. Which USB to TTL serial adapter is that on your Nano? It looks like the CH340, but maybe it's an FT232RL.

I'm using OSX/High Sierra on a mid 2011 iMac.
IDE 1.8.8.

I have both blue and black chinese nano boards; it does it on both (I've used two blue and one black so far, same results). I've always assumed CH340.

It's a garden variety USB cable connecting the nano to the mac.

And now I tries with the serial monitor closed, and neither of the spurious calls occur.

And then just by opening the serial monitor, it happens (and again when I close).

Intriguing.

I'd try with a mini, but they're all waiting to have headers solder (I managed to accidentally order about a dozen . . . ::slight_smile: )

You missed this question:

pert:
Are you getting a reset if you only do a compile, or are you getting it during the compilation that happens after starting an upload?

dochawk:
I've always assumed CH340.

It will say it right on the top of the chip. It's the large rectangular chip next to the USB jack.

dochawk:
And then just by opening the serial monitor, it happens (and again when I close).

That is the expected an normal behavior.

I just did a test using Arduino IDE 1.8.8, with a Nano derivative that uses CH340, on Windows 10, and I can't reproduce the issue of reset during compilation, whether I am just doing a compilation, or an upload.

Thanks for linking from the GitHub issue to the forum, I was just going to do that, but you took care of it for me! Since we're having difficulty reproducing the issue, having more information and reports is helpful.

On my blue boards (two on breadboards and one still in bag), there's a blank 16 pin chip on top. I've looked though the supermagnifier on my work lamp, and it still seems blank, and tried with my iPhone Xxs n 2x optical zoom, and it still seems so.

On the black board, the chip is on the underside, and is indeed a 340.

Interesting. Sometimes manufacturers will sand off the writing on chips so that they can't be identified but I can't imagine any reason to do that with a CH340 (it is probably identifiable via the VID/PID anyway). Maybe they got a discount for the factory skipping the marking step? Or maybe it's the counterfeit FT232 and they thought it would be safer if it wasn't labeled.

The MCU all have markings (although it's serious effort and magnification to read them . . .) but the black board with the 340 behaves the same way (I think I was using it when I noticed)

I'v got another data point now, which I"ll put here for anyone searching in the future.

I noticed that my indicator LEDs, filling in for relays, would flicker early in the program.

After putting a block [while(true){}] to find the location, it seems that it was when setting the pinmode--as they're active low, this set them off.

And they are indeed doing it twice, even though I prevented it from leaving setup.

So it's definitely something about running while connected to the IDE causing a reset the better part of a second after the praam initially starts running after burning.

It only happens once if I then reset the MCU, even though it's still attached to USB.

I believe that what happens is this:

  1. You upload the sketch.
  2. After the sketch is uploaded, the bootloader starts running the sketch. avrdude is still running at this point (getting read to exit, but not as fast as the bootloader starts the sketch.)
  3. The sketch starts to print data.
  4. avrdude exits, and the IDE starts the Serial Monitor.
  5. as a result of one (or both?) of the Serial port open/close sequences in (4), the Arduino auto-reset circuits reset the AVR, and it restarts the sketch from the beginning (printing/etc the begnning a second time.)
    (6) recall that the auto-reset was supposed to happen automatically on port open/close, and then (later) explicit DTR manipulation was added to the -carduino avrdude target. This could means that the DTR wiggles and auto-reset could happen a couple of times when you're using upload and/or the serial monitor. How far your sketch gets would depend on timing (of the bootloader, the host, and the sketch...)

To confirm, put a scope (or an LED?) on the DTR signal...

To work around, but a delay (a couple seconds worth?) at the very start of setup().