Robust FOTA update, and error -11

[Bastien42]

Good afternoon,

I am trying to set up FOTA update over NB-IoT, my device is offline most of the time and connects only a few times a day.

1. What are the gudielines to develop a robust FOTA update implementation ? My current code is based on the Nordic FOTA sample.

2. Here is one error that happened to me, how to make sure it never happens again ?

[00:07:59.947,906] <err> download_client: Error in recv(), errno 11
[00:07:59.955,017] <err> fota_download: Download client error
[00:07:59.961,578] <inf> dfu_target_mcuboot: MCUBoot image upgrade aborted.
[00:07:59.969,177] <inf> dfu_target_mcuboot: MCUBoot image upgrade aborted.
[00:08:00.000,915] <err> nrf_cloud_transport: NRF_CLOUD_FOTA_EVT_ERROR
[00:08:00.008,239] <dbg> cloud_connection: cloud_event_handler: NRF_CLOUD_EVT_FOTA_ERROR
[00:08:00.023,712] <inf> cloud_connection: Reported FOTA failure: 0

Best regards

Bastien

[Simon D-M]

Hi Bastien,

What are the gudielines to develop a robust FOTA update implementation ?

I would like to recommend some articles from the Memfault blog.

• "OTA for IoT: What It Is, How It Works, and Why It Matters" : It is a more general article for OTA. But contains a lot of very useful information on how to make a robust OTA solution.
• "OTA Update Checklist for Embedded Devices in 2025" : This one goes more into detail on what to implement on your firmware and how to push the OTA to the device.
• "How to Test OTA Updates Without Bricking Devices" : And here they are talking about how to safely do test and push the OTA update to your fleet.

If you manage to implement all of these recommendations, you'll probably have one of the best OTA update system that currently exists ;-)

My current code is based on the Nordic FOTA sample.

Which sample are you referring to ? We have multiple FOTA sample for different protocols and Cloud solutions.

Here is one error that happened to me, how to make sure it never happens again ?

You need to add more error handling. Robustness is not achieved by never having any errors, because that is impossible with cellular, you will always have one device which fails to download something somewhere. It is achieved by having a firmware which is capable of handling all the possible errors that can happen during an update.

Here, in your case, it seems like the download failed for some reason. A possible way to handle this is to wait a little bit, and retry updating later. And maybe, if it fails more than a certain number of time, the device can report that he can't proceed with the update.

Best regards,

Simon D-M

[Bastien42]

Thank you for this insightful answer.

I was referring to the nRF Connect SDK Intermediate Exercise 6 Fota over LTE-M/ NB-IoT and I am working with the nRF9160 using MQTT on a custom PCB board.

Regards

Bastien

[Simon D-M]

You're welcome :)

Just FYI, for new design projects, we recommend using the nRF9151 instead of the nRF9160. It is performing better, has a smaller footprint and costs less. Of course, we won't force you to change to this chip. But I just wanted to make sure you knew that this option exists.

Best regards,

Simon D-M

[Bastien42]

Ok, thanks for the information.

Does nRF Cloud implements "Secure OTA Updates with Signing & Hashes" and includes TLS ?

I struggle to see what it is already doing for me.

Best regards

Bastien

[Simon D-M]

Hi Bastien,

Bastien42 said:

Does nRF Cloud implements "Secure OTA Updates with Signing & Hashes" and includes TLS ?

The "Signing & Hashes" are entirely handled by MCUboot.  The process is explained in lesson 9 exercise 2 of our course nRF connect SDK Intermediate.

And, yes, nRF Cloud uses TLS to perform the FOTA update. Here are some relevant documentation about the FOTA performed by nRF Cloud.

Bastien42 said:

I struggle to see what it is already doing for me.

Here is the latest documentation about nRF Cloud.

Best regards,

Simon D-M