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,

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.