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?

[Amanda Hsieh]

Hi, 

MCUboot may not consider the update valid when the application space reaches a high percentage of memory due to the size of the image. If the image size is too large, it may not fit into the partition, causing MCUboot to reject the update.

Regards,
Amanda H.

[MortenK]

Just to be clear - so the update image is always larger than the hex image? It seems misleading if the build reports no warnings or errors for the increased size.

The merged.hex appears to run just fine.

Does that mean that increasing the size of the secondary image could get around this?

[Amanda Hsieh]

The updated firmware also includes the metadata which would increase the size of the image. See the Output build files (image files).