Attachments (0)
Nordic Case Info
  • Case ID: 339790
Options

Static partition manager with Mcuboot and Sysbuild

DmytroSes

Hello!
I am developing an application under the SDK V2.9.0. Now I am trying to set up a simple project with a sysbuild, Mcuboot and a partition manager.
Here is the file tree of the project:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
├── CMakeLists.txt
├── drivers
│·· ├── CMakeLists.txt
│·· ├── gpio
│·· │·· ├── CMakeLists.txt
│·· │·· ├── gpio_pi4ioe5v6408
│·· │·· │·· ├── CMakeLists.txt
│·· │·· │·· ├── gpio_pi4ioe5v6408.c
│·· │·· │·· └── Kconfig
│·· │·· └── Kconfig
│·· ├── Kconfig
│·· └── zephyr
│·· └── module.yml
├── dts
│·· └── bindings
│·· └── gpio
│·· └── diodes_pi4ioe5v6408.yaml
├── nrf54l15dk_nrf54l15_cpuapp.overlay
├── pm_static.yml
├── prj.conf
├── README.md
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

sysbuild.conf has the following lines:

Fullscreen
1
2
SB_CONFIG_BOOTLOADER_MCUBOOT=y
SB_CONFIG_PARTITION_MANAGER=y
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

prj.conf has the following lines:

Fullscreen
1
2
3
4
5
6
CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_BACKEND_SHOW_COLOR=y
CONFIG_LOG_INFO_COLOR_GREEN=y
CONFIG_GPIO=y
CONFIG_I2C=y
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

pm_static.yml was copied without any changes from the ncs/v2.9.0/nrf/applications/nrf_desktop/configuration/nrf54l15dk_nrf54l15_cpuapp/pm_static.yml
Here is its content:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
app:
address: 0x7800
region: flash_primary
size: 0xb8800
mcuboot:
address: 0x0
region: flash_primary
size: 0x7000
mcuboot_pad:
address: 0x7000
region: flash_primary
size: 0x800
mcuboot_primary:
address: 0x7000
orig_span: &id001
- app
- mcuboot_pad
region: flash_primary
size: 0xb9000
span: *id001
mcuboot_primary_app:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

When I try compiling the code, I get the following error:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- Found partition manager static configuration : /home/dima/Projects/giot/workspace/pi4ioe5v6408_gpio_expander/pm_static.yml
Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition manager failed: Incorrect amount of gaps found in static configuration. There must be exactly one gap in the static configuration to support placing the dynamic partitions (such as 'app'). Gaps found (2):0x7800-0xc0000 0x17d000-0x165000 The most common solution to this problem is to fill the smallest of these gaps with statically defined partition(s) until there is only one gap left. Alternatively re-order the already defined static partitions so that only one gap remains.
Failed to partition region flash_primary, size of region: 1462272
Partition Configuration:
app:
size: 755712
mcuboot:
size: 28672
mcuboot_pad:
size: 2048
mcuboot_primary:
size: 757760
mcuboot_primary_app:
size: 755712
mcuboot_secondary:
size: 757760
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

What am I doing wrong? I tried it on V2.8.0 as well with the same result.

  • 0

    Hi DmytroSes,

    I can reproduce your issue. The same pm_static.yml seems to work for the nRF Desktop app, but not the setup I created from the Hello World sample.

    I will look into it and follow-up with you early next week.

    Hieu

  • +1

    Hi DmytroSes,

    Thank you for the patience. Sorry I am a little late. I ended up being unexpectedly out of office.

    The problem with the nRF Desktop pm_static.yml turns out to be that it uses the entire RRAM of the nRF54L15. Meanwhile, by default, a portion of the RRAM is reserved for the FLPR core.

    You need to overlay the DeviceTree to give the entire RRAM to cpuapp like done in nRF Desktop: https://github.com/nrfconnect/sdk-nrf/blob/v2.9.0/applications/nrf_desktop/configuration/nrf54l15dk_nrf54l15_cpuapp/app_common.dtsi#L7-L10.

    However, that alone will eventually lead to another build failure. The nRF Desktop application optimizes MCUboot memory footprint and allocates a smaller region for it. You will have to either make the same optimization or adjust the partitioning to give MCUboot more space.

    Hieu

  • 0 in reply to Hieu

    Hi!
    Thanks for the reply. I will try it later and will tell the result.

    It is a bit confusing, that you need to adjust the DeviceTree as well. In the documentation it is said:

    When you build a multi-image application using the Partition Manager, the devicetree source flash partitions are ignored.

    So I thought, you do nothing in DeviceTree, when you use the Partition Manager.

  • 0 in reply to DmytroSes

    Hi DmytroSes,

    You are right. If I have to guess, the reason is that the Partition Manager was made a while ago, before the need to share RRAM between two cores. This need only arose recently with the release of the nRF54L series.

    I will leave a word with our R&D and documentation team to resolve this conflicting information in the next SDK release.

  • 0 in reply to Hieu

    I have checked the files you had provided and was able to successfully compile and run my code. I have adjusted the pm_static.yml and added the following to my overlay file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    &cpuapp_rram {
    reg = < 0x0 DT_SIZE_K(1524) >;
    };
    &cpuapp_sram { //! Without this the only 188Kb of RAM is available
    reg = <0x20000000 DT_SIZE_K(256)>;
    ranges = <0x0 0x20000000 DT_SIZE_K(256)>;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    There is also some amount of RAM reserved for the cpuflpr by default (in the nrf54l15.dtsi). So that should be modified to, if you don't use the co-processor.

Terms of service