I have a remote wireless Arduino with sensor and sometimes I lose sync with the sensor data (happens very infrequently but does happen). I can set up error flags if this happens and I would like to have my error handling routine reset the remote Arduino via code. I cannot use the WDT as the wireless is tied into that. Despite the lost sync with the sensor data stream, the remote Arduino stills receives commands so I could send the remote a specific string sequence or integer to be acted upon. The easiest at that point would be a reset to wipe memory and start fresh.
Clever? You have an interesting definition for that word. A better word to describe #1 is "stupid". It can leave the processor in a state where it does not run after the " reset".
Why can you not re-sync just like a reset would do? A reset seems quite an overkill for a sync error!
Something like a state machine you can 'reset' in code might achieve what you want.
Or simply change the context of your app. Rather than thinking of the hardware/global scope as the top layer, make your loop function the top layer, as in: one loop is an entire life time.
Maybe this example will help get my view across:
volatile bool errorFound; //Only volatile cos an interrupt uses it.
void setup() {}
void loop() {
//Initialize system here:
errorFound = false;
while( !errorFound ) loop2();
//Shutdown / clean up anything here:
}
void loop2(){
//Application loop.
}
void someInterrupt(){
if( !errorFound ){
//Application is still in a running state, do something.
}
}
method 1 - appending pin 12 to reset pin
depending on the startupvalue of the pin the Arduino will keep resetting.
method 2 - jump to 0x0000
this will not a.o. cause hardware timers to reset properly (discussed many times on the forum)
depending on complexity of the sketch I would use it with more confidence than #1
pYro_65's suggestion is the way to do it. Have your sketch keep track of the state of the thing you are trying to reset, and go through the initialisation sequence when it needs to do the reset. It is not necessary to restart the sketch unless the runtime environment has become corrupted or you need to do a hardware reset. In the first case, you can't rely on the software to know there is a problem; in the second case, a software-only reset doesn't resolve the problem. If you're trying to do a software reset of your Arduino, it's almost certainly the wrong way to solve whatever your problem is.
I appreciate all the advice and information. My project is wireless and the code works fine 99% of the time. I don't understand why it glitches other than it is likely some RF interference (powerline noise nearby) or could even be a heavily magnetized car driving nearby the magnetometer sensor. The sensor/arduino remote is outdoors and not easily accessible. Power source is solar charged Lithium Nanophosph battery, so I can't flip a switch easily. Since I don't know why it glitches then not sure how I would track the state variables, etc. I thought to enable the WDT on the remote sensore/Arduino and send it life pulses but then this would keep the remote RF transceiver powered up at all times and that's not good as we have more cloudy days than sunny days in New England over the calendar year. Although I think I understand while not ideal, the jump to address 0 with a software reset function may be the easiest to implement as when the sensor data sync problem occurs the transceiver function seems to be intact and I could send it a defined reset string to act on. Any other advice greatly appreciated.
I just finished updating my code on the remote to receive from host a reset (jmp to 0) request. It seems to work fine resetting the remote Arduino and Sensor. The data being sent from remote to host appears sync'ed correctly and both Arduino's are communicating correctly after the reset. I understand this jump to beginning doesn't clear any registers/RAM that could have been corrupted before then reset. Does the jmp to 0 only restart the program at the bootloader or at the beginning of my sketch (setup)?
I guess I wont know if this really works until its out in the field again and I can see how this method works to revive it in "real" circumstances.