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).
