Software Reset?

Would it be possible to wire a digital pin to the reset pin then have the digital pin go low to reset the arduino?

Thanks for any replies, DigitalJohnson

Sure - do it thru a 100nF capacitor like DTR comes in from the USB interface, wired in parallel with the DTR cap to the reset pin.

I would program that pin to be an input with internal pullup right up until you want to use it, then use pinMode to make it an output and digitalWrite it low - the reset will make it an input again.

DigitalJohnson: Would it be possible to wire a digital pin to the reset pin then have the digital pin go low to reset the arduino?

Thanks for any replies, DigitalJohnson

This as been discussed frequently over time. The AVR datasheet is clear that such a method won't be successful because as soon as the reset process starts all outputs default to input mode, thus removing the low on the reset before the full time that the reset process takes. And using a series cap won't change the fact that reset procedure takes a specific minimum time to complete.

That being said, there is a way to generate a chip reset via software, and that is to utilize the watch dog timer. However the question one usually asks at this stage is why does a sketch require a system reset, that can't better be accomplished by proper program structure and flow?

Lefty

Rats, thought that would work too.

Would this help?

http://www.youtube.com/watch?v=5fXN7x7a5So

hahaha nice

@ Nick Gammon

Thanks for the vid. That was pretty f***ing funny! XD.

@ retrolefty

I don't have a specific use in mind. It's more of a curiosity/learning thing. The more possibilities you're aware of, the more you're able to accomplish. I'll do some reading on the watch-dog reset. Do you know of any helpful links in particular? Also, how about a 555 in one-shot mode triggered by a digital pin? And I agree proper program structure shouldn't need a reset. However, if a reset were needed a pin change [u]seems[/u] like it would be the simplest method. I may be wrong.

Thanks for the replies guys, DigitalJohnson

I'll do some reading on the watch-dog reset. Do you know of any helpful links in particular?

No, but there have been postings on using it now and then. A nice general purpose WDT library could be a nice contribution for us software challenged types. ;)

Also, how about a 555 in one-shot mode triggered by a digital pin?

That would certainly be one method to allow a software generated reset to occur.

And I agree proper program structure shouldn't need a reset. However, if a reset were needed a pin change seems like it would be the simplest method. I may be wrong.

Most of the questions is see posted here about how to do a 'software reset' seem to come from beginners to programming and they usually have yet to master or understand all the control flow methods that C/C++ offers, so their thinking is just a means to get their sketches to 'start over'.

Lefty

If you can predict that you need a reset at an exact, programmed, point, then you probably don't need it. Proper program design would cater for that.

The watch-dog timer is useful for generating a reset/interrupt to recover the device from some unanticipated problem.

For example, on a satellite launched to Jupiter, you might have a watch-dog timer to reset the on-board electronics if it doesn't hear from Earth within 24 hours, just in case some subtle problem put its code into a loop. Otherwise you have wasted an awful lot of money. But if you can predict "oh, I think I'll reset myself now" and drop pin 3 low, then you probably shouldn't need to do that in the first place.

One possible way of achieving it though would be to have a second chip (eg. a 555 as you said) which, upon command, drops the reset line for a second.

Do you know of any helpful links in particular?

I used a watchdog timer here to wake up the chip after 8 seconds:

http://www.gammon.com.au/forum/?id=11149

There is the "re-initialize global variables from the data stored in flash" set-up part, which is hard (expensive) to do on your own, and which the flash already knows how to do. If that's something you want/need, then it would be swell if the runtime library could do it for you. Perhaps there is some inline assembly that will let you call the SRAM setup code?

@ Nick Gammon

If you can predict that you need a reset at an exact, programmed, point, then you probably don't need it. Proper program design would cater for that. The watch-dog timer is useful for generating a reset/interrupt to recover the device from some [u]unanticipated problem[/u].

Unanticipated is the keyword here. What got me thinking of using a hardware reset is that I'm working on a home alarm system with many features. It has a TFTLCD w/ touchscreen. It has 24 zones, each with programable loop (open/closed loop, normally high/low) for different types of sensors. Battery backup with charge monitoring and low battery shut down. Multiple access codes, each with different functionality. An event log to keep track of which access code was used at what time. All menu driven, as well as a few other features.

It is [u]A LOT[/u] of code. So, I started thinking. If for some reason I missed something or an unpredictable event occured and put the program in loop or some other error condition. That needs to be dealt with. It sounds like the watchdog timer is just what I'm looking for. My main loop in all cases completes in less than 2 seconds. Am I a correct that if I set the WDT to say 2sec. Then reset the WDT at the end of the main loop. If the loop takes longer then 2sec. have a reset occur?

Thanks again, DJ

That’s right. Example code:

#include <avr/wdt.h>

void setup ()
{
  Serial.begin (9600);
  wdt_enable(WDTO_1S);  // reset after one second, if no "pat the dog" received
 }  // end of setup

