Partition Manager: pm_static + McuMgr + sysbuild

Question

Using connect SDK 3.0.2 and a NRF-DK52840 my goal is fairly simple: My app should be updatable via BLE using a static partition table. I followed this tutorial: nRF Connect SDK hands-on, part 6: Adding FOTA over Bluetooth LE 
 So I added the following to my prj.conf: CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y 
 And to sysbuild.conf I added: SB_CONFIG_PARTITION_MANAGER =y SB_CONFIG_BOOTLOADER_MCUBOOT =y 
 Then defined my pm_static.yml as:

mcuboot:
&#160; address: 0x00000000
&#160; size: 0xC600 &#160; &#160; &#160; &#160; # 48 KB

mcuboot_pad:
&#160; address: 0xC600
&#160; size: 0x200 &#160; &#160; &#160; &#160; # 2 KB

image_0:
&#160; address: 0xC800
&#160; size: 0x40000 &#160; &#160; &#160; &#160;# 256 KB (0x40000 - 0x200)

image_1:
&#160; address: 0x4C800
&#160; size: 0x40000 &#160; &#160; &#160; &#160;# 256 KB

storage:
&#160; address: 0x8C800
&#160; size: 0x40000 &#160; &#160; &#160; &#160; # 256 KB (NVS or misc data)

But when I build my project I get this error: : zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH' c:/ncs/toolchains/0b393f9e1b/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe: region `FLASH' overflowed by 162072 bytes collect2.exe: error: ld returned 1 exit status 
 What did I do wrong? Before adding McuMgr my app was 230520 B in size. 
 I expected that the bootloader fits into "mcuboot" partition and my app into "image_0". It may look like that it tries to fit my app into "mcuboot"? Also: what is mcuboot_pad used for? If I just increase the "mcuboot" to 0xC800 and remove mcuboot_pad I get a strange partition config: Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: Error when inspecting mcuboot_pad, invalid address 0xcc000, expected 0xcc800,
Failed to partition region flash_primary, size of region: 1048576
Partition Configuration:
image_0:
size: 262144
image_1:
size: 262144
littlefs_storage:
placement:
align:
start: 4096
before:
- nvs_storage
size: 24576
mcuboot:
size: 51200
mcuboot_pad:
placement:
align:
start: 4096
before:
- mcuboot_primary_app
size: 512
mcuboot_secondary:
placement:
after:
- mcuboot_primary
align:
start: 4096
size: 77824
nvs_storage:
placement:
before:
- end
size: 24576
storage:
size: 262144

AHaug · Accepted Answer

Hi, Apologies for the wait, thank you for your patience. I see you've been working on initial questions based on the added post scriptum edited section, but I'll go through the questions asked anyways 
 Leschge said: Okey, as I have defined mcuboot_primary and mcuboot_secondary, why does the partition manager add an "app" slot? Can I avoid this? Or better: Can I disable this dynamic partition table entirely to use my own static one? 
 No, you can't add this. Basically what is done is that the app is a container that spans both mcuboot_primary and _secondary as well as paddings. It is not something that "exists" in addition to the previous two partitions. It just contains those mcuboot_primary / _secondary partitions. 
 Your application will always run from mcuboot_primary. The mcuboot_secondary is just to hold a candidate image for when you're doing DFU. 
 Leschge said: 
 'app' is everything but the mcuboot partition 
 I see that this may have been something that was a bit diffuse. What I meant with "'app' is everything but the mcuboot partition" was referring to the MCUboot bootloader, i.e this:

Leschge said: So after more and more hours I think I got it working together with AI and almost understand it fully. AHaug I hope you can help me to get the final piece 
 Of course! I assume that the comments in the partition map is your notes/the findings that you and 'Kapa' (the AI assistant) 
 Leschge said: What is mcuboot_pad used for and why is it part of partition "app" but not also of partition "mcuboot_secondary" ? 
 mcuboot_pad is a small partition placed in between the primary application slot ( mcuboot_primary_app ) and the MCUBoot bootloader partiton. Its main purpose is to reserve space for the MCUboot image header and to ensure that the boot image is linked with the correct address offset in flash. This padding is important for alignment requirements, such as aligning on a flash erase sector boundary. These are necessary to ensure that for instance MCUboot knows where to look for the application (where it starts) and where to place the candidate image and swap it with the running image during DFU. 
 Leschge said: Where does mcuboot hold the active partition in? It is always mcuboot_primary and mcuboot_secondary is just used for swapping or do 
 
 mcuboot_primary and mcuboot_secondary alternate? 
 It is always MCUboot primary unless you build with a configuration that is called " Direct_XIP ". But let's stick with "default" mode first. 
 In default configuration, you build your application for mcuboot_primary. When you do DFU, you upload the candidate image to the mcuboot_secondary partition and MCUboot swap the two images when you trigger a reset after the candidate image has been approved by the bootloader. After the swap, if the image faults or is not validated for some reason, then the bootloader swaps the image back and reboots from your original image. 
 For the Direct_XIP you build a version of your application that is capable of being ran from the secondary partition. In this case it checks the version of the images in the primary and secondary partitions and runs the one with the highest version. 
 Let me know if this validates your understanding/answers your questions 
 Kind regards, Andreas

Partition Manager: pm_static + McuMgr + sysbuild

Top Replies