MCUBoot erases flash area defined as "custom"

[Albert_0]

Hello all,

I'm hoping you can help me with this problem, hopefully it's just a matter of wrong configuration.

I'm using an NRF52840 (uBlox) and so far everything has worked pretty well. To store some non volatile (NV) variables like the BLE name and serial number of the device, I chose NV memory area 0x85000 to 0x86000 and I'm writing smaller chunks of data each time the serial number and/or BLE name are updated. This doesn't happen very often, and that also works very well.

When I update the firmware using the J-link programmer and the NRF development environment in VS code the custom flash area keeps the values written previously for serial and BLE name. If I do and OTA (BLE) update using the NRF Device Manager App all that information is lost and the tool starts with the default serial and default BLE name. 

The addresses defined in pm_static.yml are:

mcuboot: 0x0 -> 0xC000
mcuboot_pad: 0xC000 -> 0xC200
app: 0xC200 -> 0x84000
mcuboot_primary: 0xC000 -> 0x86000 *
empty_0: 0x84000 -> 0x85000
custom: 0x85000 -> 0x86000
mcuboot_primary_app: 0xC200 -> 0x84000
mcu_boot_secondary: 0x86000 -> 0x100000

* I can see now that there seems to be an overlap between mcuboot_primary and empty + custom, that might be part of the problem

The mcuboot config in the prj.conf file is simply:

# Enable bootloader
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

Is there a better way to configure the memory layout to prevent mcu_boot from erasing my NV data?

Cheers,

Alberto

PS: for reference, YML is shown below:

custom:
  address: 0x85000
  end_address: 0x86000
  region: flash_primary
  size: 0x1000
EMPTY_0:
  address: 0x84000
  end_address: 0x85000
  region: flash_primary
  size: 0x1000
app:
  address: 0xc200
  end_address: 0x84000
  region: flash_primary
  size: 0x77e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x86000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  sharers: 0x1
  size: 0x7a000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x84000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x77e00
  span: *id002
mcuboot_secondary:
  address: 0x86000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x1000
    align_next: 0x1000
  region: flash_primary
  # share_size:
  # - mcuboot_primary
  size: 0x7a000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

[Sigurd Hellesvik]

Hi,

This is a "feature" in the nRF Device Manager app.
Go to "advanced" settings and unselect the "delete storage" when doing OTA.

Does that fix the issue?

That being said, if any of the mcuboot partitions overlay your empty partition, they may at any time overwrite it, so I recommend not having overlap

Regards,
Sigurd Hellesvik

[Albert_0]

Hi Sigurd, thanks for the response.

After writing the question and changing the memory areas removing the overlap now it all works without having to go into the advanced settings.

Two things I noticed (also based on other posts, from other users)

- Both mcuboot areas need to have the same size apparently, otherwise the "new" firmware gets stuck in the "pending" state and it's impossible to get it out of there.

- For the new memory layout to take effect and work, the whole flash needs to be erased, otherwise we get the same issues as before.

For reference, the new layout is:

mcuboot: 0x0 -> 0xC000
mcuboot_pad: 0xC000 -> 0xC200
app: 0xC200 -> 0x84000
mcuboot_primary: 0xC000 -> 0x84000
empty_0: 0x84000 -> 0x85000
custom: 0x85000 -> 0x86000
mcuboot_primary_app: 0xC200 -> 0x84000
mcu_boot_secondary: 0x86000 -> 0xFE000
empty_1: 0xFE000 -> 0x100000

Cheers,

Alberto

[Sigurd Hellesvik]

Albert_0 said:

- Both mcuboot areas need to have the same size apparently, otherwise the "new" firmware gets stuck in the "pending" state and it's impossible to get it out of there.

Yep, this is very important. Changing partition size can cause undefined behaviour.

Albert_0 said:

- For the new memory layout to take effect and work, the whole flash needs to be erased, otherwise we get the same issues as before.

Yes, meaning that you cannot fix partitioning in DFU (with only one bootloader)

And a third point:

- There is a known issue (working to get it on the list), that you cannot use more than 95% of available application space, because MCUboot uses the last ~5% of mcuboo_secondary for stuff

Bonus tip:

Albert_0 said:

For reference, the new layout is:

You can use VS Code -> Memory Layout -> Parititons to view a nice version of the layout.
Or if your prefer the CLI. "west build -t partition_manager_report"