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

[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

[Vidar Berg]

Hi Edwin,

I believe you've listed the necessary steps. Just remember to set .bank_current = NRF_DFU_CURRENT_BANK_1 in the settings page before resetting to signal to the bootloader that there's a new image in bank 1.

Vidar

[elange]

Hi Vidar,

I'm working on the integration of SDK v15.3 components into my v15.2 base secure bootloader/dfu project. The newer DFU also depends on updates to the Bootloader and SoftDevice too.

After porting I can compile all the source but get a linker error as the bootloader application has grown beyond the ICF ROM bounds (0x5fff max) set in the .icf file:

define symbol __ICFEDIT_region_ROM_start__ = 0xf8000;
define symbol __ICFEDIT_region_ROM_end__ = 0xfdfff;

My previous bootloader application size was 0x5DA0 so it fit the above range but my new one is 0x6121 and get the following error. Note that I'm using IAR compiler in the project.

Error[Lp011]: section placement failed
unable to allocate space for sections/blocks with a total estimated minimum size of 0x6121 bytes (max align 0x10) in <[0xf'8000-0xf'dfff]> (total uncommitted space 0x5e00).

How do I handle the above?

-Edwin

[Vidar Berg]

Hi Edwin,

As you've seen, the changes made in 15.3.0 led to a slight increase in the memory footprint. Therefore, you will need to optimize your bootloader project to fit into the allocated region, or allocate an additional flash page to the bootloader. However, please note that the ROM_start address of the bootloader cannot be changed through DFU, so this will only work if you are working on the initial FW version.

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.

If you are not going to use the BLE DFU transport in the bootloader as a fallback solution, then you may consider disabling it to reduce the memory usage.

Vidar

[elange]

Hello Vidar,

Thanks for your guidance so far on the background DFU. I have integrated the app side 15.3 files needed to perform the settings write. I have left out nrf_dfu_transport, nrf_dfu_req_handler, nrf_dfu_validation and nrf_dfu_ver_validation and just want to directly mark everything in the s_dfu_settings struct necessary to have my secure bootloader detect, copy and boot the new image. 

I have confirmed that app side DFU is initializing the settings structure ie:

> Calling nrf_dfu_settings_init()...

> Using settings page.

> Copying forbidden parts from backup page.

> Destination settings are identical to source, write not needed. Skipping.

After transporting the init command data I copy to s_dfu_settings.init_command[] and confirm this array contains identical data.

After transporting the new application image to the address given by nrf_dfu_bank1_start_addr() and confirming this exists in flash I then mark s_dfu_settings.bank_current = NRF_DFU_CURRENT_BANK_1.

Finally I’m calling nrf_dfu_settings_write_and_backup() to apply the updates.

So far so good but some questions:

1. What other members of s_dfu_settings need updating in preparation for reboot?

2. Can I simply induce a reset after completing the settings write (ie: sd_nvic_SystemReset()) or is marking the general purpose retention register needed in advance of reset?

-Edwin

[Vidar Berg]

Hi Edwin,

You can see which fields the application is allowed to change in this post:  RE: App-based DFU, changing bank#1 address? . However, I believe it's only .bank_current and .init_command that are required. 

elange said:

2. Can I simply induce a reset after completing the settings write (ie: sd_nvic_SystemReset()) or is marking the general purpose retention register needed in advance of reset?

You only need a reset. When the NRF_DFU_CURRENT_BANK_1 flag is set, the bootloader will enter the postvalidation function which should verify the image uploaded by the application, and then activate it. 

Vidar

[elange]

Thanks Vidar, based on other discussion the parameters in s_dfu_settings.progress needed for post validation after reset are:

• progress.command_size
• progress.command_offset

This in addition to the bank_current setting did the trick. I see new image being rebooted now!