nRF Connect SDK 1.3.0 multi-image build stuck

[rerickson]

I am switching from standard Zephyr and I am trying out nRF connect SDK v1.3.0. When I am building my app for mcuboot, it hangs after configuring the child image (mcuboot).  If I build mcuboot or the app by itself it works just fine.  It seems like something is hanging in the partition_manager script.  I see a python process spinning in Activity Monitor forever, when I kill it, then the build process fails out.  See my output here:

https://pastebin.com/aif1jjXt

Any ideas on how to solve this?

[Didrik Rokhaug]

Hi rerickson and psychogenic

A pull request with a proposed fix to this issue has just been opened: https://github.com/nrfconnect/sdk-nrf/pull/2673

Best regards,

Didrik

[psychogenic]

Hello Didrik,

Thanks for your answer and the proposed fix.  I have yet to actually burn this to a device and try it out, but I can confirm that the new partition_manager.py does not hang and produces the following settings and finally leads to a successful build.

It isn't exactly like the prior version, and I am wondering how this will impact OTA upgrades for modules on older setups already out in the field...

Here is the produced partitions yml file, with the patched script:

# patched script, nrf version 1.3.99
EMPTY_0:
  address: 0xc000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x4000
app:
  address: 0x1c200
  region: flash_primary
  size: 0x67e00
mcuboot:
  address: 0x0
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  orig_span: &id001
  - mcuboot_pad
  - spm
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x74000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  orig_span: &id002
  - app
  - spm
  region: flash_primary
  size: 0x73e00
  span: *id002
mcuboot_secondary:
  address: 0x84000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x74000
nvs_storage:
  address: 0xf8000
  placement:
    before:
    - settings_storage
  region: flash_primary
  size: 0x6000
otp:
  address: 0xff8108
  region: otp
  size: 0x2f4
settings_storage:
  address: 0xfe000
  placement:
    before:
    - end
  region: flash_primary
  size: 0x2000
spm:
  address: 0x10200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0xc000

The older modules, running on a version of the SDK before it included the nrf/VERSION file (last commit c8fcc56888ab9bb96777fb964e2d2f61c7fc1d0d from March 25, 2020), have a config of

# original partitions from older SDK
EMPTY_0:
  address: 0xc000
  placement:
    before:
    - mcuboot_pad
  size: 0x4000
app:
  address: 0x1c200
  region: flash_primary
  size: 0x6ae00
mcuboot:
  address: 0x0
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  orig_span: &id001
  - spm
  - mcuboot_pad
  - app
  region: flash_primary
  sharers: 0x1
  size: 0x77000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  orig_span: &id002
  - app
  - spm
  region: flash_primary
  size: 0x76e00
  span: *id002
mcuboot_secondary:
  address: 0x87000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x77000
otp:
  address: 0xff8108
  region: otp
  size: 0x2f4
settings_storage:
  address: 0xfe000
  placement:
    after:
    - app
  region: flash_primary
  size: 0x2000
spm:
  address: 0x10200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0xc000

For example, we've always had

CONFIG_SETTINGS=y
CONFIG_NVS=y
CONFIG_SETTINGS_NVS=y

in the prj.conf, but now in addition to the settings_storage there is an entry for nvs_storage... not sure if this impacts anything.  More importantly, perhaps, is that the app sizes are coming out different. 

Will any of these differences impact interoperability between modules provisioned by burning locally (west flash) and jobs to push app_update.bin to older modules out in the world?

Thanks!

Pat Deegan

[Simon]

I looked at your partitions yml files and saw that the start address and size of mcuboot_secondary varied and the size of mcuboot_primary had changed.

This may cause some problems since some of the data regarding validation are stored at the end of the slot, and that may cause some problems if the size has changed. I talked to one of the developers and it is recommended to you to use a static configuration (pm_static.yml) with the exact same values (size and start address) as from the initial partition.yml file (unless it actually needs to be different due to new requirements).

Best regards,

Simon