Using flash RAM (not EEPROM) for save data

Development
#1

Continuing the discussion from EEPROM managements:

Any thoughts on this? None of the fuses are set - so programs are allowed to write to program memory… one could imagine buffering a save game to high flash (vs EEPROM). I know there are restrictions on which segments of memory can write which others. Anyone know more about this? Also, when flashing a HEX does the entire 28kb get written each time, or does it only flash up to the size of the actual compiled program?

Obviously the latter would be preferred. If one was actively developing a large game but each time you flashed a new version it erased your “flash save”, then that would have this concept a lot less useful than if it left it alone (so long as the size was small enough).

1 Like
Communicating EEPROM usage / collisions
#2

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.

#3

Update: This is actually super easy to do with bootloader support. (and harder to do without) Gamebuino already has the source for this in their library.