DFU service doesn't show service changed characteristic

[paul]

Hi,

      I am using SDK 15.0 on a custom board using nRF52840. Softdevice is 6.0.0. Coding with SES.

I am investigating and trying to fix the infamous IOS caching of characteristics problem where the IOS bluetooth stack doesn't refresh and so the correct characteristics are not shown.

As part of this I am ensuring that the service changed characteristic is showing in the generic attribute service in both normal and dfu mode. I am also running:

err_code = sd_ble_gatts_service_changed( m_conn_handle,  m_flex_service.svc_h,  0xFFFF);

on connection to cause the indication.

Currently I have the issue that the DFU mode service is not showing the service changed characteristic. I have stepped through the code and it appears to be enabling it in the default configuration.

Questions:

1) What do I need to do to get the service changed characteristic showing up under dfu mode?

2) Do I need the service changed characteristic in dfu mode to get the IOS bluetooth stack to update?

3) Do I just need the service changed characteristic or do I need both it and to call the sd_ble_gatts_service_changed function?

4) I am currently passing the service handle of one of my services into the sd_ble_gatts_service_changed function and 0xFFFF. Is that correct or do I need a different service handle or one call for each of my services?

Many thanks in advance

Paul

[Vidar Berg]

Hi Paul,

1. It should be enough to set NRF_SDH_BLE_SERVICE_CHANGED to '1' in skd_config.h. Have you done this?

nRFconnect on Android connected to bootloader in DFU mode after adding SC: 

2. The bootloader will use a different BT address as long as you don't compile the bootloader with NRF_DFU_BLE_REQUIRES_BONDS=1. This eliminates caching issues between app and bootloader. But I would still recommend adding the service changed characteristic just in case you need to update the GATT table in the bootloader in the future.   

3. It depends on whether you are bonded or not. The client shall not cache attributes across connections if hasn't bonded with peripheral and the SC characteristic is present. If it is bonded, the peripheral must send the indication to let the client know that it needs that the attribute table has been updated. Please refer to core spec v.5, vol 3, part G, section 2.5.2 for a better explanation. 

4. Recommend let the peer manager handle this if you are using it? But with the patch I posted here: https://devzone.nordicsemi.com/f/nordic-q-a/46633/peer-manager-silently-drop-service-changed-indications-if-an-att-mtu-exchange-was-happening/185510#185510

Best regards,

Vidar