Hi,
After successfully managing to preserve our devices bonding information (and custom app context data) across DFU updates, we have a few related questions.
I should note that we are working on custom peripheral boards based on the nRF51822, S110 v8.0.0 softdevice and SDK 10.0.0.
Q1: When checking the dump of the board's flash memory to check whether the bonding information were stored and preserved, we noticed the device manager reserves one extra word (4 bytes) before the start of our app context data. This seems to be referred to as "len" but it's not the actual length of the app context data (which should be constant and "0x10"(=16 bytes) for our case). This value appears to be rather random, and it's additionally updated every time the corresponding bonded device gets connected with the peripheral board, which suggests that it carries information about the last time a bonded device connected to our board. What is the significance of this field, and how can we interpret its value?
Q2: Related to Q1. At some point this word field that precedes the application context data was retrieved as 0x000000001 (by an dm_application_context_get() call) which made the board halt (invalid_parameter error code, when calling dm_application_context_set in app_context_load). This happened when trying to connect to a previously bonded device, since upon app_context_load, the code tries to retrieve that "len" field and later asserts it against being a multiple of 4. This could be due to our testing with various sizes for DEVICE_MANAGER_APP_CONTEXT_SIZE and related macros in device_manage_cnfg.h, so that the code was reading obsolete "garbage" from a previous storage format which didn't make sense with the new firmware. However, since this field seems to be updated to a seemingly random value, could it actually be assigned a value that will later cause the above ASSERT to fail, during normal operations?
Q3: The SDK documentation suggests adding 2 to our DM_GATT_CCCD_COUNT macro in device_manage_cnfg.h to account for the the two new Service Changed characteristics (one for the application itself and one for the DFU Service), as noted here in the Updating the Device Manager configuration: infocenter.nordicsemi.com/.../bledfu_appextending.html We don't use the device_manage_cnfg.h from the "\components\ble\device_manager\config" path, but rather a local copy modified for our needs under our projects "config" subfolder. Does our application firmware have to account for both of those Service Changed characteristics or just one of them?
Q4: Since we now preserve bonding information, after a DFU application firmware update the nrfConnect indicates that the board is still bonded. However, upon connect it falsely shows the DFU bootloader mode services and characteristics, and it needs an explicit "Refresh Services" performed from the nrfConnect context menu for the bonded node to acquire the proper services and characteristics for the node. There is code in app_context_load to call sd_ble_gatts_service_changed if the first field of the app context data for that bonded device is set to 1 (flag: DFU_APP_ATT_TABLE_CHANGED). Shouldn't this cause the nrfConnect to refresh its cache for the bonded node?
Q5: Related to Q4, if the peripheral board was bonded with more than one central devices, how will the rest of those devices be informed about the changed services (and new or removed characteristics) after a new firmware update, since the Service Changed indication seems to only be sent to the bonded central that performed the firmware update? Is it a good idea to always send this indication upon connecting to a bonded device to be on the safe side?