Flash partitioning

[David Ormand]

The MCUboot, Slot0, and Slot1 flash partitions are defined in the board file. E.g., nrf52840dk_nrf52840.dts has boot_partition at 0 with length 0xC000, slot0_partition at 0xC000 with length 0x76000, slot1_partition at 0x82000 with length 0x76000, and storage_partition picking up at 0xF8000, right after Slot1.

In a Sigurd Hellesvik git repo, I learned about partition_manager_report; "west build -t partition_manager_report", which seems to say that Slot 0, for the primary image, is at 0xC000 with a length of 0x7A000 (starting with a 0x200 "pad") and Slot 1, for the secondary image, is at 0x86000 with a length of 0x7A000. It would seem the partition manager is free to allocate flash0 in nrf52840_qiaa.dtsi however it likes. Is the stuff in the DTS just a suggestion? This would seem to conflict with CONFIG_USE_DT_CODE_PARTITION=y in the prj.conf.

If I put stuff like USB in MCUboot and have to grow the partition to fit it by setting CONFIG_PM_PARTITION_SIZE_MCUBOOT, it reworks Slot0 and Slot1 lengths to fit in the 1Mbyte flash.

If I set CONFIG_NVS=y, partition_manager_report now has a nvs_storage block, not starting at 0xF8000 per the DTS file, but actually CONFIG_PM_PARTITION_SIZE_NVS_STORAGE from the end. So we really can't use the DTS macros to determine where a user-defined constant in flash might be.

The application I'm working on currently reserves some memory at the very end, to be loaded with a device serial number via nrfjprog. I'm "reserving" it in a DTS overlay and giving it a symbol that can be recovered with a DT macro. But if partition manager isn't really paying attention to the partition allocations in DT, how would I tell partition manager to reserve the space and not potentially overwrite it with a DFU or some NVS operation?

[Sigurd Hellesvik]

Hi,

Is the stuff in the DTS just a suggestion?

The Partition Manager will override DTS.

CONFIG_USE_DT_CODE_PARTITION

I think we "technically" in the build system use this even with the Partition Manager, we just do it a bit differently.

But if partition manager isn't really paying attention to the partition allocations in DT, how would I tell partition manager to reserve the space and not potentially overwrite it with a DFU or some NVS operation?

See this devacademy lesson for some background.

But to answer what I think you ask for:

DFU only updates mcuboot_primary and mcuboot_secondary, so the rest of your partitions should be unchanged.

Regards,
Sigurd Hellesvik

[David Ormand]

That's correct and i knew that; I shouldn't have mentioned DFU (even if that's my current bugbear).  For a Bluetooth device, for storing bond information in a non-volatile way, NVS is set up, and Partition Manager allocates a chunk of flash all the way to the end.  Maybe I've been lucky, and the bond info is stored at the top of this chunk of flash working down, and it's never gotten to the bit that I've reserved for the serial number.  But I suspect that with repeated bonding/unpairing, that region of flash used for bond info will creep down and eventually overwrite what I had naively thought I had reserved for the serial number.

[Sigurd Hellesvik]

You are talking like you are currently seeing an issue, but I can not see that you mention anything specific.

Do you have an issue now?
Or are you simply trying to think about what could go wrong in the future?

[David Ormand]

I'm trying to anticipate or counter a potential problem.

This project I've got will use NVS as a data storing facility.  It's also a Bluetooth Central, so the bonding info will be saved.  I'm guessing the storage_partition is used for both purposes.  Maybe the bonding info is just NVS records.

I'm also expecting that the flash management method is to mark deleted records rather than actually erasing them, and acquire another flash page as the one currently in use is exhausted.  At some point the management system would search the pages for one consisting entirely of deleted records and erase that page.  But probably not until the end of the memory region was reached.  That is, the end of flash memory.

But if I have critical information written by an external tool like nrfjprog into a known memory location in flash at a point in product manufacture, and eventually NVS creeps up to and overwrites this information, then units are going to be failing in the field some (possibly lengthy) time after starting their service.

I was hoping that I could split off a little partition at the end of flash memory (I guess it would have to at least be a page) for this purpose in the Device Tree, but this won't work if Partition Manager doesn't respect it.

[David Ormand]

You know what, it just dawned on me there is a much better solution.  This is what UICR is intended for.  I should change the approach I implemented in the previous product software version.  It's still a fixed memory location suitable for coding into the nrfjprog script.

Although I think the question is still useful:  How can users assert control over how Partition Manager assigns flash memory?  Can a new partition be introduced in a way that Partition Manager would respect and manage it?