Background DFU application source code

[Cecylia]

Hi there,

We are designing our DFU mechanism for our system that has 4 Nordic 52840.
It's going to be a consumer product, so we don't want the user to have to do 4 manual updates. For this reason, we are thinking to write the new application to the flash ourselves (through Wifi & ESB using our proprietary packets) and utilize the bootloader to check if there's valid application in "Bank 1" and process it if valid. So if the user requests, we will distribute the packets to the flash transparently. Then the user would only need to power cycle the boards and, voila, it's updated.

From reading through the forum, it seems like "Background DFU update" is the way to go. However, in the post such as this one, the links to the documentation seem to be invalid:
devzone.nordicsemi.com/.../163720
devzone.nordicsemi.com/.../background-dfu-update-problem-on-nrf52832
devzone.nordicsemi.com/.../180557

It seems like there are 2 parts we need to modify:
1) The bootloader part, that can be found in:
<InstallFolder>/examples/iot/bootloader
based on info here: infocenter.nordicsemi.com/.../background_dfu_bootloader.html

2) The application part, that does:
Transferring the new firmware to flash memory.
Validating checksum for each block of the firmware.
Triggering a swap procedure by entering the bootloader context.

I don't find where I can find the code for this part. Can you please direct me to the where in the <InstallFolder> it is located?

And, perhaps, if you have documentation that shows how to do background DFU? So that I can try it in the DK first...

Thanks!

[Vidar Berg]

Hi

The install folder is the same as "SDK root", so \nRF5_SDK_15.3.0_59ac345\examples\iot\bootloader. What you need to do is to copy the DFU request handling from the bootloader to the application, then make your own custom ESB/WIFI transport layer for DFU. The transport layer requirements are outlined in the Bootloader documentation here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.3.0/lib_dfu_transport.html?cp=5_0_3_5_2. The same bootloader is also used in our thread/zigbee SDK for background DFU, so may use those as a reference. 

Another relevant thread https://devzone.nordicsemi.com/f/nordic-q-a/46336/bootloader-no-transport-dual-bank-dfu-and-dependencies. 

[Cecylia]

Hi Vidar,

Thanks for your prompt response!

For the app side, porting the bootloader code to "copy the DFU request handling" from the app seems very involved. So, I'm thinking to just manually copy the new FW to the flash chunk by chunk (and do simple CRC check). Will this be enough?

Or, will I also need to update the Bootloader Settings to notify the Bootloader that there's image in Bank 1?

The bootloader that I have in mind is very similar to what you wrote on the other ticket:

1. Checks to see if should enter DFU mode or not (I already have this working via USB)
2. Check if there are any new FW images to activate (could be an image that the app has stored).
3. If dfu_enter == true, initialize transport and wait for DFU master to initiate a DFU
4. if dfu_enter == false, verify CRC of app image and boot the app.

I notice in the other ticket that you will release a sample bootloader that can validate FW in flash. I'll probably wait for that also because I'm not sure how to tell the bootloader that there's a new FW image to activate.

[Cecylia]

Good news,  I could run the 52832 example on the NRF52 DK I recently received.  I had some hiccups with monitoring the logs on JLink 641a, but with JLink 6.40 I could see the LOG much better.

I look at the link you provided and I couldn't match my board.  It seems that my board most likely needs to be replaced to run newer SDK examples.  Please let me know if you can tell which IC revision this is.

I haven't tried cc310 in our existing app.  When you asked "is it possible", do you mean whether the size would fit? Or, are there other consideration?  I'm a bit clueless on this, and from some info I could find, it doesn't seem like we have the need to use it yet.

Thanks,
Cecylia

[Vidar Berg]

Glad to hear that it worked on the 52832. I've fixed the issue with hashing for the 52840 port now, please see attached below (added RAM buffering in cc310_backend_hash.c).

nRF_SDK_15.3.0_background_dfu_3.zip

You have Eng. Rev A on your board, so would strongly recommend that you get a new kit, particularly if you're working with the nRF USB.

Cecylia said:

When you asked "is it possible", do you mean whether the size would fit? Or, are there other consideration?  I'm a bit clueless on this, and from some info I could find, it doesn't seem like we have the need to use it yet.

 The bootloader version of the cc310 backend has a smaller feature set to reduce memory footprint. It only supports the operations I mentioned earlier. So when I asked if "is it possible", I meant if you needed other crypto operations not available in the bootloader backend. 

[Cecylia]

Hi Vidar,  I've got a new 52840 DK board (1.1.0 2019.9), and I could run the example background_dfu_3 you sent.  Thanks so much!

[twittich]

Hello

can i run my application byside the dfu mode in your example?

I tested it already(the 52840 version) and the dfu device is there but where is the entry point so that i can add my app code or for example the blinky code ?

Thanks in advance

twittich

[Satwik]

Hi Vidar,

I have used the example code which you shared (nRF_SDK_15.3.0_background_dfu_3.zip). But after doing the firmware update, after running some time its moving to the following error.