An OTA process on nRF52840

[Hardik Prajapati]

Hello Team,

I am new to the OTA process for nRF52840. Please help me with the below query.

1) Is it possible to perform the OTA over BLE and over thread network as well?

2) I have a setup like a border router(with NCP connected), two other end devices(or routers) working on nRF52840 DK. So is it possible to upgrade my DKs from the border router? considering they all are in the same thread network.

Any help would be highly appreciated.

Thanks,

Hardik

[Hardik Prajapati]

Hi Jorden,

Thanks for the prompt response.

I am more focused on the OTA process over the thread network. I understood that it is possible to upgrade all the end devices/routers at once using the multicast option. I have a couple of queries, please help me with that:

1) You have mentioned that the current solution does not allow to transfer of the DFU packets over the NCP device, what is the reason? The DFU package needs to be transferred once in a while, so is it possible to stop some NCP's services, send packets and restart them again?

2) Once my client device will download the OTA package while the app is running in parallel, then where it will store basically? What if there is no app space available?

3) Once the OTA package is downloaded and stored somewhere then how it will enter in DFU mode in bootloader runtime? I checked that there are 4 options to enter in DFU mode, which one it will use?

Thanks,

Hardik

[Jørgen Holmefjord]

Hi,

Hardik Prajapati said:

1) You have mentioned that the current solution does not allow to transfer of the DFU packets over the NCP device, what is the reason? The DFU package needs to be transferred once in a while, so is it possible to stop some NCP's services, send packets and restart them again?

Bot wpantund (used for border router functionality) and nrfutil (used for DFU features) communicate with the NCP device using Spinel protocol over the serial interface. There is no support in either of these implementation for sharing the serial interface between DFU and border router functionality. If you stop wpantund, you can perform the DFU before restarting wpantund. Note that the DFU process uses CoAP packets, so it is possible to create your own solution in the border router that sends CoAP packets directly to the Thread devices through the NCP, using IPv6 packets. See for instance this post.

Hardik Prajapati said:

2) Once my client device will download the OTA package while the app is running in parallel, then where it will store basically? What if there is no app space available?

Thread DFU requires dual-bank DFU, meaning that the application will be stored in a second slot in flash. This reduces the maximum space available for the application, as the maximum updatable application size will be  flash_size - bootloader_size - current_app_size. The size of the application will be sent in a special init-packet, which allows the device to determine if it has enough available flash before receiving the entire image.

Hardik Prajapati said:

3) Once the OTA package is downloaded and stored somewhere then how it will enter in DFU mode in bootloader runtime? I checked that there are 4 options to enter in DFU mode, which one it will use?

The application will not enter the bootloader in DFU mode. Once the transfer is completed, the application will store the settings of the new image to the bootloader setting page. On the next reset, the bootlaoder will detect a new image in the second slot, and copy this to the first slot, before booting the new application. The bootloader will always run first when the device boots, and start the application when no new updates are available.

Best regards,
Jørgen

[Hardik Prajapati]

Hi Jorgen,

Thanks for the details, it clears many confusions. I wonder about the application size, please clarify that as well.

I have checked the document for OTA update from the below link, the total application area is 972KB only, so what if the current application acquires most of the area and the new firmware app is big in size so no room to fit in the app area. So in this case, a single bank concept will be used where it removes the existing app area in flash and copies the new firmware, right? And this all will be done by the DFU module which is incorporated already in the app running in the background, correct?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fthread_ot_secure_dfu.html&cp=7_3_2_8_2&anchor=thread_ot_secure_dfu_memory

Also, please verify what I have understood from the nordic's documents and from your comments:

1) The DFU module which is running concurrently with an application will download the new firmware in the flash memory(whether using a single bank or dual bank concept).

2) Once it is downloaded, the DFU module will update the bootloader settings that the new firmware is arrived and copied to the location.

3) On the next reset cycle, the bootloader will read the settings first and get to know that the new FW is there.

4) It will read and verify the init packet from the new package, once it is validated, it will boot from the new app.

Based on this process, I have a few more questions:

i) What if the validation failed, it will not be able to recover the old app (in single bank concept). I think then the bootloader will be in DFU mode only where it will expect the correct firmware.

ii) The DFU module will download the package and store the package, not the bootloader, right?

Thanks in advance,

Hardik