What happens when uploading via programmer?

What happens when uploading via programmer? Is the boot loader still burned, or is the sketch compiled to run on it's own? What will happen to the unused part of the memory.

Background of the question: I would like to disable brownout detection for energy saving reasons. I don't care so much about erratic behavior in that device, but I fear it might jump to a memory address of the bootloader that writes to flash, destroying the programming.

Uploading via programmer remove the bootloader. Unused memory will be unused - empty. :) But it is behaviour under IDE. In real it can be little more complicated. For an example, you can use directly the avrdude tool from cmd to change fuses without affecting flash memory. Even more, you can write to part of flash without affecting another part.

The question is rather: Will the unused memory contain parts of the older program, may that be the bootloader and may the MCU jump to those addresses as erratic behavior and execute routines that write to flash.

Flash is erased page-by-page on a need-to-write basis - so uploading a smaller program will leave the previous one partially visible in flash. It takes significantly longer to erase the whole memory but I suspect there is an option to zero it.

Eratic code is extremely unlikely to write to any non-volatile memory as the code has to write to certain registers in a given order within a given number of cycles to allow this - its been thought about carefully by the chip designers (ATmega processors I am talking about).

However an exposed older bootloader would contain the right sorts of instruction sequences to program the flash...

@ElCaron No, the chip is completely erased before uploading new program. If the bootloader is used for uploading, the part of memory which contains the bootloader is protected (in Arduino), so only program part is erased. If ISP, it means no bootloader, whole memory is erased.

Compiler automatically adds infinity loop at the end of program (stop program routine) to avoid unwanted program flow behind its margins (in address meaning).

Budvar10: Compiler automatically adds infinity loop at the end of program (stop program routine) to avoid unwanted program flow behind its margins (in address meaning).

Again, to make this clear: I certainly do not fear that my program just runs through. Please assume that my questions make at least a limited amount of sense. This is a very specific concern about erratic behavior due to brown outs, which, as far as I know CAN lead to jumps to arbitrary part of the memory, and, in case that part of the memory belongs to the wrong part of the bootloader, might alter the flash. An infinite loop wouldn't help that at all.

So, now we have two contradicting statements: - MarkT seems to at least sort of agree that part of an old bootloader can remain and case problems and says it can possibly remain. - Budvar10 claims chip is completely erased before uploading new program.

Now fight for the truth :)

Budvar10: Compiler automatically adds infinity loop at the end of program (stop program routine) to avoid unwanted program flow behind its margins (in address meaning).

The compiler does not add anything to the program. The "main" function contains "setup" and "loop" and "loop" is the "infinity loop" that runs code over and over again.

Try programming with int main (void) instead of setup/loop and do a Serial.print. You'll see that the print does not complete because the program "falls off the cliff" before the printing is finished.

Now, try a Serial.print WITH a while(1): at the end and it works fine.

A programming skeleton that does not use the stupid "setup/loop" method is as follows:

int main (void)
{
    init(); // setup Arduino timers, interrupts, etc...
    Serial.begin (115200); // optional

    while (1) {
        //
        // all your code goes here
        //
    }
}

And, if you use the Stdinout library, you can use printf instead of the ridiculous multiple Serial.print calls to build up a print string.

Simple include it in your sketch (or add it to Arduino.h for automatic loading), then connect your device to the standard streams like this:

    Serial.begin (115200); // initialize a serial port
    STDIO.open (Serial); // connect serial port to stdin/stdout/stderr
    printf ("Wow, it works!\n");

krupski:
Try programming with int main (void) instead of setup/loop and do a Serial.print. You’ll see that the print does not complete because the program “falls off the cliff” before the printing is finished.

Wait, I have never programmed an MCU without Arduino. What does “fall off the cliff” mean here? Does it actually progress to some old code that was still in the falsh? Why does that suddenly interrupt the the transfer from the buffer of the hardware UART?

“What happens when uploading via programmer?”
Program loading starts at address 0, and is allowed to go past 7E00 where the bootloaded would normally go.

“Is the boot loader still burned, or is the sketch compiled to run on it’s own?”
No bootloader, sketch runs on its own. uC starts from address 0 after a reset.

