Automatic restart after a power failure

I want to reset my Uno ,after a power failure , without having to press the reset button.
Is it possible , for example , to do that with an electronic resistor-capacitor circuit connected to the reset pin ?

It will restart automatically after a power cycle, no reset required. As soon as the bootloader times out, it will run.

1 Like

Doesn’t Your Uno stop when power fails? It looks like the problem is when the power returns.I vahe seen this Before, a slowly raising power doesn’t make the normal start up work.

I want use my Arduino as a temperature controller for my homebrewing fermentation refrigerator. So if there is a power failure while I'm not home i want the arduino to restart in a known state when the power is back.

WattsThat "It will restart automatically after a power cycle, no reset required. As soon as the bootloader times out, it will run."
So, what's exactly the purpose of the reset button ?

One use of the reset button is to restart a sketch getting stuck somewhere.

I think there really is no good reason for the Uno to have a reset button. I certainly never use the things. In the rare case where someone needed to restart the program they could just unplug and then replug the USB cable, or even just close an open the Serial Monitor. I think it's just a tradition that stems from the bad old days when you had to manually reset the Arduino boards to do an upload. Even though the Uno never needed to be reset, the cost of a button is negligible and there is plenty of space on an Uno so there was really not much reason to leave it off the design.

Biasedturkey:
I want to reset my Uno ,after a power failure , without having to press the reset button.
Is it possible , for example , to do that with an electronic resistor-capacitor circuit connected to the reset pin ?

Don't know exactly what you are trying to achieve however, in one of my applications I have an auto reset after a certain time ( 30 minutes). Note that this is not related to power failure.
The way I did this was connect a diode from the reset pin (diode anode) to a digital pin (diode cathode) and simply pulled that pin low when time was up.
Reset pin is also available for manual reset at any time if required.

Thank’s all for the suggestions.
To resume: No need to worry.

Biasedturkey:
To resume: No need to worry.

No idea what this is supposed to mean.

Why not use a UPS?

SteveMann:
Why not use a UPS?

That seems to me the correct way to provide predictable behaviour.

Then the Arduino would keep running and with a suitable detector it would know when the power fails, and when it is restored and take appropriate action.

If the Arduino is just allowed to stop and start with the mains power how can it tell the difference between a restart after a power failure and a restart when a new program is uploaded, or a restart caused by the Watch Dog Timer?

...R

@Robin

There is a register in the 328 (and I think all micros) that contains the cause of the reset.

Unfortunately the boot loader (or older versions of it) might mangle it but if one gets rid of the boot loader, one will definitely be able to determine it.

The register is MCUSR, or on some AVR parts MCUCSR. The EXTRF bit indicates whether the reset was caused by the reset pin. The PORF bit indicates whether the reset was caused by powering cycling the chip. The WDRF bit indicates whether the reset was caused by the watchdog timer.

In my experience, all bootloaders mess with it to some extent (some less than others).

pert:
The register is MCUSR, or on some AVR parts ...

Seems like it would take a fair bit of testing to be confident that one knows how a particular system will behave.

In any case (even if the bootloader was eliminated) it could not tell the difference between a power failure and a deliberate de-powering of the Arduino only for maintenance purposes - i.e. the Arduino powered down while the rest of the brewing system continues as normal.

...R

Robin2:
Seems like it would take a fair bit of testing to be confident that one knows how a particular system will behave.

If you are running a bootloader you definitely need to run some tests. Here are some sketches I wrote for that purpose:

// Used to test the functioning of the MCUCSR register's WDRF (Watchdog Reset Flag) bit.
// This bit is set if a Watchdog System Reset occurs. The bit is reset by a Power-on Reset, or by writing a '0' to it.
// Some bootloaders cause the information in the MCUSR register to be lost.
// Note that the MCUSR register is called MCUCSR on some AVRs.
// Ground pin 2 to cause a watchdog reset.

#include <avr/wdt.h>

const byte LEDpin = LED_BUILTIN;
const byte buttonPin = 2;

