My project is using NCS 2.6.0, builds the _ns variant with TF-M and mcuboot, and targets nRF5340 with an 8MB QSPI flash (it's a custom board, but mirrors the 5340DK in this regard).
For some time now I've operated with a certain partition layout. In this arrangement the SPI flash contains 0xf0000 for app core OTA, 0x40000 for net core OTA, 0x4000 for settings NVS, and 0xa000 for lfs. The remaining 0x6c2000 of the flash is allocated to the external_flash partition. This is the pm_static.yml I'm starting from:
It's confusing that there is a region called external_flash and also a partition called external_flash. I don't recall how this came to be -- most likely is that it was generated this way in build/partitions.yml which I copied when originally creating pm_static.yml. I note that the file v2.6.0/nrf/samples/nrf5340/extxip_smp_svr/pm_static.yml also contains a partition external_flash, but in this sample, their external_flash partition overlaps their mcuboot_primary_2 and mcuboot_secondary_2 partitions. So here's one problem: my understanding of the purpose of the external_flash partition is flawed; I had though it should be covering all of, and exclusively, the unused portion of flash. I deleted this partition in my changes below, but I question whether I should be keeping it and what addresses it should be assigned.
I'd like to add 0x10000 pad between mcuboot_secondary and mcuboot_secondary_1, grow the nonsecure_storage to 0x20000, and allocate the remaining 0x6a0000 of the flash to lfs. I modified the pm_static.yml accordingly: insert secondary_pad, slide mcuboot_secondary_1, adjust the boundaries on nonsecure_storage, slide and adjust settings_storage and littlefs_storage.
Unfortunately this results in an image that doesn't boot. With some mcuboot serial/uart enabled in the serial console I see mcuboot starting repeatedly. Probably my app firmware is starting and something is having a panic during its initialization and causing a reboot but I haven't pursued that.
After quite a bit of iteration I discovered that if I manipulate the nonsecure_storage boundaries to be more similar to those I had originally, then the image boots and appears to run fine. Additionally I've tried erasing the QSPI flash with nrfjprog.exe --qspieraseall just in case there could be data from the prior partitioning that upset some module in my firmware - that didn't help.
Could you help me figure out why adjusting the nonsecure_storage addresses so that they do not properly span settings_storage and littlefs_storage actually results in an image that boots? Also, if you have any insight about whether the partition external_flash should stay or go, that would be appreciated too.
