Update application from SD 2.0.1 to SD 4.0.2

[Vladimir Petrigo]

Hello,

I have an application that has to be ported to the newer Softdevice version. I've already ported my application to the SDK 13 and tested it with the new Softdevice v4.0.2.

I found that topic where described the fix for legacy bootloader to be able to accept newer Softdevices.

Now the question is how to perform update to the application based on SDK13 + Softdevice 4.0.2

Steps I did:

1. Update my legacy bootloader build with patched dfu_dual_bank.c
2. Prepare zip package with the custom bootloader + application with SDK 11 + Softdevice v2.0.1 with nrfutil 0.5.3 (1)
3. Upload zip package with custom bootloader via DFU. Here my application works fine after update.
4. Prepare new zip package with the custom bootloader + application with SDK13 + Softdevice v4.0.2 (2)
5. Upload zip package with new Softdevice and application. My device does not work after that

After the final update I am able to validate that new Softdevice has been applied. Here the output of nrfjprog -f nrf52 --memrd 0x0000300C before and after update:

• before update output is 0x0000300C: FFFF0088
• after update output is 0x0000300C: FFFF0098

How zip packages were prepared with nrfutil v0.5.3:

(1): nrfutil dfu genpkg --bootloader custom_bl.hex --softdevice s132_nrf52_2.0.1_softdevice.hex --application app.hex old_full_pack_custom_bl.zip

(2): nrfutil dfu genpkg --bootloader custom_bl.hex --softdevice s132_nrf52_4.0.2_softdevice.hex --application new_app.hex new_full_pack_custom_bl.zip

It is undesirable to move to Secure Bootloader as it is mentioned in several topics here and here that that procedure is not failsafe. Hence it is unacceptable in my case as we have lots of devices in the field that have to be updated with new SD (v4.0.2) + APP.

Could you please provide the safe update steps to perform?

Thank you.

[Bjørn Kvaale]

Is the custom bootloader in step 4 compiled against the v4.0.2 headers?

[Vladimir Petrigo]

Hello Bjørn,

I tried to do so, but met several issues with missed struct definitions and softdevice function declarations during dfu_transport_ble.c and softdevice_handler.c compilation. This files were taken from SDK 11.

Here are some of them that I've noticed:

• ble_gap_whitelist_t type is not defined in the ble_gap.h header anymore

• ble_gap.h does not contain sd_ble_gap_address_get anymore

• ble.h does not contain ble_enable_params_t for softdevice_handler.c

• NRF_LOG_INFO implicit definition - SDK 11 does not have such macro

I've also updated ble_stack_init function in the main.c for legacy bootloader to a newer version provided in nrf_ble_dfu.c in SDK 13.

[Bjørn Kvaale]

Hi Vladimir, talked to a dfu expert here at nordic. His suggestions are the following: firstly, could you provide more information on your procedure in step 5? Then, it would be useful if you did a hex dump. Finally, check if the new application and bootloader are copied to your device (i.e. does the bootloader start or not).

Note that with the current smartphone app, when you try to update the softdevice, application and bootloader, there is no flexible option to only re-upload the application of the softdevice & bootloader update was successful. If you then try to update again via the smartphone, the dfu will fail because the bootloader rejects it because of the version check.