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!

[Cecylia]

Hi Vidar,

So the NRF52DK has arrived.  But when I try it, the debugger never stops at main() function.
Steps were:
1) Program using program_bl_sd_bl_settings.bat
2) Build the ble_app_hrs_pca10040_s132 project
3) Ran debugger.

If I pause the debugger, it stops at address 0x15xxx..but showing no source file..
And, the Teraterm at 115200 shows no log at all.  I upload here the screenshot of trying to run the debugger.
Should I use "Debug" or "Release" btw? Although both didn't work as expected for me.

I also made progres with the NRF52840 DK (thanks!) I ran this on the Eval board.  Btw, I'm not actually sure if my board is PreviewDK or just DK, I don't know how to tell them apart.  Here's the project files.
pca10056.zip

It shows some printfs on Teraterm, but it has issue with the Bootloader address so it fails to continue.


After I program with program_bl_sd_bl_settings, 0xFF8 shows the right address.
>nrfjprog --memrd 0xff8 --n 100
0x00000FF8: 00078000 0007E000 20001380 00024B19 |........... .K..|
0x00001008: 0000C005 00024A7F 0000C005 0000C005 |.....J..........|
0x00001018: 0000C005 00000000 00000000 00000000 |................|
0x00001028: 00000000 00024B75 0000C005 00000000 |....uK..........|
0x00001038: 0000C005 0000C005 00024BDD 00024BE3 |.........K...K..|
0x00001048: 0000C005 0000C005 0000C005 0000C005 |................|
0x00001058: 0000C005 |....|

But as I'm running the debugger, when I check again, 0xFF8 and 0xFFC become all F's.
>nrfjprog --memrd 0xff8 --n 100
0x00000FF8: FFFFFFFF FFFFFFFF 20001380 000257B1 |........... .W..|
0x00001008: 0000C069 00025717 0000C069 0000C069 |i....W..i...i...|
0x00001018: 0000C069 00000000 00000000 00000000 |i...............|
0x00001028: 00000000 0002580D 0000C069 00000000 |.....X..i.......|
0x00001038: 0000C069 0000C069 00025875 0002587B |i...i...uX..{X..|
0x00001048: 0000C069 0000C069 0000C069 0000C069 |i...i...i...i...|
0x00001058: 0000C069 |i...|

Please let me know how to proceed.  Thanks

[Vidar Berg]

Hi,

Cecylia said:

So the NRF52DK has arrived.  But when I try it, the debugger never stops at main() function.
Steps were:
1) Program using program_bl_sd_bl_settings.bat
2) Build the ble_app_hrs_pca10040_s132 project
3) Ran debugger.

Please try to do a complete "re-build" and see if it helps. Maybe it's missing the debug symbols. Otherwise, it may be the CRC validation of the app image inside the bootloader that fails, in that case, the bootloader will enter DFU mode instead of booting the app. 

Cecylia said:

If I pause the debugger, it stops at address 0x15xxx..but showing no source file..
And, the Teraterm at 115200 shows no log at all.  I upload here the screenshot of trying to run the debugger.
Should I use "Debug" or "Release" btw? Although both didn't work as expected for me.

0x15xxx is the wait for events loop inside the Softdevice. This is where the program ends up when you call sd_app_evt_wait(). But it's hard to say if it was called from the bootloader or the app. 

I used the RTT backend for logging since the UART is used for DFU (there's only 1 UART on 52832). RTT logs should be shown in the console output in SES. 

The scripts I made assumes that you use the "Debug" target. This target will also enable more verbose error logging, so suggest that you use this target for now. 

Cecylia said:

I also made progres with the NRF52840 DK (thanks!) I ran this on the Eval board.  Btw, I'm not actually sure if my board is PreviewDK or just DK, I don't know how to tell them apart.  Here's the project files.

The white sticker on the interface MCU tells you the version number of the board. Version 1.0.0 and later means that you have a non-preview kit. However, it's more important to know what IC revision you have. You can check the laser markings and look up the build code here: https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nRF52840_ic_revision_overview.html?cp=3_0_3_0. Engineering C and later should be fine.  

I'm almost finished with porting the sample project to nRF52840. The only problem is that the final hash validation fails because the cc310 backend needs the hash message (i.e., application image) to reside in RAM, not FLASH. We have solved this in the bootloader by using an immediate RAM buffer. 

PCA10056 project:

nRF_SDK_15.3.0_background_dfu_2.zip

Cecylia said:

But as I'm running the debugger, when I check again, 0xFF8 and 0xFFC become all F's.

 SES programs the Softdevice along with the application hex, that's why the addresses are being overwritten. A workaround is to disable automatic programming of the Softdevice. Have done that in the attached project.

Edit: Forgot to ask if it's possible to use the cc310 bootloader backend in your existing app? That would fix the problem with hashing. It supports the secp256r1 and secp224r1 curve for ECC, and sha256.

[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!