nRF52 DFU over NBIoT network

[mfilipovic]

HI, we want to develop DFU over NBIoT network (UDP), and we would like some advice on how to implement that. We are using nRF52832.

Looking at your SDK examples for BLE and UART DFU, we noticed that there is a defined messaging standard, and only thing user needs to do is implement custom transport layer.

Questions:

1)    How does DFU procedure write new application? Does it split the application memory in half and writes the new application bytes into free section and after checking, just switches memory banks?

2)    If we would download the new application (raw bytes, essentially hex file) into flash and then reset into bootloader, what functions do we use in order to 'manually' write bytes to flash and check CRC at the end, effectively bypassing standard DFU protocol? The reasoning behind this is that we have all communication over NBIoT in our application, and moving things into bootloader would mean duplicating code (modem drivers) and maintaining it in both projects.

 

[Einar Thorsrud]

Hi,

1) The nRF5 SDK DFU Bootloader can be either dual bank (if here is enough free flash space) or single bank (if there is not enough free flash space). It automatically switched between the two for the application, unless dual banking is enforced. It always uses two banks for bootloader and/or SoftDevice updates. Note that the second bank is only used for temporary storage, the new firmware is always copied to the same location as the old after it has been completely received and verified. (Not doing so would require position independent firmware, which is not something we advise against.)

2) Yes, you can adopt the bootloader to be a thin bootloader that only verifies the image and activates it (copies it in place). You probably want to do both the pre-validation and post-validation steps from the normal ensuring both that the firmware is of correct version (increasing), for the correct HW, is intact and verify its authenticity. Then activate it in the bootloader. How much of the validation is done in the application and how much in the bootloader is up to you. You can look at the DFU bootloader implmementation to see how it is done there. You can also refer to the ZigBee bootloader in the Thread and ZigBee SDK for an example of a thin bootloader that does something similar.

[mfilipovic]

Thanks for responding!

I have another question.

If we use dual bank mode, and download into bank 1 and verify the image in application, what do we need to do to tell the bootloader that there is a new image in bank 1?

Does bootloader on boot always check if there is a new image in bank 1?

[Einar Thorsrud]

Hi,

The nRF5 SDK bootloader handles the transfer inside the bootloader, so the bootloader have full control of the process, including where it temporarily stores the new image. The application only needs to signal to the bootloader that its sould enter DFU mode.

It sounds like the question is about a slim bootloader that only verifies and activates the image (from point 2 in your original question). Then you have to implement that yourself, for instance based on some of the other bootloaders we supply, as discussed earlier. I cannot comment in detail on how this will works, since I don't know what you are basing your bootloader on? If you base it on the Thread and ZigBee SDK, then this use a separate flash page for bootloader settings. Then there is a flag indicating weather bank 1 has a update image that is ready or not. This flag should be set by the application, and if this flag is set, the bootloader will try to validate and activate (copy in place) that image.