IDE v.1.8.3 Can I change RESET/RECOMPILE behavior on upload?

Building project for ATMEGA328, NANO

I seems that even when I compile/verify, a subsequent UPLOAD will first RESET the board , the RE-COMPILE the project, THEN upload. Is there anyway to either block the board RESET, or at least prevent the extra re-compile before upload begins?

I probably never noticed with short test programs, but as my project has gotten bigger (now at about 67% of program storage space used), this sequence has become annoying and occasionally causes upload failures. It probably makes sense for a RESET to occur just before the UPLOAD. But by then re-compiling AFTER the reset and before the upload, it causes my lengthy startup sequence to occur and get interrupted at weird places. Then of course after the upload (if it doesn't fail) the program will naturally re-start.

That's not what my IDE does. Mine completes the compile process, and only then calls avrdude, which opens the serial port (resetting the board) and uploads the sketch. The only situation I can think of where the series of events you described might occur is if the upload button was getting double-pressed or something?

Can you enable verbose compile and upload output in settings and post the output?

DrAzzy:
That's not what my IDE does. Mine completes the compile process, and only then calls avrdude, which opens the serial port (resetting the board) and uploads the sketch. The only situation I can think of where the series of events you described might occur is if the upload button was getting double-pressed or something?

Can you enable verbose compile and upload output in settings and post the output?

Appreciate the response. No, the upload is on a pulldown menu, which in Windows only activates after releasing the mouse button (intentionally to avoid such double selections).

I went into Preferences-> settings (tab), and could not find a Verbose Compile option.

At least I know its NOT supposed to be doing this now.

  • File > Preferences > Show verbose output during: > compile (check) > upload (check) > OK
  • Do an upload
  • After the upload finishes click on the black console window at the bottom of the Arduino IDE window
  • Ctrl+A - this will select the entire contents
  • Ctrl+C - this will copy the selection to the clipboard
  • Post the output you copied here. If it exceeds the 9000 characters allowed by the forum then save it to a text file and attach the text file to your reply. You need to click the "Reply" button to see the "Attachments and other options" link that allows you to add an attachment.

@Pert – result of upload attached

uupladVerboseOutput.txt (21.4 KB)

It looks normal to me. You can see it is doing caching so you're not waiting for a complete recompilation every time.

At which stage in the process does the first reset happen?

pert:
It looks normal to me. You can see it is doing caching so you're not waiting for a complete recompilation every time.

At which stage in the process does the first reset happen?

OK, so...

  1. RESET happens the moment I click the UPLOAD, then...
  2. a complete recompile happens, at least in the sense of displaying that activity above the black info area, AND the taking the same amount of time to complete as if I changes things in the code.
  3. The actual upload starts (confirmed both by the IDE activity, and the activity LED on the NANO
  4. At the end of the upload, the NANO restarts again, with the new code.

PeterPan321:

  1. RESET happens the moment I click the UPLOAD, then...

There is a serial related action immediately upon clicking the Upload button. This is when the Arduino IDE disables the Serial Monitor. I can't reproduce your issue but I think that may be a clue.

PeterPan321:
2) a complete recompile happens, at least in the sense of displaying that activity above the black info area, AND the taking the same amount of time to complete as if I changes things in the code.

The sketch is compiled each time. The core and libraries should only be compiled the first time and if anything changes. It really doesn't make much sense not to compile the sketch every time since if there were no changes to the sketch then what's the point of compiling it again?

pert:
There is a serial related action immediately upon clicking the Upload button. This is when the Arduino IDE disables the Serial Monitor. I can't reproduce your issue but I think that may be a clue.
The sketch is compiled each time. The core and libraries should only be compiled the first time and if anything changes. It really doesn't make much sense not to compile the sketch every time since if there were no changes to the sketch then what's the point of compiling it again?

Well on the first point, its good to know its not reproducible at your end, so thanks for taking the time. At least its one variable off the list. :slight_smile:

If you can't reproduce the second point, then I must have a bug in my setup somewhere. I agree... if nothing changed, there's no point in the extra re-compile when I upload. Perhaps I have a library somewhere in a folder that has a read only state. If the compiler was attempting to leave some kind of "all done" flag somewhere in the file system it could not access, I could see where it would choose to re-compile again, to err on the side of safety. Will have to investigate further. I'll post if I figure out the problem.

Thanks again for taking the time!

PeterPan321:
I agree... if nothing changed, there's no point in the extra re-compile when I upload.

You got it backwards. I was saying there is no point in an upload if nothing changed. If you are uploading a the same program to many boards then of course you wouldn't want a recompile of the sketch every time but the you can just run the avrdude command from the command line or a script. That usage is beyond the scope of what the Arduino IDE is intended to be used for.

pert:
You got it backwards. I was saying there is no point in an upload if nothing changed. If you are uploading a the same program to many boards then of course you wouldn't want a recompile of the sketch every time but the you can just run the avrdude command from the command line or a script. That usage is beyond the scope of what the Arduino IDE is intended to be used for.

I get it now. Still strikes me odd that the IDE upload command forces a reset, forces a new compile (needed or not), then uploads. I think it would be a reasonable improvement to eliminate the compile step as an option, but I can live with it.

Thanks again.

Maybe create a simple sketch that prints a message to the serial port in setup().

Compile and upload to get the new sketch in.

Open a terminal application (not serial monitor). I used realterm (and an Uno, no Nano at hand) and it displayed the message.
2)
Next try to compile and upload again (leave realterm connected).
2a)
If you see the message again during the compile, the board received a reset.
2b)
If not, your board did not receive a reset; and the upload will fail because avrdude could not open the serial port.

