This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Very simple SPI bootloader

Hi,

I'm implementing a simple bootloader which will not use BLE.

  • Application will transfer the data from mobile devices using BLE and this data will be stored to external SPI flash memory. I've already managed to make writing/reading data over SPI.
  • Custom bootloader should only read and verify data from external SPI flash and write that data to nRF flash. Bootloader should be able to update any address on the chip except itself, meaning that we want this bootloader to be able to update SoftDevice also. After it flashes what it needs to flash, it should go into newly flashed application.

I have trouble understanding vector mapping and how to do it right. Can someone please give an example with a bit more explanation?

Thnx!

  • Yes, that's it!

    • application transfers data to SPI external flash, raises flags, restarts
    • bootloader reads flags and flashes the chip (new SD or new app), clears flags and enters new app

    This means I don't have to use vector mapping, since if I use modified SDK bootloader, MBR will always call bootloader 1st. And after bootloading is done, when I call the stuff you wrote, I will have SD flashed so it will work. And since this is very simple bootloader(KISS principle), it will never need updating of it's own.

    I think I got it now, I'll wait until you confirm this last few sentences. Just one simple question. If size of SD changes it will change CODE_REGION_1_START address, correct? So I guess I should have this address as a variable which I can write/read and not have it hard-coded in the bootloader?

    Thank you very much! This helped me to grasp everything into solution.

  • One more question. When updating SD directly as mentioned above, I should keep MBR intact, correct? Meaning I should skip first 4096 bytes(address 0x0 - 0x1000) when deleting and writing new SD.

    Thank you!

  • CODE_REGION_1_START is hardcoded in an info structure within the softdevice, see dfu_types.h on how the bootloader reads this address. I don't think there is anything wrong with the approach I proposed, but could I could have forgotten some minor details. I would have to implement this to verify that it will work. Unfortunately, I don't have time to do this. I suggest to just start and get more familiar with the bootlaoder and try to implement the changes, and let me know if any problems arise.

  • Yes, the MBR must be kept when doing DFU. Also, just wanted to mention that you can make the standard bootloader use single bank in case you were not aware of it. Just replace dfu_dual_bank.c with dfu_single_bank.c. Assume the reason for using SPI flash is to have enough storage for a larger application?

  • I'm working on a "serial single bank" example, although I don't need banks at all for this case, I simply flash directly from SPI flash to chip flash. Yes, larger application space could be required later.

    Will ping you if I get some kind of a problem, but for now everything is clear.

    Thank you!

Related