Attached is an excel spreadsheet of the flash memories of my Uno chip along side the generated hex file of the Arduino IDE. I have compared the flash memory of the Uno chip after burning BLINK using my AVR-ISP MKII against the flash memory after uploading BLINK through the optiboot bootloader.
My question now is why is there a difference in the flash memory starting at line 69 of the excel file? I would expect that the memories would be exactly the same apart from the bootloader section.
If anybody can shed some light as to what is going on I would really appreciate it.
(PNG is the worst possible format for the data. Even a text file would be a better choice. I hear Google has something called "Docs". Maybe give that a try.)
The sequence F8 94 FF CF is end of program: CLI, RJMP -2 (jump to itself - end of program). After this, follows some data 0D 00. Each one is the same till this byte. Any other bytes after are useless, normally filled with FF. Using the bootloader, there can be some relict from previously loaded program data, I think.
EDIT: Yes, using the bootloader, there is a relict from previously loaded program data in memory buffer which is not cleared and written to flash. In any case, it is irrelevant piece of code.
I am pretty sure that when doing this experiment I had my AVR settings set to erase flash before loading the bootloader. I have discovered this mismatch on another sketch which I am working on and always the last few memory address don't match. I asked this question using blink as an example, as if you wanted to you could repeat the experiment.
But thanks for our response which I understand as there is nothing for me to worry about. My program is not going to expectantly behave strangely.
The question remains then, why does the bootloader write to more memory then necessary? if you look further after the missed matched lines all other addresses are filled with FF.
This is not related to flash memory erase. The bootloader writes the page of memory at once but it does not clear the buffer after write, so there are some residual data at last write from previous write if the size of program is not exactly aligned to page size. In your case we can see that it is 128 bytes. Look at 8 rows above from the end of marked optiboot data. It ends with ...91 2F B7 (rows started with addresses 3F0 and 470). The sequence of bytes is the same. Everything behind the FF CF 0D 00 is just copy of previously written program data.
The optiboot is designed to be as small as possible. Any buffer cleaning is additional code. Each byte counts and for an example the UNO has boot region 512 bytes. The bootloader has to fit into those 512 bytes otherwise the next size is 1024 bytes.
Anyway, it does not matter what is behind the end of program. Even the last valid instruction should not be normally reachable, because the sketch is infinity loop and it should never reach the end of program which is again infinity loop.
