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.

[Vidar Berg]

Hi,

I've uploaded the project to the other thread. It's configured for the 52832, so some porting will be required to make it run on the 52840 (mainly linker settings). Do you have a nRF52 DK to test with so you can verify that everything works first?

Cecylia said:

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?

I think would be easier to re-use the "dfu" files from the bootloader. This gives you support for FW signing, and you will not have to modify the existing bootloader. The remaining task will then be to create a custom DFU transport to be used by the app. 

[Cecylia]

Hi Vidar, I don't have a DK, and Segger SES is kind of new for me actually (we're mostly using IAR).  I'm ordering one nRF52-DK that will arrive in 2 days.  But in the meantime do you have some pointers on how to try to change the linker settings so I can try it on 52840?

[Vidar Berg]

Hi,

I  think you can use the ble_app_hrs example for PCA10056 as a starting point and add the following files to your  *.ewp file:

<folder Name="nRF_Serial_DFU">
<file file_name="../../../../../../components/libraries/bootloader/serial_dfu/nrf_dfu_serial.c" />
</folder>

<folder Name="nRF_DFU">
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_settings.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/dfu-cc.pb.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_handling_error.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_mbr.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_req_handler.c" />
<file file_name="../../../../../../components/libraries/bootloader/serial_dfu/nrf_dfu_serial_uart.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_transport.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_utils.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_validation.c" />
<file file_name="../../../../../../components/libraries/bootloader/dfu/nrf_dfu_ver_validation.c" />
<file file_name="../../../nrf_dfu_flash.c" />
</folder>
<folder Name="nano-pb">
<file file_name="../../../../../../external/nano-pb/pb_common.c" />
<file file_name="../../../../../../external/nano-pb/pb_decode.c" />
</folder>

Then replace main.c file with the one from the other project. You also need to copy the DFU configuration from the sdk_config.h file. Just let me know if you run into any problems, I can probably help with porting next week if neccessary.