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:
Any ideas on how to solve this?
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.
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?
Hi psychogenic.
psychogenic said:When is Simon back from vacation?
Simon will be back next week.
psychogenic said:In the meantime, how does one "define a static nvs_storage partition", ideally without manually setting up and entire pm_static.yml?
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.
psychogenic said:In short, am having the same issue, but the conflict is between NVS and something else (not sure what).
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
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
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