This depends on HOW do you want to "put it" there. If you are going to use some parallel programmer, you need to do whatever that programmer needs. There is no real standard how to "mark" separate memory areas (such as blocks of FLASH, EEPROM, nonvolatile battery-backuped RAM, configuration fuses, and mixture of these in various microcontrollers). It might well be that such records are required as separate files, or in other instance, in a single file mapped to different addresses. You'll need to refer to your programmer's documentation.



It's quite likely that the bootloader does not occupy the whole block1, so you might use that spare space. Is it a bootloader of your own, I mean, do you have full control over it (how much space it occupies)? Also, if you don't use a parallel programmer and program your chip via that bootloader, there might be a risk of destroying the bootloader.


You don't need to do this. Simply put aside two sectors. Keep your settings in one of them, and keep the other erased. When you want to change one setting, simply copy those which don't change into the "empty" sector, and write those which did change, and when you're don, erase the "old" sector. Upon startup or at any moment when you need to read the current settings, it's easy to detect which sector is "empty" and which is "active". (You'll certainly figure out also the details of marking sectors valid/invalid, and recovery from an interrupted reprogramming sequence).




Well, the standard way of doing things is slightly different.

Instead of putting setup into block1, the bootloader in block 1 is written so that it contains "methods" to erase sectors in block 0 and program them. Then, both the application and setup data are sitting in block 0, but the application is able to reprogram "herself" by calling the IAP "methods" in block1.

JW