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
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
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
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?
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
Hardik Prajapati said: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?
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.
Hardik Prajapati said: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.
Your understanding is correct, apart from the part about single-bank.
Hardik Prajapati said: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.
Like I said above, single-bank is not possible.
Hardik Prajapati said:ii) The DFU module will download the package and store the package, not the bootloader, right?
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.
Hardik Prajapati said: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?
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.
Hardik Prajapati said: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.
Your understanding is correct, apart from the part about single-bank.
Hardik Prajapati said: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.
Like I said above, single-bank is not possible.
Hardik Prajapati said:ii) The DFU module will download the package and store the package, not the bootloader, right?
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.
