I recently migrated my code from internal flash to QSPI flash and discovered that I cannot write to QSPI flash when running out of QSPI flash. Is there a plan for supporting persistent storage when running out of QSPI flash, this is a bit of a big show-stopper for me. A possible solution would be to write to persistent settings to the end of internal flash beyond the end of the Daisy bootloader if space can be reserved for that purpose but based on the size of the bootloader bin file it doesn’t look like there is much room.
It’s impossible to write to QSPI while executing code from it due to the nature of that peripheral. It uses different modes of operation and they are mutually exclusive. So if you want to execute your code from QSPI, you can’t switch to writing at all.
In order to have a writable QSPI storage, bootloader would have to copy patch to SRAM or SDRAM and execute it from memory. This removes the requirement for executing code from QSPI. Such approach is used to write firmware and patches on OWL, but no idea if Daisy bootloader will end up supporting something like this. Most likely not any time soon.
Using internal flash is not a good solution, because you’d have to erase it before writing, which means that you’d have to erase bootloader too as there’s just 1 sector to use. And libDaisy PersistentStorage class only works with QSPI either way.
1 Like
Note: I only know enough here to be dangerous. 
but… could one make a custom version of the _QSPI.LDS file to store in QSPI flash, but run from SRAM or DTCMRAM, etc.? Then all the code would not be running in QSPI RAM, just stored there at boot. Or is that a function of the Diasy Bootloader and as such, that is why the Bootloader would have to changed?
I ask only because I did create a custom SRAM.LDS file to move around what parts of code were running from what areas of RAM… but again, I only worked through enough of that to solve my specific out of space in the DTCMRAM situation. So, the above is speculation based on only solving my specific issue.
Thanks,
Brett
While you can copy parts of code to .data section (on DTCM or somewhere else), you can’t avoid running part of firmware from QSPI as you need to execute Reset_Handler first. That’s the place where .data contents get copied. So you can’t relocate at least Reset_Handler itself.
If you want to use QSPI only as a storage an not run any firmware code from it at all, you would need a custom bootloader. It would place code to multiple section of memory, but you’d have to describe it for bootloader, because it has to happen before firmware runs and bootloader doesn’t know what you want to do (unlike firmware that can use exports from linker script).