void setup() {
  pinMode(LEDpin, OUTPUT);
  pinMode(buttonPin, INPUT_PULLUP);
  digitalWrite(LEDpin, bitRead(MCUSR, WDRF));
  bitWrite(MCUSR, WDRF, 0); //reset the flag - it is only reset automatically by Power-on Reset
}

void loop() {
  if (digitalRead(buttonPin) == LOW) {
    wdt_enable(WDTO_15MS);
    while (true) {}
  }
}
// Used to test the functioning of the MCUCSR register's PORF (Power-on Reset Flag) bit.
// This bit should be set to 1 (HIGH) after a Power-on Reset (reset caused by resuming the power supply to the MCU). It is only reset to 0 by writing to the register.
// Some bootloaders cause the information in the MCUSR register to be lost.
// Note that the MCUSR register is called MCUCSR on some AVRs.
// Ground pin 2 to cause a watchdog reset.

#include <avr/wdt.h>

const byte LEDpin = LED_BUILTIN;
const byte buttonPin = 2;

void setup() {
  // failed attempts to deal with the reset loop after WDT reset
  wdt_reset();
  wdt_disable();
  
  pinMode(LEDpin, OUTPUT);
  pinMode(buttonPin, INPUT_PULLUP);
  digitalWrite(LEDpin, bitRead(MCUSR, PORF));
  bitWrite(MCUSR, PORF, 0); //reset the flag
}

void loop() {
  if (digitalRead(buttonPin) == LOW) {
    wdt_enable(WDTO_15MS);
    while (true) {}
  }
}
// Used to test the functioning of the MCUCSR register's EXTRF (External Reset Flag) bit.
// This bit is set if an External Reset occurs. The bit is reset by a Power-on Reset, or by writing a '0' to it.
// Some bootloaders cause the information in the MCUSR register to be lost.
// Note that the MCUSR register is called MCUCSR on some AVRs.
// Ground pin 2 to cause a watchdog reset.

#include <avr/wdt.h>

const byte LEDpin = LED_BUILTIN;
const byte buttonPin = 2;

void setup() {
  // failed attempts to deal with the reset loop after WDT reset
  wdt_reset();
  wdt_disable();
  
  pinMode(LEDpin, OUTPUT);
  pinMode(buttonPin, INPUT_PULLUP);
  digitalWrite(LEDpin, bitRead(MCUSR, EXTRF));
  bitWrite(MCUSR, EXTRF, 0); //reset the flag - it is only reset automatically by Power-on Reset
}

void loop() {
  if (digitalRead(buttonPin) == LOW) {
    wdt_enable(WDTO_15MS);
    while (true) {}
  }
}

Robin2:
it could not tell the difference between a power failure and a deliberate de-powering of the Arduino only for maintenance purposes

You’re right that the program can’t tell the difference, but certainly the person doing the maintenance is going to know the difference. So it really depends on the application whether that’s a problem or not.

bluejets:
The way I did this was connect a diode from the reset pin (diode anode) to a digital pin (diode cathode) and simply pulled that pin low when time was up.

This method is known to be unreliable as part of the reset sequence is to set all pins to INPUT and you are cancelling the reset signal partway though the reset process.

Note I quote from previous discussion long ago: unreliable.

Railroader:
One use of the reset button is to restart a sketch getting stuck somewhere.

Indeed.

But it will probably get stuck every time anyway, so it may or may not help to determine where the problem lies! :grinning:

Well all I can say about that is, my application has worked reliably for over a year now.

Robin2:
In any case (even if the bootloader was eliminated) it could not tell the difference between a power failure and a deliberate de-powering of the Arduino only for maintenance purposes - i.e. the Arduino powered down while the rest of the brewing system continues as normal.

Nothing can do that. The only way to differentiate is to store some information first (in e.g. EEPROM) when the user brings the system down. E.g. a push button that will store the shutdown date/time.

sterretje:
Nothing can do that.

Which is why my preference is for a UPS so the Arduino keeps working.

...R

Robin2:
Which is why my preference is for a UPS so the Arduino keeps working.

...R

Your point was about differentiating :wink: