I believe that an Arduino can get restarted for the following reasons:
#1. Code is downloaded. After the download, the Arduino system is restarted by the downloader. #2. A serial port monitor is started on the PC that is connected via USB. #3. The reset button on the Arduino board is pressed #4. Power is restored to the Arduino board after power disconnect.
Is there a way for an Arduino program to detect which of these caused the restart? I am interested in all of these, but most particularly #1. I would like to use the program compile time to set (or reset) the time in the RTC chip. However, this is only a valid thing to do when code was just downloaded.
I moved your topic to an appropriate forum category @cdj15.
In the future, please take some time to pick the forum category that best suits the subject of your topic. There is an "About the _____ category" topic at the top of each category that explains its purpose.
Hi @cdj15. Please add a reply here on this forum thread to tell us which Arduino board you are using.
Please be as specific as possible as some Arduino boards with similar names have significant differences and the forum helpers can only provide effective assistance if we are aware of which one is being used.
If you aren't sure how to describe which board you are using, you can provide the link to the online product listing you bought the board from and we'll proceed based on the information found there.
The last time I tried to get that information on an UNO type board I found that the bootloader cleverly zeroed the register containing the information before branching to the user code. I think it was done to prevent some pathological case from causing an infinite loop in the bootloader. This was years ago so I don't know if things have changed.
There is a sketch that demonstrates reading and interpreting the MCUSR register here:
Note the important caveat mentioned by @oldcurmudgeon in post #7, and in the comment in the sketch:
Normally, MCUSR itself is destroyed by the use of a bootloader, but Optiboot v4.6 and later save the contents in register r2, where it can be accessed by an application.
The genuine UNO R3 boards come with an older version of the Optiboot bootloader (I believe somewhere around version 4.4) that doesn't have the "save the contents in register r2, where it can be accessed by an application" feature. It looks like the SparkFun boards also use that old version of Optiboot.
Another thing to note is that the information in that sketch comment is outdated. Versions >=7.0 of Optiboot actually do preserve the MCUSR value to some extent:
As discussed here (and in the other threads linked off this one):
So all this is to say that you can definitely get information about the cause of the restart if you replace the bootloader on your boards with the latest Optiboot. If you are interested in doing that, let us know and we'll provide instructions. You do need an ISP programmer to do it, but you can make a DIY "Arduino as ISP" programmer out of one of your Arduino boards so as long as you have some jumper wires on hand, you have all the hardware you need already.
When you upload to the UNO R3 board, the bootloader is activated by the board's auto-reset circuit, which produces an "external" reset cause. After the upload finishes, the bootloader uses a watchdog reset to exit the bootloader, which produces a "watchdog" reset cause.
When the port is opened in Serial Monitor, it resets the board via the auto-reset circuit. This produces an "external" reset cause.
This produces an "external" reset cause.
This produces a "power on" reset cause.
So you can see that, it is definitely not going to be possible to differentiate (2) and (3) from each other. I think you should be able to differentiate (1) from the others (because I think you will get the "watchdog" reset cause instead of "external"), and definitely you can differentiate (4). So I guess that will be sufficient for your needs anyway.
An Arduino can also reset from other causes. Like when switching on a motor. This cause the motor to generate RFI (Radio Frequency Interference) and there is no way of spotting that cause in software.
Thank you very much for providing these details. This is exactly what I wanted to know. I'm a little skittish about the required update - I'll have to think about it, but now I know that it is possible to detect the initial boot, and what I need to do to make it happen. Thanks again.