nRF Connect SDK 1.3.0 multi-image build stuck

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Simon — Tue, 11 Aug 2020 09:26:48 GMT

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

RE: nRF Connect SDK 1.3.0 multi-image build stuck

psychogenic — Thu, 06 Aug 2020 10:25:08 GMT

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

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Didrik Rokhaug — Wed, 05 Aug 2020 08:40:51 GMT

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

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Didrik Rokhaug — Tue, 04 Aug 2020 12:25:45 GMT

Hi psychogenic.

[quote user="psychogenic"]When is Simon back from vacation? [/quote]

Simon will be back next week.

[quote user="psychogenic"]In the meantime, how does one "define a static nvs_storage partition", ideally without manually setting up and entire pm_static.yml?[/quote]

What I did to create the pm_static I posted earlier was to build the application without either NVS or littlefs. I then looked at the generated pm.yml files in the build folders and used those to create the pm_static.yml file. What it ended up with, was me copying the lifflefs_storage partition into the pm.yml file created with only NVS, then adjusting the size and starting positions of the other partitions. As the size of the littlefs_storage partition was 0x6000, I shrank the two mcuboot partitions with 0x3000, then I worked from the beginning of the flash (0x0) to find new start addresses.

[quote user="psychogenic"]In short, am having the same issue, but the conflict is between NVS and something else (not sure what).[/quote]

Could you share your prj.conf (or <your build folder>/zephyr/.config file? That should show what else you have included.

Are you able to build without NVS? How does the pm.yml file look then?

Best regards,

Didrik

RE: nRF Connect SDK 1.3.0 multi-image build stuck

psychogenic — Sun, 02 Aug 2020 00:09:41 GMT

When is Simon back from vacation? In short, am having the same issue, but the conflict is between NVS and something else (not sure what).

In the meantime, how does one "define a static nvs_storage partition", ideally without manually setting up and entire pm_static.yml?

RE: nRF Connect SDK 1.3.0 multi-image build stuck

rerickson — Mon, 27 Jul 2020 16:19:39 GMT

Thanks, I was able to get my custom project to build by just defining a static nvs_storage partition. I have a suspicion that this issue has to do with the PM trying to automatically create littlefs_storage and nvs_storage partitions automatically and them residing at the same spot.

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Didrik Rokhaug — Mon, 27 Jul 2020 14:55:35 GMT

Hi.

Simon is on vacation, so I have taken over this ticket.

Using your sample project, I am able to reproduce the problem.

After adding some debug-prints to the partition manager, it seems like it gets stuck in this loop, not being able to resolve the nvs_storage_partition.

I have not yet been able to find the reason why it gets stuck in the loop, and our partition manager expert is on vacation.

I will continue investigating so that we can find a proper fix.

In the meantime, I have been able to create a static configuration file for the partition manager that places both the nvs_storage and the littlefs_storage partitions: devzone.nordicsemi.com/.../pm_5F00_static.txt(you must change the file ending to .yml, and place it in your project folder)

Note that if you want to re-size any of the partitions, you must calculate new start addresses and sizes for the other partitions.

Best regards,

Didrik

RE: nRF Connect SDK 1.3.0 multi-image build stuck

rerickson — Fri, 24 Jul 2020 15:48:20 GMT

I have found an easy way to reproduce the issue with the nrf52840dk. A simple project is attached. Build it against the nrf52840dk_nrf52840 board. The issue happens when both

CONFIG_FILE_SYSTEM_LITTLEFS=y and CONFIG_NVS=y are used at the same time. If you comment out one of them then the build works just fine.

devzone.nordicsemi.com/.../console.zip

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Simon — Thu, 16 Jul 2020 08:40:43 GMT

Okay, I was too quick to answer. Thanks for the files, I will try to reproduce the problem.

Could you provide the exact steps to reproduce it, where in NCS v1.3.0 should he files be placed, and what commands to run?

Best regards,

Simon

RE: nRF Connect SDK 1.3.0 multi-image build stuck

rerickson — Tue, 14 Jul 2020 15:39:07 GMT

That does work, but I am interested in solving the issue with my project. I have attached my input files that were used for the output above.

devzone.nordicsemi.com/.../pm_5F00_hang.zip

RE: nRF Connect SDK 1.3.0 multi-image build stuck

Simon — Tue, 14 Jul 2020 09:14:36 GMT

Strange, it should work out-of-the-box.

Could you try the following:

Install NCS v1.3.0 using the Toolchain Manager
Add CONFIG_BOOTLOADER_MCUBOOT=y to <..>\ncs\v1.3.0\zephyr\samples\hello_world\prj.conf

Open the bash window from the Toolchain Manager, cd into /ncs/v1.3.0/zephyr/samples/hello_world and build the project:

west build -b nrf52840dk_nrf52840

If that works, you've successfully built and compiled a project with mcuboot as a child image

Best regards,

Simon