“What will happen to the unused part of the memory.”
Nothing is created by the compiler to get loaded there. I can’t connect up a programmer here to show the verbose output from uploading to show what the IDE does.

Here is the file for a blank program,
void setup(){}
void loop(){}
with a bootloader, and without.
With:

:100000000C9434000C9446000C9446000C9446006A << code starts at 0
:100010000C9446000C9446000C9446000C94460048
:bunch of lines deleted for posting
:100190007A0080917A00816080937A0080917A0061
:1001A000806880937A001092C100C0E0D0E0209770
:0C01B000F1F30E940000FBCFF894FFCF99
:107E0000112484B714BE81FFF0D085E080938100F7 << bootloader
:107E100082E08093C00088E18093C10086E0809377
: bunch of lines deleted for posting
:107FD00088E0F5DFFFCF84E1DECF1F93182FE3DFCA
:107FE0001150E9F7F2DF1F91089580E0E8DFEE27F6
:047FF000FF270994CA
:027FFE00040479
:0400000300007E007B
:00000001FF
:100000000C9434000C9446000C9446000C9446006A << code starts at 0
:100010000C9446000C9446000C9446000C94460048
: bunch of lines deleted for posting
:100190007A0080917A00816080937A0080917A0061
:1001A000806880937A001092C100C0E0D0E0209770
:0C01B000F1F30E940000FBCFF894FFCF99
:00000001FF

No bootloader code is included.

“I would like to disable brownout detection for energy saving reasons.”
How does that help?

Nothing is created by the compiler to get loaded there.

That does not mean it is not blanked, does it?

CrossRoads: "I would like to disable brownout detection for energy saving reasons." How does that help?

By saving 25µA, according to Nick Gammon's page.

"That does not mean it is not blanked, does it?"

I can't say what it does. When I can connect up a Programmer and a card, we can check the verbose output of the IDE during "Upload Using Programmer" and see what it does. Lots of stuff goes by as the code is loaded and verified, so it'll be easy to see what addresses are actually touched. I've never had code a sketch corrupted with power being turned on & off with normal brownout detection turned on.

I didn't realize turning off brownout detection saved a little current. I don't run projects off battery normally, so that's not normally a concern.

I didn't realize turning off brownout detection saved a little current. I don't run projects off battery normally, so that's not normally a concern.

I am experimenting with coin cells and aim for a year of run time, so 25uA are MASSIVE :)

Make sure you don't have any floating inputs as well. Inputs with internal pullup resistor, only needs a little current to charge the input gate capacitance, then they just sit high.

Yeah, there is bunch of stuff. The ADC is the biggest chunk. I think Nick has covered it very well.

MarkT: Flash is erased page-by-page on a need-to-write basis...

When uploading through a bootloader.

When uploading with ISP the first command is Chip Erase which sets the entire Flash to 0xFF and clears the Lock Bits. If EESAVE is not enabled the EEPROM is also set to 0xFF.

ElCaron: What happens when uploading via programmer?

Is the boot loader still burned, or is the sketch compiled to run on it's own?

As mentioned by @CrossRoads, whatever you include in the image is uploaded. Normally, only the code and constants of your sketch.

What will happen to the unused part of the memory.

The unwritten parts will have 0xFF.

krupski: The compiler does not add anything to the program.

Of course it does. It adds initialization code that runs before main and shutdown code that runs if main returns.

Try programming with int main (void) instead of setup/loop and do a Serial.print. You'll see that the print does not complete because the program "falls off the cliff" before the printing is finished.

If main returns, halt is called. halt disables interrupts then enters an infinite loop. Serial stops functioning because interrupts are disabled.

krupski: The compiler does not add anything to the program. The "main" function contains "setup" and "loop" and "loop" is the "infinity loop" that runs code over and over again.

As mentioned by Coding Badly: It does. For an example, look to HEX posted by CrossRoads. The end of program is:

:0C01B000F1F30E940000FBCFF894FFCF99

F8 94 CLI ; disable interrupts FF CF RJMP -2 ; jump to itself - infinity loop