I'm trying to track down who is erasing and programming 0x800..0xFFF.
Does the SD_MBR_COMMAND_COPY_BL modify 0x800..0xFFF?
I inserted a CRC32 at the end of the MBR (4K-4), at the end of the SD (0x16000-4), at the end of my application and at the end of the bootloader. The CRC at the end of the MBR was added for completeness.
I'm not sure how I got this far and missed it, but when my bootloader swaps in a new bootloader the last two pages of the MBR are getting erased and some stuff is getting left behind.
Before upgrading the bootloader I have:
0x800: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0xff0: 0xffffffff 0xffffffff 0xffffffff 0x5d9d4f3f <= CRC32(0..4K-4)
Afterwards:
0x800: 0x00000000 0x00016000 0x00002000 0xcdcdcdcd
0xff0: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
As far I can tell this is the result of SD_MBR_COMMAND_COPY_BL. Can someone verify that the bootloader copy command uses 2 pages of the MBR as a scratch space or something?
I don't really need to have a CRC covering 0..4K-4, I mostly did it for completeness. I guess I should not be surprised 0x800..0xFFF is used for something, because it is 0xFF in the softdevice hex and 50% seems like quite a bit of space reserved for future use.