nRF52 DFU over NBIoT network

RE: nRF52 DFU over NBIoT network

Einar Thorsrud — Wed, 27 Mar 2019 09:39:02 GMT

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.

RE: nRF52 DFU over NBIoT network

mfilipovic — Wed, 27 Mar 2019 07:58:40 GMT

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?

RE: nRF52 DFU over NBIoT network

Einar Thorsrud — Thu, 14 Mar 2019 11:13:41 GMT

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.