background DFU for sdk 17.0.2

[elva]

Hi.

I'd like to develop my custom board's DFU function like the below steps.

1. Run my application (simple LTE transfer function included)
2. During LTE transferring, If checked the DFU is valid, start downloading the New image file from our server.
3. A new image is downloaded in flash's specific address.
4. Soft reset(ex. NVIC_SystemReset) and enter to Bootloader.
5. Check New image's validation and change the existing image.

I think these steps are according to 'background DFU'. But in SDK 17.0.2, there is no background DFU libraries.

(I referred to this ticket: https://devzone.nordicsemi.com/f/nordic-q-a/61561/difference-between-secure-serial-dfu-and-background-dfu-bootloader)

To summarize the questions,

1. Could I port SDK 16.0.0's background-dfu-bootloader to SDK 17.0.2 and my project?
2. How can I check the Flash's address for the new firmware image package?

[elva]

I want to add some questions.

3. If I use the background DFU, Couldn't I use the package(.zip) file for DFU?

- I understand that the init packet in the Package(zip) file is parsed during the DFU process. So, From what I understand, after the init packet's information is analyzed, the application hex file will be downloaded to the designated address (bank 1).

[Edvin]

Hello,

Could I port SDK 16.0.0's background-dfu-bootloader to SDK 17.0.2 and my project?

Yes. That should be possible. Even 17.1.0, if you prefer.

If you download the nRF5 SDK for Thread and Zigbee, you can see that the bootloader found in nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8\examples\thread\dfu\bootloader\pca10056, you will find a bootloader that does pretty much what you are looking for. The application is transferred during application runtime in the thread example, and the bootloader only verifies it. I know that you are using the nRF52833, and not the nRF52840, but you can use this as a reference. 

How can I check the Flash's address for the new firmware image package?

Let us get back to this.

elva said:

If I use the background DFU, Couldn't I use the package(.zip) file for DFU?

Perhaps not directly using nrfutil or nRF Connect for Mobile. I have not tested this. 

So, I know that several customers have already implemented similar things, although we don't have a finished solution for this. 

As you may know, the default behavior for our BLE bootloader is that the DFU master puts the slave/peripheral in DFU mode, and then transfers the image and performs the DFU.

I believe that when the object is transferred, the call that is triggered is on_cmd_obj_execute_request(), which will validate and execute the new software image. 

I see that this calls "nrf_dfu_validation_init_cmd_execute()", but I suspect that this is the function that actually executes the DFU image. 

As for the init packet, I don't think you need this in the case of a "background bootloader", which is what you are trying to implement. The reason for this is that the init packet is used by the bootloader to verify that the image is actually a valid image before it downloads the entire application. In your case, the application is already downloaded and stored in flash. 

Best regards,

Edvin