How does "reset" work?

Other Hardware 3rd Party Boards
1

Arduino newbie question.

What is the definition of "reset" for Arduinos, i.e., what happens when I a) physically press the restart button, 2) cycle power, 3) upload a new program, 4) send the RESET pin to LOW, 5) invoke one of the several software-based restart methods I've read about?

Does it simply restart the current program (i.e. run start() and then loop() repeatedly), or does it also set I/O pins and other hardware settings (such as analogReference, pullup resistors) to their "default" states? In other words, how much can I assume about the Arduino's current state in the context of my setup() function, or must I explicitly set everything? The Arduino reference has a few warnings in parts which imply it can be dangerous to call certain functions like analogRead() if the board is not configured correctly.

As a corallary: do all the "reset" methods accomplish the same thing -- at least the first 4? Or are there different degrees of "reset"?

I'd have thought this should be obvious but I can't find an authoritative answer anywhere. If I've missed something, please post a link. Thanks!

2

The action of a physical reset of an AVR microcontroller is described in the device's data sheet.
What happens after that depends on which boot loader (if any) you have.
After that, it is down to crt0 (added to your sketch) and the contents of "main.cpp", which adds an "init()" before your "setup()".

3

Read the section "System Control and Reset" in the Atmel Mega328 datasheet.

4

tgherzog:
a) physically press the reset button

You invoke the reset sequence described in the datasheet.

tgherzog:
2) cycle power

You invoke the reset sequence described in the datasheet.

tgherzog:
3) upload a new program

You invoke the reset sequence described in the datasheet. Generally, opening the USB port from the PC causes the USB interface to generate a reset pulse to the Arduino, or else you have to do it manually. At the end of the programming procedure, the bootloader jumps to the start of your program. It is not reset again.

tgherzog:
4) send the RESET pin to LOW

That's what the reset button does.

tgherzog:
5) invoke one of the several software-based restart methods I've read about?

You jump to some point in the code, possibly by generating a watchdog interrupt, which does whatever the watchdog interrupt does.

tgherzog:
Does it simply restart the current program (i.e. run start() and then loop() repeatedly)

That's about the size of it.

tgherzog:
The Arduino reference has a few warnings in parts which imply it can be dangerous to call certain functions like analogRead() if the board is not configured correctly.

Depends what you call "dangerous". analogRead() is a library call, and as I understand it, changes the pin modes to suit what it needs to do.

5
  1. physically press the restart button
  2. upload a new program
  3. send the RESET pin to LOW

Assuming an Uno-like board, with the optiboot bootloader, these three are exactly equivalent; they all "set the reset pin low" (via the auto-reset circuitry for (3)), and then the reset proceeds "as per the datasheet", with the 'reset cause" set to "external reset."
"As per the datasheet" means that a bunch of the internal IO registers get set to their default state (listed in the datasheet), and execution is started at the bootloader start address. The bootloader runs and looks for new upload attempts. If it doesn't see one, it causes a "watchdog reset" (one of the software-based methods.)

  1. cycle power

A power cycle is slightly different. It causes the same internal register defaults, except that the cause will be set to "power up."
Also, a power-cycle will reset the "watchdog running" bit, which is NOT reset by other forms of reset. (This is why you occasionally see instructions for getting an Arduino out of some "bricked" state that involve holding down the reset button while turning on the power; when you finally release the button, the power-on reset will proceed.)
Execution begins at the bootloader again, but the bootloader starts the user sketch immediately instead of looking for new data. (the so-called "Adafruit Fast Start Mod") Also, power-up reset seems to leave most of the CPU registers at 0, whereas external reset leaves them as-was (except for the ones modified by the bootloader.) (This has caused at least one "interesting" bug.)

  1. invoke one of the several software-based restart methods I've read about?

Other than the method that involves causing a watchdog reset, software-reset methods DO NOT set the internal registers to their defaults, so they can be very prone to not working right. Peripherals left running in unexpected modes, interrupts left enabled even though the data necessary for them to work hasn't been initialized, etc. Bad news!
The "turn on the watchdog and wait for it to reset the CPU" ends up causing a real RESET (as per datasheet), with the reason set to "watchdog reset." The bootloader starts, notices the cause, and starts the sketch immediately.

