When using an Eclipse based IDE to debug an embedded system, undoubtedly the reader has come across the reset and restart buttons in the debug perspective. From a high-level view, these two options may seem the same but there are important differences on when a developer should use restart over reset. Let’s look at how these are used in a standard application and also when using a bootloader.

First, let’s discuss the basics and possibly the obvious. Pressing the reset button causes the program to reset to the application entry at “power-on reset”. When the reset button is pressed, a developer will find themselves in the processors reset handler. A developer can then step through all the code including the low-level initializations. There is often quite a bit that occurs before an application ever gets to main.

If a developer doesn’t care about what happens before main and simply wants to start the application over and get back to main, they can press the restart button. Restart is a combination operation. The result is the same as if a developer had pressed reset and then play with a break-point located on the first line of main. Restart is sometimes defined as the application from the entry point. (Notice that this is different than the power-on entry point).

Second, reset and restart may seem nearly identical for a developer working with a single application in memory but if a developer has a bootloader AND an application, that is where it gets interesting. During bootloader development, a develop may use debugger commands to directly access the application code space. These commands might be something like the following:

set $sp = *0x280000
set $pc = *0x280004
set {int}0xe000ed08 = 0x280000

These are telling the debugger on start-up to set the stack pointer, program counter and interrupt vector table to a location other than the first location in memory. When these commands are executed, something interesting and useful occurs that developers need to be aware. The reset button still behaves as expected. Pressing it will return to the reset entry-point which will be the bootloader reset vector. However, if a developer presses the restart button, they do not get a reset followed by a run. Instead, they will find themselves in the reset handler for their application code!

Developers who are working in just a single application space will hardly notice any difference between reset and restart. In fact, they will mostly favor restart. A developer working in an environment with a bootloader will still favor restart to debug and work with their application but reset will also provide them a way to enter their bootloader and debug the combined bootloader / application program.