Booting an application image without using DFU to transport

[elange]

Hello Nordic Semi,

My Platform: nRF52840 + S140 SoftDevice + Secure Bootloader, SDK base v15.2 

I am working on a project requiring to transport application images to flash without using of the well established DFU/Mobile method. Images are transported via BLE connection during application runtime and written to flash using customized means. Assuming the whole application image is transported and written to free flash space, I need to then prepare the system to boot and run the new image. This requires some coordination with the bootloader settings configuration by the running application before restart.

Question: What are the specific steps necessary to inform/configure the bootloader to boot the newly written image?

- Edwin

[elange]

Hello Sigurd,

Thanks for pointing me to the Background DFU example! This contains much of what I am attempting to do. In my case, rather than using TFTP to transport the image, I am using a virtual serial port to transport the app update over BLE (similar to Nordic's NUS). This method is working and image data is getting written to flash and matching the binary code. I also have means to send Json formatted information so could use this to transport meta-data for validation checks where needed.

So in terms of order it looks like I need to:

1. Rebuild my bootloader with NRF_DUF_SETTINGS_IN_APP = 1 to allow app to write settings otherwise restricted
2. Send init packet data (including signing info)
3. Send app image data (already working)
4. Perform post-validation
5. Update settings records in upper flash
6. Reboot to let Secure bootloader do the rest (assuming the above when to plan)

I'll attempt to port the parts I need from tftp_dfu.c and background_dfu_*.c source to achieve the above.

Am I getting this right?

[elange]

Update: for step 1 above. Based on the background DFU example I should set:

NRF_DFU_SETTINGS_ALLOW_UPDATE_FROM_APP = 1

NRF_DFU_SETTINGS_IN_APP = 1

[Sigurd]

Hi!

elange said:

Am I getting this right?

I checked with Vidar. You don't need to look at the IOT background DFU example, since we actually have what is needed in the standard version. You are on the right track, the important thing is to save the image to the correct bank 1 address, and update the fields in the BL settings.

[elange]

Vidar,

I've added the DFU and Crypto source components from my secure bootloader to my application project to get started and now ready to process the init packet. My build system is using nrfutil to generate the DFU package (.bin and .dat) and also the settings.hex files.

Next step I think is to send the init packet data first and pass to DFU to validate. I'm assuming the data sitting in the .dat file from the nrfutil package contains this.

Somehow I need to kick DFU validation into action (bypassing transport) so a bit of guidance would help.

I notice the nrf_dfu_settings_t holds the init_command[512] array. Does the .dat data simply get copied into this array and processed with stored_init_cmd_decode()?

-Edwin

[Vidar Berg]

Edwin,

There were some improvements and bug fixes made to the background DFU support in nRF5 SDK v.15.3.0. Therefore, I recommend updating to v15.3.0 if possible.

From the SDK 15.3.0 release notes:

** DFU **

- Various security improvements and fixes.
- Fixed various bugs in background DFU.
- Fixed bugs that appeared when combining transports (for example, UART + BLE).

The main change was that updates staged by the application would be validated by the bootloader before activation. With this modification, it's not strictly necessary for the application to validate the update since the bootloader will handle it.

The postvalidation() function shown below from v15.3.0 uses the init command stored to the settings page by the application to verify the update before activating it (i.e., copying the image from bank 1 to bank 0).

Relevant DevZone post:  RE: App-based DFU, changing bank#1 address?  

Best regards,

Vidar

[elange]

Thanks Vidar,

Things are getting clearer now on the approach. I will use the newer DFU to take advantage of the bootloader side validation. ie: 

• Application integrates v15.3 DFU source with NRF_DFU_IN_APP = 1
• Secure Bootloader integrates the same with NRF_BL_DFU_ALLOW_UPDATE_FROM_APP = 1

Runtime application then does the following:

• receive .dat info (via our own transport method)
• copy in the .dat to s_dfu_settings and write to flash with nrf_dfu_settings_write()
• call nrf_dfu_bank1_start_addr() to determine where to write incoming app image
• receive app image and write to flash starting at address from call above
• induce a reset

Since the Application's DFU instance is not validating, it seems we do not need to include all the Crypto source used by nrf_dfu_validation.c nor the transport stuff in nrf_dfu_transport.c as we have our own. 

I'll give the above a try. Any feedback is most welcome!

-Edwin