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!

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

[Vidar Berg]

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