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.

[Vidar Berg]

Hello,

Is this while loop running in your main() thread? What happens if you don’t call k_sleep(), does the thread run indefinitely performing blocking tasks without ever yielding to other threads? 

 RE: FOTA speed 

Best regards,

Vidar 

[payalD]

Hello Vidar,

Vidar Berg said:

Is this while loop running in your main() thread?

Yes.

Vidar Berg said:

What happens if you don’t call k_sleep(), does the thread run indefinitely performing blocking tasks without ever yielding to other threads? 

We have only a single main thread. If we don't call k_sleep(), other tasks are working fine, but FOTA doesn't work in this case.

[Vidar Berg]

Thanks for confirming.

payalD said:

We have only a single main thread. If we don't call k_sleep(), other tasks are working fine, but FOTA doesn't work in this case.

Is still a multi threaded application. I think my comment in the linked ticket also applies here: "it sounds like your app spends most of its time processing tasks in the main loop, which also means the system isn’t able to spend much time in sleep. Are the tasks in this loop really that compute heavy and need to be blocking, or could the main loop perhaps yield more often?"

[payalD]

Hi,

Vidar Berg said:

Are the tasks in this loop really that compute heavy and need to be blocking, or could the main loop perhaps yield more often?"

The application is non-blocking.

We also tried to test the FOTA in the Bluetooth peripheral sample example, and there also we observed that the FOTA process requires a delay.