Extremely slow and unstable FOTA on nrf5340 based device after code update in app

[nfbe]

Hi,

I am developing a nrf5340 based device (no external memory) using FOTA to update the firmware. This process used to work quite well for a while now, but I ran into trouble recently, because to my surprise the update over the air does not work anymore after a small update to the code (content wise not related to FOTA).

The Update gets stuck on the nrf Connect app on my iPhone at various points early in the process - never finishing successfully. Using my own iOS app I can manage to "force" the update process in an extremely slow speed restarting the process several times, because here, too, the FOTA-process breaks repeatedly at unpredictable times (it took more than an hour to do so). This "new behavior" is the same on several samples of my device - so it does not seem to be a hardware problem.

So: the device and the process still seem to work in principle, but became extremely slow and unreliable. Does anyone have an idea what can cause this behavior on the nrf5340? ... and how I could bring this back to the old quick and reliable update process over the air?

Does the speed and stability in any way depend on the size or other properties of the app_update.bin file, which now is (just a little) larger? What are the limits to the FOTA process with nrf5340 determining speed and stability? Could there be any cause effect relationship between the firmware upload via BLE while the firmware on the device communicates via BLE at the same time?

I am using nrf Connect SDK v2.4.0 (arm64) on the nrf5340 side and an up to date version of nrf Connect on my iPhone.

Thanks a lot for your advice.

Regards,

Jens

[Menon]

Hello,

Could you please try enabling the configuration CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP to expedite the OTA DFU transfer? There's a thread discussing a workaround to enhance OTA DFU speed, although it's Android-centric. Please let me know if this resolves the issue for you.

Kind regards,
Abhijith

[nfbe]

Dear Abhijith,

thank you very much for your reply.

I already have set the CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP to yes. in my project.conf for the app core side. It is also set to yes in the rpms_child_image_overlay.conf on the network core side, which is coming from the otp/nordic/ncs/v2.4.0/nrf/samples/common/mcumgr_bt_ota_dfu/ path.

So, unfortunately, this is not the solution to my problem.

Is it preferable to set a certain (higher) number of connections allowed? I do have contradicting settings for BT_MAX_CONN in the different config files on the network core side - one file sets it to 16, another one to 10 and the third and decisive one sets this parameter to 2. Other than that conflict "imported" from the nordic samples, I do not see any problems in my configuration... and more importantly - I have not changed any of the bluetooth relevant configuration parameters compared to the old version that worked. I did not work terribly fast, but reproducibly at about 3.6 kb/s for a 200kb file - and, rolling back to that version (flashing it on the device and then updating it with one byte for build number changed via FOTA), still works at that speed.

This older version by the way contains the same conflicting settings for BT_MAX_CONN on the network core side - and just works.

The app_update.bin file for the new version is 156 bytes larger than the old one... but does FOTA somehow depend on the content itself?

I would really like to understand, what determines this speed and stability of the nordic FOTA update.

Any hints welcome to reliably solve this problem.

Regards,

Jens