ATmega328. Minimum size reserved for boot loader

Hi,

on the 328, can you set the size of the boot loader to 0 or is the minimum 512 bytes?

It is possible to disable the boot section, there are two "lock" bits for that. However, I don't understand exactly how BLB11 and BLB12 should be set to disable the boot section.

To disable the boot section entirely, un-set the BOOT_RST fuse. Without that being set, the size of the boot section is pretty unimportant. (It does still control what code can write flash memory; that can be controlled with the lock bits.) (The bootloader section is special because it has separate protections (BLB bits), and because you can get execution to start there after reset (BOOT_RST) If you set the protections so that it can't do anything special, and have execution start at 0, it's the same has not having a boot section...)

Does File:Upload Using Programmer overwrite the bootload area with the sketch without having to mess with the fuses?

"upload using programmer" doesn't reset the fuses, afaik (there is no boards.txt entry for what the fuses should be in this case!), so it's actually sort-of broken. If you do "upload using programmer" on a chip that has previously had its fuses programmed for use with a bootloader, it will leave the "BOOT_RST" fuse set, and the sketch will start in the wrong place. Usually there won't be anything there, and the execution will just wrap around to the actual start vector at 0x0.

I have a large sketch that is acting weird. The sketch goes in to the space reserved for a boot loader and I had thought this may be causing the problem.

I am using an Arduino as a programmer to program a stand-alone Atmega 328P, no boot loader. BOOTRST is not set, BOOTSZ 1&0 were not set (so boot loader size set at 512 bytes). I added a stand-alone entry to the boards.txt file that has the lock bits as per the Uno entry. I changed the fuse settings but not the lock bit settings.

When BOOTRST is not programmed, does the chip ignore the BOOTSZ fuses or does it still reserve the space? If I am not using a boot loader can I use all memory for a regular sketch? I have read the data sheet but did not see this explained.

If BOOTRST is set to 1 MCU jump to address 0x00000 after reset and it doesn't matter what BOOTSZ are set to. If BOOTRST is 0 MCU jump to address defined by BOOTSZ 0 & 1.

Budvar10: If BOOTRST is set to 1 MCU jump to address 0x00000 after reset and it doesn't matter what BOOTSZ are set to. If BOOTRST is 0 MCU jump to address defined by BOOTSZ 0 & 1.

Does this mean BOOTSZ is only used to determine the address to start running a boot loader and is not used for anything else?

There are also the protection bits. There is a separate set for the code running "in the bootloader section" vs "in the application section." Since one of the settings (used by Arduino, even) is that the application section cannot use LPM on the bootloader section, it is possible (but not very likely?) to have a program that would not work, depending on the BOOTSZ bits, even if it doesn't use BOOTRST.

Does this mean BOOTSZ is only used to determine the address to start running a boot loader and is not used for anything else?

BOOTSZ primary defines a size of bootloader flash section (according the name of those fuses) and boot reset vector address is defined implicitly also, which have to be exactly at the beginning of bootloader section and is not used for anything else.

Thanks for the replies.

The application is not writing to memory but it does contain a lot of data stored in the PROGMEM. Not sure if this can cause issues. I will cut down the size of the code (it is not very efficient at the moment) but would like to find out the reason for the problem just out of curiosity. Will spend some time trying to learn about the lock bits and doing further experimenting.

I have noticed that programming the chip fails in about 1 in 4 / 1 in 5 times. I assumed it was due to the size. Is it possible that I have corrupt code or is the write process verified?

I think that it doesn't matter if you have a lot of data or not in PROGMEM. Everything written to flash memory is the data from the programmer's view. If chip programming process sometimes fails, there is high probability of bad wiring or connection etc. Check this.