does the Bootloader works after pushing RESET Button only?

Hi everyone,
my question is: since the bootloader waits till a sequence of bytes are available at the virtual serial port (UART),
and its stored at the end of the memory, why do the bootloader code starts running only after pushing the RESET button? or making the RST pin low?, as i know the reset changes the address register in the CPU to 00000 (i think its called CS), and if there is already a code that starts after 00000 , the bootloader will never start, right?.
thanks !

How is this a website and forum question?

I've asked moderators to move it.

I mistakenly posted it in this section, thanks for pointing it out

Read 12.4 of the 328P datasheet, it explains interrupt vectors and how the uC knows where to start processing from after a Reset or other interrupt.

Not sure which Arduino you are asking about, different bootloaders operate differently. The optiboot bootloader used on several of the boards checks the processor flags to see if the board was reset or powered on. If the processor was powered on, the bootloader immediately exits to the sketch code, otherwise it waits several seconds checking the serial input to see if there is an attempt to upload new code.

CrossRoads:
Read 12.4 of the 328P datasheet, it explains interrupt vectors and how the uC knows where to start processing from after a Reset or other interrupt.

i couldn't find this section in the datasheet but i can tell that maybe i understood what you mean, so the bootloader is located somewhere in the memory (usually at the end) its address is stored as a vector in the address 00000h and the reset button (or reset interrupt) executes the interrupt 0*4 which is int0, making a jump to the address where the bootloader is stored, right?

david_2018:
Not sure which Arduino you are asking about, different bootloaders operate differently. The optiboot bootloader used on several of the boards checks the processor flags to see if the board was reset or powered on. If the processor was powered on, the bootloader immediately exits to the sketch code, otherwise it waits several seconds checking the serial input to see if there is an attempt to upload new code.

i was asking about the Arduino Uno,
hmm in that case, the interrupt that /Crossroads talked about will only affect the flags, but due to many resources online the bootloader is located at the end of the memory which means that it will never run to check if the flags got updated or not considering that there is already a code running in a loop before the bootloader.

See page 66.

zakariabsd:
i couldn't find this section in the datasheet but i can tell that maybe i understood what you mean, so the bootloader is located somewhere in the memory (usually at the end) its address is stored as a vector in the address 00000h and the reset button (or reset interrupt) executes the interrupt 0*4 which is int0, making a jump to the address where the bootloader is stored, right?

It's not an interrupt.

One thing that happens is that everything in the processor is set to a default. One of those things is the so-called program counter (PC) which is set to the reset vector.

In case you haven't heard of it, the program counter tells the processor where to fetch the next instruction that needs to be executed.

sterretje:
It's not an interrupt.

One thing that happens is that everything in the processor is set to a default. One of those things is the so-called program counter (PC) which is set to the reset vector.

In case you haven't heard of it, the program counter tells the processor where to fetch the next instruction that needs to be executed.

i know about the program counter, the main question that i posted its about it, i just named it address register, the question was, since you update the PC (program counter) to address 00000h when you press the reset button, how can the PC get to the last 2KB in the memory where the bootloader is located to run it, i mean a jump is needed, and it doesn't run continuously, only after reset , between the reset address (00000h) and the bootloader should be our pre-uploaded code that runs in a loop.
i think that the interrupt is the only solution for this dilemma, and in the address 00000h, a vector of the bootloader's address is stored, and its what update the PC to where the bootloader is located, so that should be an external interrupt, int0

how can the PC get to the last 2KB in the memory where the bootloader is located to run it, i mean a jump is needed

The atmega328 has a fuse setting, BOOTRST, that can move the reset vector from 0000h to the start of the boot section. Also, the boot section is not necessarily the last 2KB, it can be set to 4kB, 2KB, 1KB, or 512 bytes on the atmega328. The UNO uses 512 bytes.

On the UNO, the bootloader is optiboot. The bootloader ALWAYS runs on a reset, before executing any code you have loaded from a sketch. One of the first things the bootloader does is look at the MCU status register to see what caused the processor to start/restart. If the cause was a Power-On anything other than an external reset, the bootloader then executes the sketch code, otherwise it waits a few seconds to see if there is any communications on the serial port. If nothing is received over the serial port within the allotted time interval, the bootloader executes the sketch code.

When you upload a sketch to the UNO, or open the serial monitor in the IDE, the opening of the serial port connection causes the USB to serial adapter (atmega16u2 on a genuine Arduino UNO, FTDI or other chip on most clones) to pull the RESET line of the atmega328 active momentarily, resetting the processor and causing the bootloader to start watching the serial line.

david_2018:
The atmega328 has a fuse setting, BOOTRST, that can move the reset vector from 0000h to the start of the boot section. Also, the boot section is not necessarily the last 2KB, it can be set to 4kB, 2KB, 1KB, or 512 bytes on the atmega328. The UNO uses 512 bytes.

On the UNO, the bootloader is optiboot. The bootloader ALWAYS runs on a reset, before executing any code you have loaded from a sketch. One of the first things the bootloader does is look at the MCU status register to see what caused the processor to start/restart. If the cause was a Power-On anything other than an external reset, the bootloader then executes the sketch code, otherwise it waits a few seconds to see if there is any communications on the serial port. If nothing is received over the serial port within the allotted time interval, the bootloader executes the sketch code.

When you upload a sketch to the UNO, or open the serial monitor in the IDE, the opening of the serial port connection causes the USB to serial adapter (atmega16u2 on a genuine Arduino UNO, FTDI or other chip on most clones) to pull the RESET line of the atmega328 active momentarily, resetting the processor and causing the bootloader to start watching the serial line.

so the bootloader starting can be caused either by a normal booting or a reset, the only difference then will be the status register, to make the bootloader either wait for the bytes sequence from the serial port or skip to the pre-uploaded code, right?

zakariabsd:
so the bootloader starting can be caused either by a normal booting or a reset, the only difference then will be the status register, to make the bootloader either wait for the bytes sequence from the serial port or skip to the pre-uploaded code, right?

The bootloader will always be run at startup, regardless of the cause of the startup - can be either from applying power to the board, pulling the RESET pin low, a watchdog timer reset, or a brownout reset (from an internal detector that shuts the processor down if the power supply drops below a pre-determined voltage, selectable by a fuse setting). The status register only affects the bootloader because the bootloader itself checks the status register as a way of determining what action to take.

thanks everyone for your help!