RE: Bonding information lost after DFU OTA update SDK 10.0 SD 8.0

NateABC — Thu, 27 Apr 2017 08:48:09 GMT

Hi, the issue seems to be resolved for us.

We've tried quite a few combinations, settings and code changes to get this working, so I'm not quite sure what exactly resolved it, (it could have been really simple) but it had to be of the following things:

-- We were using "nRFConnect Mobile" (from Android 7.0 smartphone). We failed to notice that there were Settings for "DFU options" and the "Keep bond information" in that menu was by default disabled. We have since enabled this option. This has the side-effect of creating a "cached services" issue after a DFU update, but I'll be creating a separate question thread for this and another issue. This option was definitely responsible for what we were seeing on the end of the DFU update (the nRFConnect disconnected from the boards and became unbonded).

-- Our application had some code in-place that in-case it read "garbage" or values that didn't make sense it some of the application context data fields, it would delete all bonding device information, and start over. I don't believe this could have been the culprit though, since this should only be responsible for clearing those data once after a new firmware update, and we were experiencing the issue consistently upon subsequent (multiple) updates of the same firmware image. We have not removed this code (because it is useful), but we added some extra code whereby after a new firmware update, if a persisted (in external memory) revision number has changed (indicating radical changes), then we explicitly enforce deletion of all bonding data to ensure that the new firmware won't be reading "garbage" in case it mistakes them for valid data.

-- In the Keil settings for our application firmware project, in the IROM1 size we now account for the restricted space that the application firmware should fit into, due to dual banking, and preserving application data. This value is identical to the DFU_IMAGE_MAX_SIZE_BANKED macro from dfu_types.h from the dfu firmware project.

IROM1: 0x18000, size: 0x11800 
IRAM1: 0x20002000, size: 0x2000

-- In the bootloader firmware project, the DFU_APP_DATA_RESERVED is now set to 0x1000 which is 4 * CODE_PAGE_SIZE. I don't think that this should change anything. The previous value was 0xC00 (3 code pages), and the bootloader was using padding to get it to a multiple of 0x800 which again was 0x1000, so this change shouldn't do anything different effectively. In the application firmware project, the PSTORAGE_NUM_OF_PAGES remained as 2.

And I think that is all. We've checked with:

nrfjprog -f nrf51 --readcode firmwareyyy.txt

and "diff" the dumps among subsequent firmware updates, and the bonding data seem to be preserved as they should, starting from the 0x3B400 address.

RE: Bonding information lost after DFU OTA update SDK 10.0 SD 8.0

NateABC — Tue, 25 Apr 2017 12:48:41 GMT

For the bootloader the settings (as entered in the Keil "Options for Target" dialogue) are:

IROM1: 0x3C000, size: 0x3C00
IRAM1: 0x20002C00, size: 0x1380
IRAM2: 0x20003F80, size: 0x80 (NoInit checked)

For the application:

IROM1: 0x18000, size: 0x24000 (also tried 0x23400 (= 0x24000 - 0xC00 ) here
IRAM1: 0x20002000, size: 0x2000

I'll try increasing the DFU_APP_DATA_RESERVED in the bootloader and the PSTORAGE_NUM_OF_PAGES define in the application firmware accordingly and report if anything changes.

Just in case it is related, the pstorage_platform.h in the bootloader project is different than the one for the application project. The bootloader one also has 2 flash code pages reserved, but that space is reserved at the end of the flash memory (NRF_FICR->CODESIZE). I have made no changes to that file. It's as it was from the SDK (10.0.0).

RE: Bonding information lost after DFU OTA update SDK 10.0 SD 8.0

bjorn-spockeli — Tue, 25 Apr 2017 12:06:05 GMT

As far as I know the bootloader should only erase bank 1 when the DFU start packet is received, i.e. you should see the new application image lying in both bank 0 and bank 1 after the DFU. Have you tried increasing the DFU_APP_DATA_RESERVED define , e.g. 4 or 5 pages? Also could you post the IROM and IRAM settings for your bootloader?