DFU approach from cloud to ESP32 to nRF52840

[JasonGeo]

Hi,

My setup include a nRF52840-DK board that has an ESP32 WiFi module connected to it via UART. The idea is to source the new firmware from a server located in the cloud.

GCC toolchain,

Running FreeRTOS,

SDK 15.2.0

I am getting really confused after reading all the information on DFU and how I should be doing it. Simon also recently posted an article on DFU using Connect SDK https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu

However, we are not using NCS at the moment.

Questions that I asked myself or still confused about are:

1. Should I be using background DFU or should I be modifying the bootloader to perform the DFU?
2. Where do I get the bin file from? I have a .zip package from the build output. Is that the bin file to use?
3. What is an init packet? Is that the .dat file that comes in the .zip package? How do you trigger the init packet? Via application or bootloader?
4. What is this bootloader settings file?
5. If I am using dual bank update, how do I specify the flash address for the second bank where the updated firmware gets written to?
6. How to let the bootloader knows that there is a new firmware in the second bank for validation and swap over? 
7. What transport should I be looking at? I assume serial - UART?

My initial approach is to write my own in a simplified manner.

The application will issue HTTP GET to the server and retrieve data chunks of the binary until the whole bin file is received. As it receives the chunks, it writes to a flash location.

After the whole bin file is received, the CPU reboots and the application copies the new firmware, overriding the old firmware in place.

Will that "upset" the bootloader when it reboots next time seeing that the firmware signature is different from the one being overwritten?

This is not foolproof as there is no validation and checks for data corruption. It's also not the "proper" way that Nordic perform DFU.

I hope someone can help with those questions and shed some light on the best method to approach this (given my setup, NRF52-ESP32-cloud).

What are the articles that I should focus reading up on. 

[JasonGeo]

Hi Hung,

Do you have some time to go over the questions? 

I've got the build issue sorted out. It has to do with the linking order of the libraries. So don't need to worry about the last part of the ticket.

Would appreciate if you can help with the rest of the queries.

[Hung Bui]

Hi Jason, 

I'm sorry for the late response. It was Easter vacation here in Norway last week. 
Regarding your question, no you don't need to implement any serial opcode. In fact you just need to find a way to receive your image and store it to the correct location (slot 1) and then call the function nrf_dfu_validation_pst_data_execute() just as in the code that I pointed to in previous replies.

The most important part is that you write to the bootloader setting correctly and trigger a reset to get to the bootloader. The bootloader will then swap the image when it read the bootloader setting. 

So it doesn't matter how you receive the image and that you don't have the DFU master on the cloud to send the image chunks the same way as the DFU serial protocol. 

You can read more about the init package here. I would suggest to test with the background DFU example from Vidar that I pointed to as well. 

[JasonGeo]

Happy Easter and thank you for your reply.

Ok, will give what you suggested a try. Am more relief now that I don't really need to follow the protocol but only the steps you mentioned!

Will revert back when I am succesful with the process.

[Bosemani_Raja]

Hai JasonGeo 

 Currently I'm also planning for this implementation.

After reading this discussion I'm bit relief.

Do you have any points or examples?

If you share this will be very helpful!

Best regards

Bose