Bonding information lost after DFU OTA update SDK 10.0 SD 8.0

Question

Hi, 
 We are currently facing this issue, where after a DFU application firmware update (or bootloader update) the bonding information gets wiped out. 
 We are using a custom board as peripheral based on NRF51822, with Soft Device S110 8.0 and SDK 10.0.0. 
 Our DFU bootloader (based on the SDK dual bank bootloader) has been compiled with: 
 #define DFU_APP_DATA_RESERVED (3*CODE_PAGE_SIZE)
 
 which is 0xc00 bytes, and this includes the swap page. 
 The Application firmware is using the device_manager and does not initialize pstorage anywhere else, so the swap page is placed right below the bootloader start address (which is 0x3C000). Our pstorage_platform.h has: 
 #define PSTORAGE_NUM_OF_PAGES 2 
 
 because that number does not include the swap page (so it should match the DFU_APP_DATA_RESERVED when including the swap page) 
 and our device_manager_cnfg.h has (changed): 
 #define DEVICE_MANAGER_MAX_BONDS 3
...
#define DM_GATT_CCCD_COUNT 9
...
#define DEVICE_MANAGER_APP_CONTEXT_SIZE 8
 
 The application firmware on its own, once programmed, is able to store bonded information of devices across resets / power cycles. 
 And when the bootloader is called for a dfu update the nrfconnect shows the device still bonded (when the DFU is started by a bonded device) for the most part of the OTA DFU process (up to the end). 
 However, the bonding information is erased at some point during OTA DFU update, seemingly right near or at the end. Then, every page in the "DFU_APP_DATA_RESERVED" space has 0xFF. 
 I've dumped the flash memory before a DFU update and it had valid data in the start of the DFU_APP_DATA_RESERVED space (address: 0x003C000 - 0xC00 = 0x0003B400) and in the start of the swap page ( 0x003C000 - 0x400 = 0x0003BC00). 
 I've dumped the flash memory interrupting a DFU update (while uploading) and those regions were still maintaining their data. 
 However, after a complete successful DFU update, those regions were cleared out and the mobile phone was no longer bonded, and needed to re-bond again. This happens every time. 
 I am not sure if it's relevant but we are using Keil Studio uVision v5.20 as our IDE. 
 What could be going wrong? Could the bootloader be wiping out the DFU_APP_DATA_RESERVED space, after swapping the application to the bank_0 space, even though it should preserve that data space? 
 We need to carry bonding information across DFU OTA updates. It seemed that setting the DFU_APP_DATA_RESERVED would do the trick as per the documentation, but there's seems to be something else that we are missing. 
 I've found a similar older thread here: devzone.nordicsemi.com/.../ 
that is probably the same issue we are facing, but there doesn't seem to be a solution there; I've tried the suggestions there but I had no further luck, and I didn't want to resurrect that thread. 
 
 edit: I'm adding the original Keil settings for the bootloader firmware project and the application firmware project here, too, for quicker reference:
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 (also tried to leave 0x80 (NoInit) for IRAM2 here like in the bootloader but that didnt make sense, nor did it solve the issue and we reverted it)
 
 The final ROM/RAM settings for the applications are : 
 IROM1: 0x18000, size: 0x11800 
IRAM1: 0x20002000, size: 0x2000
 
 I'm not certain if the change in IROM1 helped for the solution or not, since the issue is now resolved. It seems to be more correct though so we'll be keeping it like that. The change reflects the restriction for the code size due to the dfu dual banking we are using.
This size is the DFU_IMAGE_MAX_SIZE_BANKED from the dfu_types (the space where the uploaded app firmware image should fit into).

NateABC · Accepted Answer

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.

Bonding information lost after DFU OTA update SDK 10.0 SD 8.0

Top Replies