DFU image is not updated if it uses a high percentage of application flash.

[MortenK]

Using NCS 2.5.1. nRF52832 being updated using external flash.

We're having an issue with DFU's on a product that is using a high percentage of the application space (~97.5%) of 360kB reserved (0x58000).

Memory layout for primary:

mcuboot_pad:

  address: 0x18000

  end_address: 0x18200

  placement:

    align:

      start: 0x1000

    before:

    - mcuboot_primary_app

  region: flash_primary

  size: 0x200

mcuboot_primary:

  address: 0x18000

  end_address: 0x70000

  orig_span: &id001

  - app

  - mcuboot_pad

  region: flash_primary

             

  size: 0x58000

  span: *id001

mcuboot_primary_app:

  address: 0x18200

  end_address: 0x70000

  orig_span: &id002

  - app

  region: flash_primary

  size: 0x57e00

  span: *id002

Memory layout for secondary:

mcuboot_secondary:

  address: 0x0

  device: DT_CHOSEN(nordic_pm_ext_flash)

  end_address: 0x58000

  placement:

    align:

      start: 0x4

  region: external_flash

  share_size:

  - mcuboot_primary

  size: 0x58000

When programming the resulting code manually via a programmer, the code appears to function. When trying to update the code via DFU, MCUboot does not consider the update valid. Optimizing code size for this to be smaller makes the DFU work once again.

A rough guess would be that the ending signature actually overflows the reserved application space, but we haven't verified this.

The fact that large image sizes successfully build with no errors given seems misleading and has caught us out on a few occasions.

Are we configuring anything incorrectly, or is this a known issue?

[MortenK]

This is actually marked as a known issue in the SDK. It is not obvious how much space is needed for the scratch.

NCSDK-20567: Partitioning limitation with MCUboot swap move

v2.7.0v2.6.2v2.6.1v2.6.0v2.5.3v2.5.2v2.5.1v2.5.0v2.4.4v2.4.3v2.4.2v2.4.1v2.4.0v2.3.0v2.2.0v2.1.4v2.1.3v2.1.2v2.1.1v2.1.0v2.0.2v2.0.1v2.0.0v1.9.2v1.9.1v1.9.0v1.8.0v1.7.1v1.7.0v1.6.1v1.6.0

The swap algorithm in MCUboot (especially the default one - swap_move) requires some extra space to perform the swap move operation, so not entire partition space can be spent for the image. If the incoming image is too large, then the update will be impossible. If the installed image is too large, then undefined behavior might occur.

Workaround: Make sure that the DFU update images are of a specific maximum size. Typically, for the nRF52, nRF53, and nRF91 devices, the size of the application must be less than mcuboot_primary_size - 80 - (mcuboot_primary_size/ 4096) * 12 -4096. Some additional margin is suggested.