It doesn't need to be reset at all if you write your code correctly using the code shown in the blink without delay example. Even when the millis counter overflows after about 40 days of being on continuously it will not need a reset.
1 Like
I have enjoyed your comments, curiosity and questions so much that I feel obliged to answer in kind.
This clock is for fun. It has digital count down displays with 60 segment bar graphs that kick in for the final 60 seconds.
Lightening chess can be fun and exciting when playing against the clock. I am hoping the final bar graph countdown will enhance the excitement. More so than the traditional flag.
That would be more cumbersome. I need at least 70 pins.
I built this clock many years ago with 12 Decade counters and logic gates etc. It is easier, quicker and probably cheaper with two Arduino's
Done that and looking again at my code, It will be easy to reset the game.
You are quite right. In retrospect I was too lazy to modify my code. 
But now I am fired up and ready to roll.
If you read the Mega data sheet you will see that a WDT Reset is Exactly the same.
1 Like
Some people just like throwing in their two cents without trying to solve the problem or doing something constructive.
1 Like
You would use 5 16bit IO-expanders.
The IO-expanders would be connected by just two IO-pins to the microcontroller.
All your direct connections to the microcontroller just move over to the IO-expander and that's it.
Of course this requires re-wiring. If you have it wired ready to run with two arduino-Megas you have a working solution so just use it.
For future projects you should consider if using IO-expanders would be a less cumbersome solution than using multiple microcontrollers
For a countdown display you could use WS2812 RGB-leds which require only one single IO-pin to control 500 RGB-leds
best regards Stefan
And others like to misunderstand questions to bend to their own limited knowledge.
That application note is perfectly true if you are using the ATMEL development system. If you take the approach mentioned in that note on an Arduino system you will never be able to use then Arduino IDE again, without re flashing the boot loader. This is because the WDT will time out and reset the processor before any new code can be loaded.
You need a much longer timeout to avoid this.
Some time ago, we had lots of people suffering from this according to the posts we received. Maybe you are too recent to the forum to remember. Or maybe something has changed?
@Delta_G is right.
The case was specific modification of the bootloader if I remember correctly.
WTD is an excellent way to reset the MCU intentionally or in a case of trouble like non-responsive MCU.
1 Like
Couldn't that be accomplished by calling setup( ) ?
(Your variables would have to be "=0" in setup().)
That explains it then.
As to when I joined it was
Joined 13 May '08
My son was asked at his work to provide a sound sample that could blow up the speakers in a product. He resisted for some time arguing that no one would want such a thing. Finally his boss forced him to. When the requesting engineer got the sound file he rang my son and said "The speakers have burned out", yes that is what you asked for. He continued "but didn't think it would happen immediately"
Anyway the OP has no need to resettle Arduino at all, so it is a moot point now about how to do it.
It's a confirmed X-Y problem, and it's a classic XY example too.
1 Like
Laughing Out Loud. An example that things should be specified with a minimum of precision.
Being a bit harsh here.
- I don't have a spare Arduino Uno that I could try this on.
- I did say:-
and I got the reply that:-
So I recon there is no need to do anything, because my knowledge of the problem has now been updated. That is why I have no interest in supplying you with an example, because the problem has been fixed, and you were right.
I didn't follow mentioned case precisely but in the bootloader at the beginning there is a evaluation of MCUSR register (WDRF), the reason of the reset. Depending on an action in the bootloader it can fall into a infinity loop.
I think @westfw could clarify it more.
But maybe not long enough.
I definitely remember that there were some issues related to watchdog in the early bootloaders like back in the 2010 and earlier time frame.
I have a note in some old sketch code of mine for the atmega168 from back in early 2011 that says:
If you did a watchdog reset when using an old bootloader that the board would go into a reset/boot loop until it was power cycled.
I'm sure if we really wanted to we could dig deep enough into the git history of the original "MEGA" bootloader, optiboot, and forum posts we could find out what the issue was and when it was fixed.
These days, I'm assuming that users will have a new enough bootloader, particularly if using optiboot in their board that they will not see the issue.
What makes things messy / complicated is that there are multiple bootloaders that have conditionals so that they can be built in multiple ways and some of them may still have the issue. So depending on which board you have, you may see the issue.
i.e. not all Arduino boards are using optiboot.
From a quick look in forum posts, it looks like there are still some issues on some boards.
--- bill
@bperrybap So what is your recommendaion?
If someone REALLY wants to reset a Mega in s/w, it can be done.
While we often see cases of people wanting to do this for reasons that could be to recover from or even mask bugs, I also think that there can be valid reasons to do so.
For example, in this specific case, it may be simpler, and quicker to get something reliably working by doing a reset in s/w than to go back and modify / update the code to use what most people would consider to be "proper" solution.
IMO, the easiest and best way to reset the processor from s/w is to use the AVR WDT capabilities.
It is quite trivial to do so and requires no pins or any external h/w.
i.e. it is a purely s/w based solution.
Just make sure to have a newer bootloader that supports watchdog resets.
If you have optiboot, it works just fine.
Here is some example code:
(It is quite old and was originally written prior to Arduino 1.0 and back when "Arduino" only had AVR based boards)
/*
* Demonstration of AVR processor reset under software control
* since the Arduino core library does not provide a function to do this.
* While this resets the AVR chip and all its internal registers,
* it won't reset any of the attached hardware that is external to the AVR chip.
*
* Note:
* This will not work with some of the older versions of the Arduino bootloader
* as they didn't properly initiliaze the AVR chip for watch dog reset & timeouts.
* With some older bootloaders it may cause the bootloader to get stuck in a
* constant reboot until the chip is power cycled.
*
* 2012-17-06 bperrybap - added flush for 1.x arduino to ensure message is sent
*
* May 2011 - bperrybap@opensource.billsworld.billandterrie.com
*/
void setup()
{
Serial.begin(9600);
Serial.println("setup()");
}
void loop()
{
Serial.println("Top of loop()");
for(int x = 3; x ; x--)
{
Serial.print(x);
delay(1000);
}
Serial.println("(Reseting Arduino)");
#if ARDUINO > 100
// force out the serial data as silly 1.x ALWAYS buffers xmits
// with no way to disable buffering.
Serial.flush();
#endif
resetArduino(); // reset myself
}
/*
* Function to cause the AVR to reset
*/
#include <avr/wdt.h>
void resetArduino()
{
noInterrupts();
wdt_enable(WDTO_15MS);
while(1); // wait to die and be reborn....
}
Clearly the WDT issue was/is a bootloader issue.
I guess to be pedantic, I should have said:
I definitely remember that there were some issues related to using the watchdog timeout in Arduino sketches when used with the early bootloaders like back in the 2010 and earlier time frame.
I'm also assuming that is what Mike meant as well.
vs meaning that any time a WDT timeout would hardware reset the board that it would brick the board.
I remember that there are some cases where a combination of bootloader and WDT used in the sketch that could prevent the board from being downloaded over the serial port even after a power cycle.
Thus from an Arduino user perspective, the board is effectively "bricked", since it would require re-flashing using ISP.
I seem to recall running into this as I was experimenting with the WDT capabilities using the early bootloaders.
And years ago, the board was essential bricked as most users didn't have a way to burn a new bootloader to get rid of the "offending" sketch.
AVR Bootloaders and the ability to do ISP programming on an Arduino has come a long way in the past 15 years.
Now you can get cheap USBASP devices or even do Arduino as ISP programming to reset/program the AVR chip using the IDE.
And it seems that some of these use cases/scenarios may still exist today for AVR based boards that are not using optiboot and may be using a very old bootloader.
--- bill
His name is "Grumpy Mike"..... 
I thought I asked a simple question....." Can a Mega reset pin be controlled with code?"
I have learned from this discussion that it was not as simple as I thought. I also learned that the answer to my question is "No." However, I did find a very simple way to programatically control the Mega reset pin. I used a digital pin to control the base of a switching transistor with collector to the Mega reset pin and emitter to ground. Someone here said it would not work due to some black magic that I didn't fully understand. Anyway, It works very well for me despite the fact that it used up the last available pin on my 72 io pin Mega.
1 Like