Does it simply restart the current program (i.e. run start() and then loop() repeatedly), or does it also set I/O pins and other hardware settings (such as analogReference, pullup resistors) to their "default" states?

In addition to the reset functions mentioned in the datasheet, the "user sketch" will be started AT THE VERY BEGINNING; well before loop(). First, some standard C/C++ initialization code runs, clearing some memory, initializing the initialized variables (remember that your variables are in RAM, and their initial values have to be in flash somewhere. Code has to exist to move the flash values into ram.) Static C++ objects are constructed by calling their constructor routines.
THEN the C++ program begins a main(), which sets up the chip IO registers and hardware settings as appropriate for the Arduino libraries and environment (for example, it sets up timer0 to cause the periodic interrupt that drives the millis() clock.)
and THEN the code calls setup() where the user code gets to initialize things.
and THEN loop() gets run, over and over again.

6

@westfw, great explanation, thanks very much. I bookmarked it but it deserves better!

7

So if you hit the reset button on an Arduino loaded with BLINK, what happens is:

  1. Hardware "external reset." (see chip datasheet.)
  2. Bootloader starts, initializes serial port and LED13, looks for serial traffic. Times out (about 1s), turns on watchdog.
  3. Watchdog reset. (see chip datasheet)
  4. Bootloader starts again. Notices "watchdog" cause, jumps to "Application section." (note: before touching serial port.)
  5. Application starts. Initializes memory, stack, heaps, static objects. ("C Startup code")
  6. main() runs, calls init(), which initializes the timer and A2D converter hardware.
  7. main() calls setup() (first USER CODE!)
  8. main calls loop(), inside a loop.

I also meant to note that things are probably more complicated on something like a Leonardo, where the bootloader has to run USB (which is MUCH more complicated to run than the serial port.)

8

Paul__B:

tgherzog:
5) invoke one of the several software-based restart methods I've read about?

You jump to some point in the code, possibly by generating a watchdog interrupt, which does whatever the watchdog interrupt does.

Sort of.

The watchdog interrupt gives you a chance to try to recover from whatever's causing the problem. Your watchdog interrupt has to do the right things or the chip will eventually do a full reset.

At startup, the MCUSR shows you why the chip was reset. It can be because of power-on, RESET button, brownout or watchdog. See the "System Control and Reset" section of the datasheet for details.

From personal experience, some bootloaders will crash if the wrong bits are set in MCUSR. This leads to an unusable Arduino until you power it off long enough for MCUSR to go back to zero. I thought my Arduino was bricked the first time this happened to me.

9

westfw:
So if you hit the reset button on an Arduino loaded with BLINK, what happens is:

  1. Hardware "external reset." (see chip datasheet.)
  2. Bootloader starts, initializes serial port and LED13, looks for serial traffic. Times out (about 1s), turns on watchdog.
  3. Watchdog reset. (see chip datasheet)
  4. Bootloader starts again. Notices "watchdog" cause, jumps to "Application section." (note: before touching serial port.)
  5. Application starts. Initializes memory, stack, heaps, static objects. ("C Startup code")
  6. main() runs, calls init(), which initializes the timer and A2D converter hardware.
  7. main() calls setup() (first USER CODE!)
  8. main calls loop(), inside a loop.

I'm not sure about the "watchdog" part of that ... a simple counter will work for the serial port timeout.

(there's lots of different bootloaders though so maybe there's one that does it that way).

10

The watchdog interrupt

The "watchdog" is sneaky. You can configure it so that it causes an interrupt (only), which has certain uses. Or you can configure it so that it causes a RESET. Or you can configure it so that it first causes an interrupt, and then causes a RESET "the next time."

a simple counter will work for the serial port timeout.

The optiboot bootloader uses a 1s watchdog timer to implement the timeout, and a "short" watchdog timer when it knows that it should start the user sketch ASAP (ie immediately after an upload.) This has the advantage of resetting all the peripherals that the bootloader uses (UART and LED13 port), starting the user sketch with the chip in something VERY close to the "reset" state.