Or maybe I’m totally wrong:
While the Application section is used for storing the application code, the The Boot Loader software must be located in the BLS since the SPM instruction can initiate a programming when executing from the BLS only. The SPM instruction can access the entire Flash, including the BLS itself. The protection level for the Boot Loader section can be selected by the Boot Loader Lock bits (Boot Lock bits 1), see Table 27-3 on page 317.
Although this wouldn’t exclude doing it completely - it would just mean you’d have to have support for it built into the bootloader - since the bootloader would be the code that would have to alter the flash. At that point though it might be too complex to be worth it for most uses.
Ok, a bit more reading. It’s really only the SPM instruction that has to be on the bootloader side… so a simple do_spm method like the following:
do_spm:
; check for previous SPM complete
Wait_spm:
in temp1, SPMCSR
sbrc temp1, SPMEN
rjmp Wait_spm
; input: spmcrval determines SPM action
; disable interrupts if enabled, store status
in temp2, SREG
cli
; check that no EEPROM write access is present
Wait_ee:
sbic EECR,EEPE
rjmp Wait_ee
; SPM timed sequence
out SPMCSR, spmcrval
spm
; restore SREG (to enable interrupts if originally enabled)
out SREG, temp2
ret
If that were placed at a fixed location in the bootloader then user land could call it whenever needed to perform SPM operations in the user land. And, suddenly storing things in flash from app space becomes possible.
You have to write flash a whole page at a time… so that means a 256 byte buffer. Although it might be possible to use a smaller buffer and just read in existing data, pass it back into the SPM buffer, then only push the data you changed, then more existing data… so you could do the whole thing with a 1 or 2 byte buffer. I’m not sure if that gets hung up in the RWW vs NRWW area though. I know you can’t read while writing in all areas, but is that talking about the actual “write” SPM command, or the entire sequence of pushing the buffer? If it’s just the write command, that’s fine. If it’s pushing the whole buffer, then you can’t (always) read it while pushing it.
Update: Actually, we’re good. It’s only the top 4kb (max bootloader size) that’s NRWW… and since we’re using the full 4kb, that means ALL the rest of flash is Read-While-Write… so it seems if we could get support for this in the boot-loader it would be pretty easy to wrap it all up in a nice library for user space.