Is 2a indeed what is happening?

Test sketch used:

void setup()
{
  Serial.begin(57600);
  Serial.println("Ready");
}

void loop()
{
}

You can add a simple blink in loop() if needed; it should keep on blinking during the compile.

PS
IDE version 1.8.5

sterretje:
Maybe create a simple sketch that prints a message to the serial port in setup().

Compile and upload to get the new sketch in.

Open a terminal application (not serial monitor). I used realterm (and an Uno, no Nano at hand) and it displayed the message.
2)
Next try to compile and upload again (leave realterm connected).
2a)
If you see the message again during the compile, the board received a reset.
2b)
If not, your board did not receive a reset; and the upload will fail because avrdude could not open the serial port.

Is 2a indeed what is happening?

Thanks. OK, I haven't tried this with a simple short sketch yet. But the project I'm working on has plenty of occasional debug serial outputs, so I started there to test out RealTerm (just installed). First of all, as soon as I connect with RealTerm, it resets my board (and then of course I see my debug messages). Pressing reset (which of course resets) and debug messages are displayed. So I conclude that (a) any external opening of the USB serial port causes a board reset and (2) the IDE must be opening the port as soon as I hit UPLOAD, but then wastes time recompiling before starting the upload.

Also, not surprisingly, with RealTerm still connected, avrdude reports it cant open the comm port.

But this led to another discovery! If I shut down the realterm connection, that resets the board. Opening again does not, but closing always does. Further, if I keep both the realterm connection IDE serial monitor closed, no extra reset occurs at the instant I hit UPLOAD. So that tell me when you hit UPLOAD on the IDE, it closes the serial connection, which for some reason on my boards causes RESET. And of course it makes sense to shut down the serial monitor to upload, because serial port emulator drivers usually don't provide the port as a shared resource. (I know it can be done, but mine obviously is not). I can't repeat the experiment with the SPY feature, because I don't have that feature installed on the free version.

Now with the short sketch you provided, I still have to keep the realTerm disconnected to upload, but I see evidence of the reset still happening twice... once when I hit UPLOAD, and again when the upload completes. Its pretty obvious because the blinking LED from the last U/L freezes when I click UPLOAD, and then of course momentarily freezes again when the upload completes. Again, keeping the serial monitor closed avoids the unwanted initial reset.

OK... if that's the way it works. I can live with it. Thanks again.

So I conclude that (a) ... and (2) the IDE must be opening the port as soon as I hit UPLOAD, ...

From the below, it does not have to open the port, closing it is the culprit in your case.

If I shut down the realterm connection, that resets the board.

Opening a comport will reset the 328P micro; this is normal behaviour. Closing the com port usually does not reset the board but this might have to do with the driver. Is this an original nano with FT232RL chip or a clone with CH340 chip? If the former, can you re-install the driver from the Arduino driver directory>

When you hit upload, the IDE does indeed close the connection used by Serial Monitor; it however has no way of closing the connection that is used by RealTerm (as far as I know).

Do you see the debug messages in RealTerm when you hit upload and the connection is open in RealTerm? That's not quite clear to me from your last reply; with the little sketch that I provided, you should see a new 'Ready' occur in RealTerm.

PS
I tested it with a Sparkfun Redboad again which uses the FT231XS (the only FTDI based board that I have); behaviour is normal (no reset on closing the connection)

sterretje:
From the below, it does not have to open the port, closing it is the culprit in your case.
Opening a comport will reset the 328P micro; this is normal behaviour. Closing the com port usually does not reset the board but this might have to do with the driver. Is this an original nano with FT232RL chip or a clone with CH340 chip? If the former, can you re-install the driver from the Arduino driver directory>

This one is a clone. I'll have to try with my one and only original when I get a chance. but the behavior seems the same. In fact if I have an external power supply feeding the project, I can pull out the USB plug and the NANA no care. :slight_smile:

sterretje:
Do you see the debug messages in RealTerm when you hit upload and the connection is open in RealTerm? That's not quite clear to me from your last reply; with the little sketch that I provided, you should see a new 'Ready' occur in RealTerm.

If I don't close the Realterm connection, the upload will fail, because the USB serial port is busy. I'll get a debug message complaining it could not open the port. If you are able to upload to the USB while the Realterm com port is still open, then maybe the original PC based factory USB driver implements the serial port as sharable. Or maybe you're using a linux/unix system, which also might explain the difference.

sterretje:
PS
I tested it with a Sparkfun Redboad again which uses the FT231XS (the only FTDI based board that I have); behaviour is normal (no reset on closing the connection)

Interesting!

If I don't close the Realterm connection, the upload will fail, because the USB serial port is busy. I'll get a debug message complaining it could not open the port.

I'm not talking about that debug message; I'm talking about the 'Ready' message from my short application or the debug messages that your Arduino application seems to generate on reset.

So now the question is what you mean by 'debug messages' in your earlier posts?

sterretje:
I'm not talking about that debug message; I'm talking about the 'Ready' message from my short application or the debug messages that your Arduino application seems to generate on reset.

So now the question is what you mean by 'debug messages' in your earlier posts?

I guess I've been using the word to describe a few different things. Usually when I say DEBUG messages, I'm talking about my own Serial.println() statements, for debugging and confirming things are happening as expected. But in some cases I may have called error messages in the black lower window of the IDE "debug" too.

For my test I a series of fast blinks in setup and then slow blinks in loop. Then you have a sure indicator of a reset without serial output. I did also add some serial prints to see if that was somehow related.