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

Are pages from MBR used during SD_MBR_COMMAND_COPY_BL?

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.

Related