nrf54l15: FOTA requires delay

[payalD]

Hello Team,

I am currently using the nRF54L15 DK with NCS version 2.9.0 for development and compiling code for the nRF54L10 board.

I am trying to implement FOTA updates over BLE. To facilitate this, I have added the following lines to my configuration files:

1. In `sysbuild.conf`: `SB_CONFIG_BOOTLOADER_MCUBOOT=y`

2. In `prj.conf`: `CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y`

After compiling the code, the `dfu_application.zip` file is generated, which I use for the FOTA process through the nRF Connect Device Manager app, as instructed in the nRF Connect SDK Intermediate.

I have successfully flashed the v1 application onto the board and am attempting to perform a FOTA using the v2 `dfu_application.zip`. When starting the FOTA through the nRF Connect Device Manager app, the process is getting aborted, resulting in an unsuccessful FOTA. But when I added the continuous delay like

while(1)
{
    k_sleep(K_MSEC(200));
}

FOTA started and completed successfully. My observation is that for the FOTA process, a minimum delay of 200 msec is required.

Can someone please clarify

1. Why is this delay required?

2. Is there any way the FOTA can work without delay? As this delay is hampering other functionalities.

3. If no, is there any way that I can identify in the code that the FOTA has started and is in progress, so that I can stop the functionalities that are getting hampered due to the delay required for FOTA?

Thank you!

[ryansmith532]

I’ve encountered a similar issue with FOTA on nRF devices where the process becomes unreliable unless some timing constraints are respected, especially during Bluetooth activity. horror games

To answer your questions:

1. Why is the delay required?
   BLE-based FOTA relies on stable data transmission intervals. If your main application is heavily using the CPU or interfering with connection events (e.g., high-frequency logging, sensor polling, or interrupts), it might be blocking the SoftDevice or the BLE stack from maintaining the connection properly. The 200ms delay probably gives the stack enough breathing room to handle DFU packets reliably.

2. Can FOTA work without delay?
   In theory, yes — but only if your application is already yielding enough time or prioritizing BLE connection handling. You might want to review how cooperative your threads are and check if the main loop is allowing idle time. Consider using k_sleep() or reviewing Zephyr's thread priorities (especially for the DFU or mcumgr tasks).

3. Can I detect FOTA in progress?
   Yes. You can hook into DFU start/end events using mcumgr callbacks. A common method is to monitor mcumgr_grp_register() with custom handlers or set flags when the DFU image upload begins. Once detected, you can throttle down or pause other time-sensitive tasks temporarily.