DFU for nRF9160 with max possible image size

Hello, I develop the dfu for my application. I started testing the dfu process with maximum image size that I can build and I need some help here.

Here is my pm_static.yml:

# flash primary:

mcuboot:
  address: 0x0
  end_address: 0x10000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0x10000

mcuboot_primary:
  address: 0x10000
  end_address: 0xe8000
  orig_span: &id001
  - mcuboot_pad
  - app
  - tfm
  region: flash_primary
  size: 0xd8000
  span: *id001

tfm_secure:
  address: 0x10000
  end_address: 0x50000
  orig_span: &id008
  - mcuboot_pad
  - tfm
  region: flash_primary
  size: 0x40000
  span: *id008

mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200

mcuboot_primary_app:
  address: 0x10200
  end_address: 0xe8000
  orig_span: &id002
  - app
  - tfm
  region: flash_primary
  size: 0xd7e00
  span: *id002

tfm:
  address: 0x10200
  end_address: 0x50000
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x3fe00

tfm_nonsecure:
  address: 0x50000
  end_address: 0xe7000
  orig_span: &id007
  - app
  region: flash_primary
  size: 0x97000
  span: *id007

app:
  address: 0x50000
  end_address: 0xe7000
  region: flash_primary
  size: 0x97000

swap_move_region:
  address: 0xe7000
  end_address: 0xe8000
  region: flash_primary
  size: 0x1000

tfm_storage:
  address: 0xe8000
  end_address: 0xfc000
  orig_span: &id009
  - tfm_ps
  - tfm_its
  - tfm_otp_nv_counters
  region: flash_primary
  size: 0x14000
  span: *id009

tfm_its:
  address: 0xe8000
  end_address: 0xea000
  inside:
  - tfm_storage
  placement:
    align:
      start: 0x8000
    before:
    - tfm_otp_nv_counters
  region: flash_primary
  size: 0x2000

EMPTY_2:
  address: 0xea000
  end_address: 0xf0000
  placement:
    after:
    - tfm_its
  region: flash_primary
  size: 0x6000

tfm_otp_nv_counters:
  address: 0xf0000
  end_address: 0xf2000
  inside:
  - tfm_storage
  placement:
    align:
      start: 0x8000
    before:
    - tfm_ps
  region: flash_primary
  size: 0x2000

EMPTY_1:
  address: 0xf2000
  end_address: 0xf8000
  placement:
    after:
    - tfm_otp_nv_counters
  region: flash_primary
  size: 0x6000

tfm_ps:
  address: 0xf8000
  end_address: 0xfc000
  inside:
  - tfm_storage
  placement:
    align:
      start: 0x8000
    before:
    - end
  region: flash_primary
  size: 0x4000

EMPTY_0:
  address: 0xfc000
  end_address: 0x100000
  placement:
    after:
    - tfm_ps
  region: flash_primary
  size: 0x4000


# otp

otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4


# sram primary

mcuboot_sram:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id003
  - tfm_sram
  region: sram_primary
  size: 0x10000
  span: *id003

sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id006
  - tfm_sram
  region: sram_primary
  size: 0x10000
  span: *id006

tfm_sram:
  address: 0x20000000
  end_address: 0x20010000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000

sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id005
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id005

nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x20014568
  orig_span: &id004
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x4568
  span: *id004

nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - tfm_sram
    - start
  region: sram_primary
  size: 0x4e8

nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x20012568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2080

nrf_modem_lib_rx:
  address: 0x20012568
  end_address: 0x20014568
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000

sram_primary:
  address: 0x20014568
  end_address: 0x20040000
  region: sram_primary
  size: 0x2ba98

# external flash:

littlefs_storage:
  address: 0x0
  end_address: 0x4000000
  region: external_flash
  size: 0x4000000

fmfu_storage:
  address: 0x4000000
  end_address: 0x4400000
  region: external_flash
  size: 0x400000

external_flash:
  address: 0x4400000
  end_address: 0x7f29000
  region: external_flash
  size: 0x3B29000

mcuboot_secondary:
  address: 0x7f29000
  end_address: 0x8000000
  region: external_flash
  size: 0xd7000

I had to limit the imgtool max slot size to 4kB less than mcuboot secondary slot size with the following configuration:

CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--slot-size 0xD6000"

Otherwise, the mcuboot says that the image in secondary slot is not valid (too big). 

With such configuration, I can perform dfu for max possible image size that I can build and everything seems to work fine, but the mcuboot prints the following warning:

Non-optimal sector distribution, slot0 has 214 usable sectors (216 assigned) but slot1 has 215 assigned

That suggests the mcuboot secondary slot should be 1 sector lower (4kB) but I don't understand why. If I lower the mcuboot secondary slot by 1 sector, the warning disappears, but I also have to lower the imgtool slot size argument to 0xD5000, to make the dfu pass (which seems to be wasting 1 sector).

So my questions are:
1. Is my pm_static.yml configured okay? Is it the correct way to reserve 1 sector (4kB) for swap using move algorithm?
2. Why mcuboot warns me about non-optimal sector distribution?
3. Is it necessary to limit the imgtool output to 1 memory sector less than the mcuboot secondary slot size?

nRF9160, NCS 2.9.0

Parents Reply
  • In my experience, static partitioning is very often the source of the error. And it is often not required.

    I always recommend using dynamic partitioning, with the two exceptions:

    1. Static partitioning is required for DFU. So for your release, copy build/partitions.yml to pm_static.yml. Then you do not have to calculate sizes manually, but instead just freeze the already dynamically partitioned partitioning. 
    2. To add a custom partition. For this, do not statically partition all the device memory if it can be avoided. Instead, add only the custom partition to pm_static.yml. The dynamic partitioning will then add other partitions "around" (technically just before or after) the custom partition.

    Try to not use static partitioning, and see if your project works then?

Children
No Data
Related