This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU OTA Bootloader with bonding info SDK 14.2.0 fails

Hi,

We are having problems trying to integrate support for maintaining application context and bonding info across firmware OTA updates on our NRF52 (nRF52832) based board.

The problem is that we can't find a working combination of bootloader and application firmware to flash to our boards. I've basically tried with the SDK examples (dfu/bootloader_secure_ble and ble_app_buttonless_dfu) first unedited and later with some slight edits to them to better support our board's configuration. But the problem remains.

First, I tried flashing the firmwares using a JLink programmer (not OTA). Using nRFGo Studio I erased everything on the nRF52, flashed the latest SD (5.1.0), then flashed the example hex for the bootloader provided pre-built in the SDK (examples\dfu\secure_dfu_test_images\ble\nrf52832\bootloader_secure_ble_debug_with_bonds_s132.hex). Up to this point, the board can't boot properly/ the bootloader is not able to take-over (since there is no valid app) and advertise itself. The device won't work. Is this expected behavior? It seems that the bootloader enters ble_dfu_transport_init() in nrf_dfu_ble.c but the (nrf_dfu_settings_peer_data_is_valid()) fails and the method returns NRF_ERROR_INTERNAL.

I then (on the above configuration) flashed the application pre-built firmware too (examples\dfu\secure_dfu_test_images\ble\nrf52832\ble_app_buttonless_dfu_with_bonds_s132_with_setting_page.hex). This time the board boots ok; the application is launched and the board advertises itself. But why wasn't the bootloader able to launch itself when it was supposed to work as standalone?

Next, I tried doing a similar process OTA. I started with a working device which had SD 3.1.0, a bootloader and a buttonless dfu application. I built (with Keil) the dfu SDK 14.2 example (\examples\dfu\bootloader_secure_ble), setting

#define NRF_DFU_BLE_REQUIRES_BONDS 1

in SDK_config.h . I also kept the line:

#define DFU_APP_DATA_RESERVED CODE_PAGE_SIZE * 3

I created a package with the latest (cloned from github) pc-nrfutils (with python 2.7.11) like so:

nrfutil pkg generate --hw-version 52 --hw-version 52 --sd-req 0x91 --softdevice s132_nrf52_5.1.0_softdevice.hex --bootloader-version 3 --bootloader BLReqBonds.hex --key-file private.pem SD_BL_Package.zip

The OTA completes, but the device won't advertise itself (DfuTarg). It seems that the bootloader goes in nrf_dfu_utils.c and returns false at the nrf_dfu_app_is_valid() crc check: ((crc != s_dfu_settings.bank_0.image_crc)).

I also built the buttonless dfu application in SDK 14.2, setting

#define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 1

in its SDK_config.h. I created a package with SD+Bootloader+app like so:

nrfutil pkg generate --hw-version 52 --hw-version 52 --sd-req 0x91 --softdevice s132_nrf52_5.1.0_softdevice.hex --bootloader-version 3 --bootloader BLReqBonds.hex --sd-id 0xA5 --application-version 3 --application appSupportsBonds.hex --key-file private.pem SD_BL_APP_Package.zip

but this seems to have the same issue, since the OTA update should happen in two steps (first SD+bootloader, then the app), but the second step can't launch because after the first step completes the bootloader can't enter DFU mode to continue to the next step.

Another thing I tested was to send an OTA update with SD, bootloader (without bonds required), and an buttonless dfu app supporting bonds, in hopes of later updating the bootloader only to a bonds-required one. This completes the whole OTA process ok, and the bootloader launches the app, but then the app fails VERIFY_SUCCESS for nrf_dfu_set_peer_data_init(). I believe that's the issue detailed here: devzone.nordicsemi.com/.../ where it is suggested to use a bootloader with bonds support in this case. Which seems impossible since for us such bootloader can't launch dfu to flash the application as mentioned above.

I should note that in our boards:

  • Directly flashing the softdevice SD 5.1.0 and pre-built bootloader without bonds () works ok (advertises DfuTarg).
  • Using OTA to upgrade from a SD 3.1.0, with bootloader and a working app, to SD 5.1.0, with bootloader without bonds (built in Keil from the SDK example) and app also without bonds (also built in Keil from the SDK example), works ok.
  • I've tried a couple of more combinations OTA but none worked, so now I'm thinking that either I've don't have a good grasp of how this is supposed to work, or there is some bug in the SDK for this particular use case?

Also note that the ultimate goal is to be able to upgrade OTA the firmware of NRF52 boards with SD 3.1.0, bootloader and working app to SD 5.1.0 with bootloader and working app with bonds and keeping application context across updates support. Flashing the boards directly with a programmer is not an option.

  • Hi Nate,

    I would not suggest to test with the precompile hex file but to build your own bootloader (with your public key) and the .zip file with your own private key.

    Could you let me know which SDK you used on your previous bootloader and application ? Did you set the correct Preserving application data as described here ? ,to preserver the bond information.

    Note that on earlier version of the SDK (SDK 13 and earlier) we don't support bond information forwarding when doing DFU. You still can preserve bond information but when doing OTA DFU the link is open. I'm not sure it's a requirement of you that the link should be encrypted when doing DFU or not. The "with bond" in the precompiled hex files are about the bond forwarding for encryption when doing DFU.

    You should test first with just no bond to check if the application data is preserved or not.

Related