An OTA process on nRF52840

RE: An OTA process on nRF52840

Jørgen Holmefjord — Wed, 27 Jan 2021 15:01:06 GMT

[quote user="Hardik Prajapati"]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?[/quote]

The application is running from flash. You cannot erase the currently running application to make room for a new application. The Thread stack needs to be available to maintain communication with the thread network, and receive the new firmware. Single-bank updates is possible in BLE applications, as the softdevice is a separate hex-file, which allows the bootloader to initialize and maintain the BLE connection used to receive the new firmware. There is no similar interface for OpenThread that allows you to separate the stack from the application. Including Thread support into the bootloader would require too much space to be feasible. The Thread DFU client functionality needs to be incorporated into your application to support DFU updates. The bootloader is also required to activate the new firmware.

[quote user="Hardik Prajapati"]

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.

[/quote]

Your understanding is correct, apart from the part about single-bank.

[quote user="Hardik Prajapati"]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.[/quote]

Like I said above, single-bank is not possible.

[quote user="Hardik Prajapati"]ii) The DFU module will download the package and store the package, not the bootloader, right?[/quote]

Correct, the Thread DFU Client libraries are incoporated into your application and allows the download to happen in the background while your application handels other tasks. The bootloader is only used to activate the new image.

RE: An OTA process on nRF52840

Hardik Prajapati — Wed, 27 Jan 2021 06:35:43 GMT

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

RE: An OTA process on nRF52840

Jørgen Holmefjord — Tue, 26 Jan 2021 15:37:23 GMT

Hi,

[quote user="Hardik Prajapati"]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?[/quote]

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.

[quote user="Hardik Prajapati"]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?[/quote]

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.

[quote user="Hardik Prajapati"]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?[/quote]

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

RE: An OTA process on nRF52840

Hardik Prajapati — Mon, 25 Jan 2021 11:53:36 GMT

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

RE: An OTA process on nRF52840

Jørgen Holmefjord — Thu, 21 Jan 2021 10:32:52 GMT

Hi,

Yes, we support DFU over BLE with our BLE Secure DFU Bootloader, and DFU over Thread with our Thread Secure DFU protocol solutions. It is theoretically possible to support DFU over both BLE and Thread protocols using Multiprotocol support, but we do not provide any examples or bootloaders with support for this.
Yes, the Thread Secure DFU protocol allows you to update the end devices/routers over the Thread protocol. The solutions supports background DFU with multicast option, allowing you to update many devices at once, and allow the devices to continue to operate while receiving the update. Note that the current solution does not allow the DFU packets to be transferred over the NCP used in border router configuration simultaneously. Thread DFU can be done over a second NCP device, together with the nrfutil command line tool. If you have two NCP device connected to the border router, you should be able to operate both DFU and border router features concurrently.

Best regards,
Jørgen