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

[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

[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