Using NCS 1.2 SMP_SVR example compiled with custom board DT


I am using NCS 1.2 with Zephyr SMP_SVR example compiling with my own board DTS and using MCUBOOT

I have my own partitions configured in my DTS (attached down at the bottom of this message)

I understood that NCS is using PM (Partition manager and overrides this DTS configuration

In such case as read here:

I should config the desired partitions under the PM.yml of the child (which is the bootloader MCUboot)

I don't that this is the right way to do it - I might be missing something.

Another thing I tried is entering menuconfig of the application (smp_svr) and search PM there, I only got:

Which I don't really understand how to use/configure

Bottom line, I want to understand what is the correct way and how should I configure the flash partitions for bootloader, slot-0 slot-1 scratch and storage to match the muli-build of smp_svr example build with mcuboot

boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0x0000C000>;
slot0_partition: partition@c000 {
label = "image-0";
reg = <0x0000C000 0x000036000>;
slot1_partition: partition@42000 {
label = "image-1";
reg = <0x00042000 0x000036000>;
scratch_partition: partition@78000 {
label = "image-scratch";
reg = <0x00078000 0x00008000>;
storage_partition: partition@80000 {
label = "storage";
reg = <0x00080000 0x00080000>;

  • According to my understanding, they are perfectly aligned, which means there are no gaps that I know of, I am not sure if the syntax of the pm_static.yml is correct

    It was copied from the partitions.yml and changed addresses and sizes only.

    I am not aware of this keywoards:

  • mcuboot:
      address: 0x0
      size: 0xc000
      address: 0xc000
      size: 0x36000
      address: 0x42000
      size: 0x36000
      address: 0x78000
      size: 0x8000
      address: 0x80000
      size: 0x7f000

    I guess that would be the simplest way of representing what you are trying to write. I don't think you can have 0x80000 in your storage partition it seems as you hit 0x100000. Maybe there is a bug in the partition manager that doesn't do a proper check.

    So I guess that's what is failing for you since partition manager is thinking you are going out of bounds of the flash. I would agree that the error message is not telling you what's failing.

    Just an FYI you don't need a scratch partition anymore:

    dit: Tested it and it seems that it doesn't work as expected :/ Seems truncates the space of MCUBoot

  • Dear 

    The below pm_static.yml is compiling ok (I have removed the scratch partition and added that space to the storage), but I have a few follow-up questions

      address: 0x0
      size: 0xc000
      address: 0xc000
      orig_span: &id001
      - mcuboot_pad
      - app
      sharers: 0x1
      size: 0x36000
      span: *id001
      address: 0x42000
      size: 0x36000
      address: 0x78000
      size: 0x88000  


    In the mcuboot_primary section, I must add the "orig_span", "sharers" & "span" sections (or else I get the same error as above), I got them from the partition.yml on my build folder but I don't know their meaning & why are they needed, can you share your thoughts?


    The storage partition seems ok to me as it is exactly filling up space till 0x100000. Anyway, it is not preventing the compilation (i will check the storage partition later on)


    During the build both memory maps are confirming that the partitions for mcuboot and the application are on the right size:

    For MCUBOOT, 48K = 0xC000
    Memory region         Used Size  Region Size  %age Used
               FLASH:       35680 B        48 KB     72.59%
                SRAM:       23764 B       256 KB      9.07%
            IDT_LIST:          56 B         2 KB      2.73%
    For APP, 220672B = 0x35E00
    Memory region         Used Size  Region Size  %age Used
               FLASH:      121848 B     220672 B     55.22%
                SRAM:       26124 B       256 KB      9.97%
            IDT_LIST:         120 B         2 KB      5.86%


    I managed to get a cycle of mcumgr commands and DFU the board using the 2nd partition