nrf54l15: FOTA requires delay

RE: nrf54l15: FOTA requires delay

Vidar Berg — Fri, 18 Jul 2025 13:47:16 GMT

You don't have to use k_sleep() as I mentioned earlier, but you should implement a mechanism to prevent your loop from running unnecessarily. Otherwise, it will waste CPU cycles, prevent the device from entering sleep, and negatively affect system performance as you have experienced.

RE: nrf54l15: FOTA requires delay

payalD — Fri, 18 Jul 2025 13:35:54 GMT

Thanks for the quick reply.

It seems I need to add the delay for FOTA to work successfully. But as I mentioned earlier, this delay is hampering the other functionality. Is there any way that I can identify if the FOTA has been initiated and is in progress so that I can halt the functionality that is getting affected due to this delay during the FOTA activity?

RE: nrf54l15: FOTA requires delay

Vidar Berg — Fri, 18 Jul 2025 12:50:59 GMT

An empty while(1) loop causes the thread to consume 100% of the CPU as long as it's allowed to run by the scheduler. For your app it means it will prevent lower priority threads from running and will block the system from entering the idle or logger thread. Some of this is covered by the devacademy course: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-7-multithreaded-applications/topic/scheduler/

[quote user="payalD"]But if I add the delay of a minimum 200mSec as below, FOTA process gets successfully completed[/quote]

By calling k_msleep(200) you are effectively yielding the main thread and allowing the scheduler to run other threads for at least 200 ms.

RE: nrf54l15: FOTA requires delay

payalD — Fri, 18 Jul 2025 11:52:09 GMT

Hi,

Apologies for the late reply.

Please have a look at code below.

int main(void)
{	
    ble_adv_start();
	while(1)
	{
		//execute_main_apps();
	}
	return 0;
}

This main loop is doing absolutely nothig as I commented the main app execution. When I flash this code on the nrf54l15 board and try to perform FOTA, the process aborts with "Request timed out" error displayed on the app.

But if I add the delay of a minimum 200mSec as below, FOTA process gets successfully completed

int main(void)
{	
    ble_adv_start();
	while(1)
	{
		//execute_main_apps();
		k_sleep(K_MSEC(200));
	}
	return 0;
}

RE: nrf54l15: FOTA requires delay

Vidar Berg — Wed, 16 Jul 2025 15:38:21 GMT

Yes the peripheral sample requires k_sleep() in the main loop because of the way it is implemented (the sleep duration effectively controls the sensor sample rate). Otherwise, it would continuously try to send the notifications and leave little to no time for other threads to execute. However, if you have some kind of "superloop" in your main thread, it would likely be better to look into using zephyr primitives such as semaphores or k_poll() than k_sleep().

RE: nrf54l15: FOTA requires delay

payalD — Wed, 16 Jul 2025 13:55:20 GMT

Hi,

[quote userid="4240" url="~/f/nordic-q-a/123001/nrf54l15-fota-requires-delay/542637"]Are the tasks in this loop really that compute heavy and need to be blocking, or could the main loop perhaps yield more often?"[/quote]

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.

RE: nrf54l15: FOTA requires delay

Vidar Berg — Wed, 16 Jul 2025 12:03:38 GMT

Thanks for confirming.

[quote userid="142658" url="~/f/nordic-q-a/123001/nrf54l15-fota-requires-delay/542636"]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.[/quote]

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?"

RE: nrf54l15: FOTA requires delay

payalD — Wed, 16 Jul 2025 12:00:01 GMT

Hello Vidar,

[quote userid="4240" url="~/f/nordic-q-a/123001/nrf54l15-fota-requires-delay/542633"]Is this while loop running in your main() thread?[/quote]

Yes.

[quote userid="4240" url="~/f/nordic-q-a/123001/nrf54l15-fota-requires-delay/542633"]What happens if you don’t call k_sleep(), does the thread run indefinitely performing blocking tasks without ever yielding to other threads? [/quote]

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.

RE: nrf54l15: FOTA requires delay

Vidar Berg — Wed, 16 Jul 2025 11:52:40 GMT

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

RE: nrf54l15: FOTA requires delay

ryansmith532 — Wed, 16 Jul 2025 10:00:03 GMT

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:

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.
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).
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.