Issues with settings_storage erased after BLE DFU and inability to assign HEX to a partition using Partition Manager

[Ivenhor]

Hi Nordic team,

We're experiencing two issues related to partition handling in Zephyr/NCS and are looking for your guidance

Issue 1: settings_storage is erased after BLE DFU

We are using BLE DFU and the settings subsystem to persist device parameters.

Everything works fine under normal conditions, but after performing DFU, the parameters are lost.

Example memory dump before DFU:

0x0015F000: FFFF8001 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F010: FFFFFF30 FFFFFFFF FFFFFFFF FFFFFFFF   |0...............|
0x0015F020: 31696473 64612F32 FFFF7264 FFFFFFFF   |sdi12/addr......|
0x0015F030: FFFF8002 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F040: 6870655A FFFF7279 FFFFFFFF FFFFFFFF   |Zephyr..........|
0x0015F050: 6E2F7462 FF656D61 FFFFFFFF FFFFFFFF   |bt/name.........|
0x0015F060: FFFF8003 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F070: B6D816E7 EFED0E58 EA1FE440 A54D2660   |....X...@...`&M.|
0x0015F080: 682F7462 FF687361 FFFFFFFF FFFFFFFF   |bt/hash.........|
0x0015F090: FFFF8004 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F0A0: 00000001 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F0B0: 65756C62 746F6F74 69742F68 756F656D   |bluetooth/timeou|
0x0015F0C0: FFFFFF74 FFFFFFFF FFFFFFFF FFFFFFFF   |t...............|
0x0015F0D0: FFFF8005 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F0E0: 00000000 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F0F0: 65756C62 746F6F74 61702F68 64777373   |bluetooth/passwd|
0x0015F100: FFFF8006 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F110: FFFF0556 FFFFFFFF FFFFFFFF FFFFFFFF   |V...............|
0x0015F120: 612F7462 61657070 636E6172 FFFFFF65   |bt/appearance...|

After DFU:

0x0015F000: FFFF8001 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F010: FFFFFF30 FFFFFFFF FFFFFFFF FFFFFFFF   |0...............|
0x0015F020: 31696473 64612F32 FFFF7264 FFFFFFFF   |sdi12/addr......|
0x0015F030: FFFF8002 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F040: 6870655A FFFF7279 FFFFFFFF FFFFFFFF   |Zephyr..........|
0x0015F050: 6E2F7462 FF656D61 FFFFFFFF FFFFFFFF   |bt/name.........|
0x0015F060: FFFF8003 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F070: B6D816E7 EFED0E58 EA1FE440 A54D2660   |....X...@...`&M.|
0x0015F080: 682F7462 FF687361 FFFFFFFF FFFFFFFF   |bt/hash.........|
0x0015F090: FFFF8004 FFFFFFFF FFFFFFFF FFFFFFFF   |................|
0x0015F0A0: FFFF0556 FFFFFFFF FFFFFFFF FFFFFFFF   |V...............|
0x0015F0B0: 612F7462 61657070 636E6172 FFFFFF65   |bt/appearance...|
0x0015F0C0: 736E6553 6154726F 30305F67 30303030   |SensorTag_000000|

We expected settings_storage to be preserved, as it is located outside the mcuboot_primary and mcuboot_secondary partitions.

Partition Manager report confirms this:

  flash_primary (0x165000 - 1428kB): 
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB)                    |
+---0xc000: mcuboot_primary (0xa5000 - 660kB)-----+
| 0xc000: mcuboot_pad (0x800 - 2kB)               |
+---0xc800: mcuboot_primary_app (0xa5000 - 660kB)-+
| 0xc800: app (0xa4800 - 658kB)                   |
| 0xb1000: mcuboot_secondary (0xa5000 - 660kB)    |
| 0x156000: pad (0x8000 - 32kB)                   |
+---0x15e000: device_data (0x1000 - 4kB)----------+
| 0x15e000: serial (0x80 - 128B)                  |
| 0x15e080: device_data_reserved (0xf80 - 3kB)    |
+-------------------------------------------------+
| 0x15f000: unused_space (0x6000 - 24kB)          |
| 0x15f000: settings_storage (0x2000 - 8kB)       |
+-------------------------------------------------+

  otp (0x4fc - 1kB): 
+-----------------------------+
| 0xffd500: otp (0x4fc - 1kB) |
+-----------------------------+

  sram_primary (0x2f000 - 188kB): 
+--------------------------------------------+
| 0x20000000: sram_primary (0x2f000 - 188kB) |
+--------------------------------------------+

This indicates that settings_storage is located at 0x15f000, well outside the regions that DFU should be erasing.

Yet after DFU, the memory content of settings_storage appears wiped.

Questions:

• Could the BLE DFU process be erasing more flash than intended?

• Is there any MCUboot or Zephyr behavior we might be missing regarding retention of NVS/Settings partitions during DFU?

Issue 2: Assigning HEX to a partition using Partition Manager does not work

We want to assign a pre-generated serial.hex file to a custom serial partition via Partition Manager, as described in the Partition Manager documentation.

Our goal is to embed a serial number at build time into a small flash partition:

Partition:

serial:
  address: 0x15e000
  size: 0x80
  region: flash_primary

CMake snippet:

set_property(GLOBAL PROPERTY serial_PM_HEX_FILE ${CMAKE_CURRENT_SOURCE_DIR}/tools/serial.hex)

However, serial.hex is not included in the final merged.hex file. We verified that the file exists and contains the expected content at the correct offset.

Questions:

• Have we understood the purpose of this mechanism correctly?

• Are there any specific requirements that must be followed?

[Amanda Hsieh]

Hi, 

Is there any MCUboot or Zephyr behavior we might be missing regarding retention of NVS/Settings partitions during DFU?

If you are using the Android version of "nrf connect," there is the options : settings->Mcu Manager options->Erase application setting

For iOS, see this post. 

Have we understood the purpose of this mechanism correctly?

That's correct.

Are there any specific requirements that must be followed?

You can check:

• There are no typos in the property name (it must match the partition name and end with _PM_HEX_FILE).
• The HEX file is valid and at the correct address.
• If you are using sysbuild, try to set it in the sysbuild.cmake under your application.

Regards,
Amanda H.