void loop ()
{
  
Serial.println ("Entered loop ...");

Serial.println ("Point A");
delay (500);
Serial.println ("Point B");
delay (500);

wdt_reset();  // give me another second to do stuff (pat the dog)

Serial.println ("Point C");
delay (500);
Serial.println ("Point D");
delay (500);

while (true) ;   // oops, went into a loop
    
}  // end of loop

Thanks for your help Nick. I love learning new things! :slight_smile: I checked out the WDT thread on your forum. It looks pretty straight-forward (not at all complicated). This will make a good fail-safe for program lock-up. If anyone knows anything I should be aware of when using the WDT, feel free to post.

THANX,
DJ

One thing you may need to know is that older bootloaders don't disable the watchdog when they start up. This results in the chip continually resetting once the first watchdog reset has happened.

dc42: One thing you may need to know is that older bootloaders don't disable the watchdog when they start up. This results in the chip continually resetting once the first watchdog reset has happened.

Yep, I can definitely confirm this. I just spent the evening fixing the atmega bootloader. (I literally just finished up and updated my bootloaders)

Without a watchdog code correction, the watchdog reset function is totally useless for the m328s using the atmega bootloader.

There are a few issues: The code won't compile with the current compiler (its a few lines to patch it to compile). Then you have to reset the watchdog registers properly if you don't have WATCHDOG_MODS enabled (which it isn't enabled in the Makefile by default for the mega328).

Not sure how to really get the official code updated as I was poo pooed the last time I brought up the issue of the atmega bootloader not compiling with the current compiler tools and even offered simple a fix that allows the code to compile with both old and new tools.

--- bill

One thing you may need to know is that older bootloaders don't disable the watchdog when they start up. This results in the chip continually resetting once the first watchdog reset has happened.

I have the Mega2560. Does this board disable the WD when it starts?

I use this for a software (Arduino) reset and seems to work.

Put this near the beginning of your code:

        void(* resetFunc) (void) = 0;     //declare reset function @ address 0

Then where ever you want to call a reset just put:

        resetFunc();  //call reset

That would jump to the start of the software reset, however the hardware isn't reset. So for example, if you assume that, after a reset, all pins are inputs, this might not be the case.

Nick, do all electric outlets down under have switches on them?

DigitalJohnson:

One thing you may need to know is that older bootloaders don't disable the watchdog when they start up. This results in the chip continually resetting once the first watchdog reset has happened.

I have the Mega2560. Does this board disable the WD when it starts?

The bootloader stuff seems pretty messy.

From what I can tell with Arduino 0022: There are 6 different bootloaders supplied, most of which seem to be slight modifications from the same ancestry. It apears that none of them other than the optiboot bootloader properly deal with the watchdog reset.

So depending on your bootloader and the way it was built and your sketch code, you can potentially brick your Arduino if you turn on the watchdog timer very early in your sketch code and then not properly handle clearing the timer. (I did it to a m328 board and had to burn a new bootloader to erase the sketch)

atmega: The atmega bootloader code supports pretty much all the AVRs used on arduino except the mega8 and the 2560. It has support for the mega128 and mega1280 but the Makefile does not have support to build the mega128 version. Contains code to do quick jump to app code on powerup and watchdog timeout (watchdog timeout quick start is only if WATCHDOG_MODS is enabled but it is not enabled by the Makefile) My guess is that it should be easy to update this for the 2560.

atmega8 The atmega8 bootloader only supports the mega8

bt: Looks like it was created from copying atmega8/atmega but has not received all the udpates that atmega has gotten. Makefile only supports building BT arduino with mega238.

lillypad: very similar to bt bootloader but looks older in that there is no support for mega328. Makefile only supports build for lillypad which is a mega168.

optiboot: New improved re-written bootloader that looks to be the replacement for the atmega series bootloaders. Much smaller at 512 bytes instead of 2048. Code has no support for mega128, mega1280 or mega2560. It is really just for m168/m328 devices. Makefile does have support for more boards/options than the atmega+lilypad

stk500v2: Totally different origin than the atmega bootloader. Code appears to have support for ATmega8, ATmega16, ATmega32, ATmega64, ATmega128 ATmega162, Atmega1280, ATmega2560, ATmega2561. Makefile has support for a few other boards but mainly for 1280 and 2560.

Now how Arduino 0022 uses them: (This is according the boards.txt file as supplied with 0022)

atmega8 uses atmega8 mega2560 uses the stk500v2 mega1280 uses the mega Arduino BT (328 & 168) both use mega UNO m328 boards use the optiboot lilypad m328 board use the mega lilypad m168 board use the lilypad all others use the mega bootloader


So that was a long answer that it, unfortunately, looks like the 2560 bootloader will not work for watchdog reset.

The good news is that it is only a couple of lines of code to fix it and there is plenty of room in the mega and stk500v2 bootloaders for it.

So like I said earlier I updated my mega bootloader code and then updated my mega bootloaders. And while I've not needed it in the past, I can now reset the AVR in software using a simple 3 line C Macro.

--- bill