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 ?

[GaryG]

When I call sd_ble_gatts_sys_attr_get() from my application I get NRF_ERROR_NOT_FOUND returned. I am running with s110 8.0.0. I'm running with SDK version 8 components but this call is into the softDevice so the SDK version shouldn't matter, right?

This is the same value returned if called during a connection or after the disconnect.

When I change the bootloader so it calls sd_ble_gatts_sys_attr_set() with a null as the 2nd parameter and not with the attribute I don't have the bootloader works as far as I can connect to it from my central app and do the reflash. Given the application is using flash to communicate the application calls the reset vector address (0x00000004) to restart the system and doesn't just call the bootloader address. This means the softdevice is restarted so maybe the attribute table reset isn't needed? Just trying to figure out why it works to understand if this is a valid solution.

...Gary