Hardware circuit to Trigger Board Reset through software - In essence, push the reset button through a software trigger
Ok, I don't know if this is the right section to post this in but I thought I would share this since I couldn't find an answer when I was searching for this so hopefully the next person needing to "push the reset button through software" will be able to find and use this.
I needed a way to reset the board through software for my project without causing issues with uploading new software to the chip. I had found one solution online but you had to disconnect the trigger pin every time you wanted to upload a new sketch which was not a viable solution to me. So I build the following circuit:
Capacitor is charged by Pin 15 (on my Mega). The first transistor is triggered by Pin 14 which in turn causes the capacitor to latch the first transistor open until discharged which in turn triggers the 2nd transistor to open and ground the reset pin. When the board resets itself it automatically writes all digital Pins to LOW and the circuit closes after the capacitor is discharged. I ran my Mega through 30 some test runs in 10 second intervals and it's working great. Holds the reset pin LOW just long enough to trigger the reset. Have not tested this on any other board but in theory, if it doesn't work on another board because it does not hold it open long enough you could always bump up the capacitor value.
Code wise here is what you need (and yes I am fully aware this is not actually a HARD Reset but that's what I called it in my sketch):
Declare you pins:
const byte HardResetPowerPin = 15;
const byte HardResetTriggerPin = 14;
Write the following in void Setup:
// Set HardResetPins to OUTPUT
pinMode(HardResetPowerPin, OUTPUT);
pinMode(HardResetTriggerPin, OUTPUT);
// Set HardResetTriggerPin LOW (just in case)
digitalWrite(HardResetTriggerPin, LOW);
// Power Reset Capacitor
digitalWrite(HardResetPowerPin, HIGH);
Then at any point you want to trigger the Reset:
digitalWrite(HardResetTriggerPin, HIGH);
I have read quite a few horror stories about people locking their board with some software reset loop, unable to upload a new sketch to fix it because it is constantly resetting itself, so I personally prefer this method over any others I have been able to find online because if you accidentally get it stuck in a reset loop, simple disconnect the ground from transistor #2 or disconnect the reset pin on the board.
Regarding Osgeld's sketch ( which is sufficient for that task ) :
There's already a built in pullup resistor between RESET and +5V.
As this is pretty high ( 10k ? ), the other resistor is not critical. Anything (or rather 470 ... 47k ) would do, with any npn transistor.
Main reason for more electronics than a wire between trigger pin and reset is, to allow startup with a wrong sketch.
Else a simple wire were sufficient :
// Sample software to trigger Reset
// requires nothing but a wire between Pin 9 and Reset
# define resetTriggerPin 9
boolean wannaReset=false;
void setup()
{
digitalWrite (resetTriggerPin, HIGH); // another pullup resistor for RESET
digitalMode (resetTriggerPin, OUTPUT); // order matters
}
void loop()
{
// TODO: add code to eventually set wannaReset to true
if ( wannaReset ) digitalWrite(resetTriggerPin, LOW);
}
BTW: It's more challenging to setup something that inhibits a reset, but only during some critical phase in your sketch. ( Well, to temporarily avoid a reset via Serial should be doable )
fungus:
Just connect the reset pin to another I/O pin...
When you want to reset set the port to OUTPUT then set it LOW.
Doing this will cause a reset loop and even if you force write the pin HIGH on start up this will mean you will not be able to upload a new sketch without disconnecting the pin (not sure if this is true on the UNO or Mega but my planned chip is a stand along ATMega1284P_PU without all the extra hardware on the board that we take for granted)... my project is stand alone aka disconnecting the reset pin means opening up my project box every time I want to try a new sketch.
Much simpler. I went with the capacitor mainly because I had read that the manufacturer doesn't recommend using just the power of a pin without some sort of way to ensure the reset is held sufficiently long. Was I miss lead here?
As for the backwards transistor... I am new to drawing circuitry lol and the transistor I am using is bipolar (which I assume means it can go both ways because it works either way on my breadboard).
InitialForce:
Much simpler. I went with the capacitor mainly because I had read that the manufacturer doesn't recommend using just the power of a pin without some sort of way to ensure the reset is held sufficiently long. Was I miss lead here?
If you're using an I/O pin for reset then it's impossible to hold it for too short a time. It will be held low until reset happens, no more, no less.
You can force a hardware reset using the watchdog timer, which is what I do in my projects. The only complication is that some of the older bootloaders don't disable the watchdog when they start up. One way round this is not to use a bootloader - you don't need one anyway if it's a standalone system, you can program it via ICSP instead.
fungus:
Just connect the reset pin to another I/O pin...
When you want to reset set the port to OUTPUT then set it LOW.
AVR cautions against using that method as it will not reliably allow a full legal reset condition. The problem is that the start of the reset process all I/O pins are set to input mode, thus losing the low being wired to the reset pin. There is a minimum length that the low reset pulse must meet to fully satisfy a hardware reset condition. Using the WDT is the only way to create a true reset condition under software only control unless you utilize some external components like a 555 timer chip to create the needed reset signal length.
This is on an atmega328p running at 8MHz. I'm not using a bootloader, so 0.25sec is ample time for the processor to be reset and control passed to setup(), provided you don't have any static initializers doing complicated things that they probably shouldn't be doing anyway.
Paul1958:
Have you tried this? I have. It dont work...
Nope, of course it doesn't, he was wrong. See the post by retroleft above where he refers to the datasheet. Atmel specifically warns that this will not work!
This thread is over two years old. Please look at the date on posts before posting in a thread. For that matter, read the posts in the thread, too, (like the one I referenced above)
