Is it possible to reset the Arduino with a software command?

Hi Bill,

That may be tricky, depending on the scope some variables are set to zero automatically, and others will have different content (i.e. non-zero).

However, one option is to write your data to EEPROM, which of course is persistent even after power loss.

Is there a reason you wish to reset? Ordinarily you'd never do that (unless a software failure was detected, e.g. using a watchdog timer)

or some rare scenario like a software upgrade. (normal practice is to never allow have the microcontroller to reset or exit).

I realize how correct you are re: It's not wise, normal to reset, re power a microprocessor. But I am concerned that an error could occur that would lock up the system. By starting from the beginning would clear any thing like overflowing the stack due to incorrect input or electronic noise or my bad programming. I don't have debugging programs that would allow me to se the state of all the variables , stack etc. I also don't have the time or expertise to check every possible scenario.  I tried setup() ; ..there is where I realized that I can't leave the variables as they are ( what a mess this creates). I appreciate all the helpful advice and I am still working on all the suggestions. At present, I am still using the asm volatile ("  jmp 0") and although it causes blinks in the display, it seems to be safe regarding the above. The training is worthwhile even if I am not able th fully understand all the ramifications of the suggestions.

Bill

Hi Bill,

A software reset can (sometimes) be a good thing to do to handle situations as you describe (program runaway for instance).

I was just addressing that second point in you original question, i.e, regardless of the way the reset occurs (jmp zero, watchdog programmed reset, or forcing a pin as mcb1 mentions), the variables can not be assumed to remain the same (despite power not having been removed from the chip), because in-between the reset and the Arduino main/loop etc, there is a bit of invisible code (called C startup or similar) which will force some variable storage to zero. Any that are not forced to zero cannot be presumed to be uncorrupted anyway, due to the program runaway which might have caused the reset (so that was the only reason I wanted to confirm why the reset was to occur, because we have to presume loss of all state information upon reset (regardless of the way the reset occurs) unless state can be inferred from elsewhere (e.g. logic levels on pins or non-volatile memory).

Thank you. My comment was not meant in any way to be criticizing. Quite the opposite. I can't thank you and the others on the forum enough for all the help. I take every comment in the way it is intended, that is, to be helpful.

Hi Bill,

You're too kind, it was no problem at all to help. I just wasn't sure if the second part (regarding the state of variables had got lost in the discussion since the thread had grown a bit since I last saw it!).

I don't know much recent stuff about Arduino, but I learn a lot from following what you and others do with it. From that I gather it

has underlying C compiler, just the compiling/building of the code is hidden from the user to a degree.

Not that I am a software programmer, but I tend to force/set variables either during the initial declaration or during void setup().

Call me stupid but I always imagined it was better to be sure.

Mark

Hi Mark,

I do too, it would be thrown out in a code review if it wasn't, so I agree. I interpreted Bill's query to be whether there was a way to maintain variable content across a reset regardless of whether it was wise or not. The answer being no, not all variables will be persistent (some data spaces are).

Hi Mark,

I do too, it would be thrown out in a code review if it wasn't, so I agree. I interpreted Bill's query to be whether there was a way to maintain variable content across a reset regardless of whether it was wise or not. The answer being no, not all variables will be persistent (some data spaces are).

I think more specifically it would be fare to say you "Can Not Guarantee" the preservation of volatile RAM through a reset condition so therefor should NEVER rely on it happening

If you need variables preserving across resets either software invoked or Power Cycle then you need to use None Volatile RAM, either the EEPROM or an external SD Card

Hi Peter,

In theory if you're careful, the behaviour is guaranteed. The JMP 0 won't corrupt memory, it is a legal instruction. However, as mentioned several times, the compiler and C-startup code will have defined behaviour, and it depends on the scope of the variables. That part is outside of our control (unless we rewrite it, or use a different language or just write in assembler).

In real life, the answer is obviously no for a couple of reasons, primarily because if you've had program runaway then you cannot assume your important variables have not been corrupted either, and secondly in real life no-one would ever be allowed to have such code in a shipping product since it won't pass any code review.

But it may not take much to mess that up, for instance a pin state (Input) being different during the power on first time run causing the order of the variable creation to be different, now your really messed up.

Yes there are ways around it to improve the odds of the ram to be intact but is it worth the headaches, and it still does not help you with a power on reset as here there are no guarantees and the code really does not know the difference.

Though some MPU;s have a flag to indicate if the reset was a POR or Soft but i'm not sure if the AMEGA328 has that

I agree. A POR isn't the same, and all goes out the window in that case. And as you say, additional trickiness is then to figure out what kind of reset occurred. I think Bill is aware we're not advocating this should be done at all, we wouldn't do it for real. In practice only a few times I can think of for a JMP 0 (other than a watchdog forced reset which can be a different location) such as perhaps after an in-service software upgrade.. and even then we wouldn't be presuming the state of RAM contents in our code (for reasons mentioned before).

As usual, a simple question is more involved depending how deep the rabbit hole we go.

Oh so true

But a fun road to travel, as with many things, the trip can be more fun that the destination