Daisy seed bootloader

Hi all,

I use the seed bootloader to run my program in the SRAM and would like to augment it with the ability to flash a new version at runtime. Are there the bootloader sources available? If not, can I at least get details on the format stored in QSPI when a new firmware is flashed?

Thank you!
Adrian

Hello!

The storage format is very simple – it’s just the raw program binary, stored at address 0x90040000. The QSPI address space starts at 0x90000000, so there’s just a bit of space at the beginning in case you want to store anything there.

There’s a couple ways you could add runtime programming. You could just do it manually by erasing the QSPI at 0x90040000 for however much you want to program and then writing your data. This would be the best approach if you’re updating over MIDI or something like that.

Alternatively, you could return to the bootloader from within your program. I have a pull request up that lets you return to the Daisy bootloader (not just the system one), and you could let it handle any flash attempts. This would work best if you insert some media (like an SD card) with a new binary on it, or you need it to work with DFU.

Isn’t there metadata kept anywhere? I would expect at least the filesize and checksum to be stored somewhere. Can you detail on that?

For most applications, that metadata is largely unnecessary. The DFU transaction itself enforces a CRC, so you can be reasonably confident in the integrity of the transferred data. And, since the bootloader only currently supports a single program, the file size is not stored. These are features that will likely be supported in the future, but were not critical for an initial implementation.

No additional information is needed to execute the binary, however. The entry point and stack pointer are in fixed locations near the beginning, so any calling program can set up the new one correctly.

1 Like

Thank you @Corvus_Prudens,

This leads me to think that versioning apps is not a thing yet and that the bootloader simply copies the amount of RAM from QSPI before setting the vector table and jumping to it. Correct?