Sharing bonding info with DFU but getting BLE_GAP_EVT_CONN_SEC_UPDATE that causes issues

[GaryG]

I have the application saving off the information it should from the Nordic documentation titled "Sharing bonding information" which is part of the Info center software developers kit example section: m_peer_data.addr = key_set.keys_central.p_id_key->id_addr_info; m_peer_data.irk = key_set.keys_central.p_id_key->id_info; m_peer_data.enc_key.enc_info = key_set.keys_periph.enc_key.p_enc_key->enc_info; m_peer_data.enc_key.master_id = key_set.keys_periph.enc_key.p_enc_key->master_id;

I get the bootloader to start up and find the information, it bonds to my application and according to the Nordic Sniffer application the connection is encrypted. Then the S110 bootloader quickly gets a BLE_GAP_EVT_CONN_SEC_UPDATE event with data of security mode = 1, level = 2, and encr_key_size = 0x10. This causes the bootloader to call into service_change_indicate() which calls sd_ble_gatts_sys_attr_set() and this fails with a NRF_ERROR_INVALID_DATA. The sys_serv_attr is all zeros since the application doesn't set this to any values but I don't see how to get it set correctly. If I just call sd_ble_gatts_sys_attr_set() with the 2nd param NULL then everything works fine.

What am I missing?

I have changed the way the application is sharing the peer_data is it is going through a dm flash area that is shared between the app and bootloader, but that seems to be working as it gets the whitelist etc data to the bootloader to allow pairing with my application but another device running nRF Master Control Panel sees the device but doesn't have a "Connect" option for that device. If I don't do the sharing of bonding info it does show the "Connect" option.

...Gary

BootloaderSecureConnectionForNordic.pcapng

[Hung Bui]

Hi Gary,

Well, the event BLE_GAP_EVT_CONN_SEC_UPDATE tells the bootloader that the link is encrypted. When the link is encrypted the bootloader will try to send the "Service changed" indication to tell the DFU master to do a service discovery to update the attribute table. This is needed because the attribute table changed from application to bootloader.

In this case I suspect that the system attribute (the value and handleid of the CCCD of service changed characteristic) has not been saved and passed to the bootloader. If you have a look in bootloader_start() function in dfu_app_handler.c file in the ble_app_hrs_s110_with_dfu example you can find that we read it out and then store it in m_peer_data.sys_serv_attr.

I guess it's not saved and passed to bootloader in your implementation where you use flash to pass the information?

Could you try to follow what we do there and let me know the result ?

If that didn't help could you share the sniffer trace you captured. A trace contains the pairing procedure with the application, then application switch to bootloader, then the issue, would be great. Also please let me know your SDK version and the DFU master you used. Also, do you have any issue when testing with our example ?

[Hung Bui]

Hi Gary,

How did you test your app ? Make sure you have written to the Service Changed CCCD to enable indication. If you call sd_ble_gatts_sys_attr_set() with null, the CCCD for service changed will not be set and the bootloader won't send the indication => DFU master wont update the table.

Again, please provide us your sniffer trace, and please try a test with the ble_app_hrs_with_dfu