BLE DFU on NRF54L05 using ncs

Hello Team,

We are currently working with the nRF54L05 SoC and are in the process of enabling DFU over BLE. However, after integrating DFU support, we are encountering memory overflow errors.

Upon reviewing related discussions on DevZone, we understand that memory constraints are a common concern. As per the standard DFU memory layout, the architecture typically includes:
MCUboot + 2 × Application + Settings + Storage.

We have the following queries:

1. For the nRF54L05, what is the typical memory architecture used for DFU? Specifically, how much flash is allocated for:

  • MCUboot
  • Each application slot
  • Settings and storage

    Also, what is the maximum available memory we can allocate to a single application?

2. Is it possible to configure DFU with only a single application slot (i.e., remove the secondary slot) to save flash and avoid overflow?

Kindly guide us on how best to configure this setup within the memory limits of the nRF54L05.

 

Parents
  • Hi, 

    1. For the nRF54L05, what is the typical memory architecture used for DFU?

    There are three main parts for DFU: The bootloader, a primary slot and a secondary slot. DFU can only send an image to the application running on a device. Then the application can write that image to flash. But the application can not write to the slot itself runs in, as that would break the application. Therefore, we need a second slot to write the new image to, as such:

    DFU is to send new firmware to a slot in flash. This is often handeled by the application. The bootloader do not need to be involved in the DFU. 

    what is the maximum available memory we can allocate to a single application?

    The nRF Connect SDK variant of MCUboot uses the Partition Manager to configure the flash memory partitions for these image slots. See Partitioning device memory.

    2. Is it possible to configure DFU with only a single application slot (i.e., remove the secondary slot) to save flash and avoid overflow?

    No, because BLE DFU is handled by the application instead of mcuboot. To avoid overflow, you could try to optimize the application, update with external flash or use other nRF chips with larger internal flash. 

    Regards,
    Amanda H.

  • Thanks for the update

    Regarding maximum available memory, considering above mentioned architecture, we need the maximum size that can be configured for the bootloader, primary slot, and secondary slot.

    Note: This is required for NRF54l05

Reply Children
Related