nRFConnect App on iOS cannot do take app into DFU mode with SDK15.2

[chaitz]

Hi, 

nRFConnect is behaving differently for apps on different SDK versions. I am able to do a DFU via script something similar to the one here https://thegecko.github.io/web-bluetooth-dfu/examples/web.html. The app uses SDK 15.2. However, on testing DFU via nrfConnect on iOS it doesn't work. The device doesn't enter DFU mode. The same nrfConnect app can do DFU for an app using SDK 14.2.

Has anyone observed this before?

[bjorn-spockeli]

Hi Chaitz, 

No, I have not seen this issue before. Our mobile applications should be compatible with the latest version of our SDK as well as backwards-compatible with older versions of the SDK. 

Can you provide a sniffer trace of the on-air packets between the nRF device running SDK v15.2.0 and the iOS device? You can use our nRF Sniffer to do the trace, see https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer. 

Any log output from the nRF device or the nRF connect app on the iOS side would also be helpful. 

Best regards

Bjørn

[chaitz]

Hi Bjørn

Apologies for the delayed response. I have the following observations

1. The characteristics in the app cannot be subscribed to using the nrfConnect app, however it works fine with LightBlue app.

2. Using the sniffer I see that there are errors in ATT protocol - 0x0a attribute not found'.

3. Also the slave device disconnects from nrfConnect after a certain interval of time.

Any clues why this happens with nrfConnect/iOS?

[bjorn-spockeli]

Hi Chaitz,

1. By subscribe you mean allowing notifications by writing to the CCCD of the characteristic? Did you capture a sniffer trace of the LightBlue app as well?

2. Can you attach the sniffer trace? 

3. If the nRF device has been put in bootloader mode and the central that initiated the DFU procedure does not reconnect, then the bootloader will reset due to inactivity.

To me it could sound like the central(i.e. iOS device) is not connecting to the nRF device after it has triggered it to switch to bootloader mode from the application. This switch is done by the the application writing a magic number to a retained register, resetting the device and then the bootloader, which is always run on boot will check this retained register. The bootloader will then enable the SoftDevice and populate the GATT table with the DFU service.

Another issue is that the device will still have the physical address and the GATT table of the bootloader will not be identical to the application which the iOS device has been connected to, so the bootloader should send a Service Changed notification to indicate that the GATT table has changed and that a new service discovery must be performed.  

So it could also be that theiOS device has cached the GATT table of the application and is using those handles when communicating with the nRF Device. I will know more if I can see the sniffer trace. Attaching any debug logs from the nRF device and the nRF Connect app would also be helpful. 

[chaitz]

Hi Bjørn,

Thanks for the response. I will send you the sniffer logs soon. Meanwhile, I added peer manager (it was missing somehow!) to the applications and it seems to be working now. I am still validating this change. Can you please let me know whether it is mandatory to have peer manager? How much flash does it use and I see that it distributes service change indications - this will affect DFU isn't it? What is the effect of disabling peer manager?

[bjorn-spockeli]

You can use our bootloader in two configurations; allow DFU from unbonded devices (use ble_dfu_unbonded.c) or only allow DFU from bonded devices(use ble_dfu_bonded.c with NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS in the Preprocessor Definitions) . If the latter configuration is chosen, then you need to use the Peer Manager, as the bootloader uses its API to retrieve peer data( encryption keys, identity resolving keys etc). 

The Peer Manager and its dependencies is about 15kB I think. GATT table caching should only be an issue if you have bonded with the iOS device. 

[bjorn-spockeli]

You can use our bootloader in two configurations; allow DFU from unbonded devices (use ble_dfu_unbonded.c) or only allow DFU from bonded devices(use ble_dfu_bonded.c with NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS in the Preprocessor Definitions) . If the latter configuration is chosen, then you need to use the Peer Manager, as the bootloader uses its API to retrieve peer data( encryption keys, identity resolving keys etc). 

The Peer Manager and its dependencies is about 15kB I think. GATT table caching should only be an issue if you have bonded with the iOS device. 

[chaitz]

NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS is set to 0 and we are using ble_dfu_unbonded.c. So does this mean that peer manager is still needed for sending the service change indication?

[bjorn-spockeli]

No, service changed indication should only be necessary if you are bonded with the iOS device. You can initiate a Service Changed Indication through the SD API, i.e. sd_ble_gatts_service_changed()

If you are not bonded the the Bootloader will increment the device address by one so that it appears as a "new" device

#if (!NRF_DFU_BLE_REQUIRES_BONDS)
static uint32_t gap_address_change(void)
{
    uint32_t       err_code;
    ble_gap_addr_t addr;

    err_code = sd_ble_gap_addr_get(&addr);
    VERIFY_SUCCESS(err_code);

    /* Increase the BLE address by one when advertising openly. */
    addr.addr[0] += 1;

    err_code = sd_ble_gap_addr_set(&addr);
    VERIFY_SUCCESS(err_code);

    return NRF_SUCCESS;
}
#endif

So if you are not bonding to the iOS device and you do accept DFU from unbonded peers, then you should not need to use the peer manager. 

[chaitz]

OK, so even with NRF_DFU_BLE_REQUIRES_BONDS not defined, why cannot iOS do DFU/get notification unless peer manager is added to the application? What am I missing here?

[bjorn-spockeli]

If you are not bonded with the iOS device you do not need the PM and you do not have to send any Service Changed notification as the nRF device in bootloader mode will have another address than the device in application mode. The nRF Connect app should look for advertisment packets from both addresses.

If I could see the sniffer trace I would be able to see if the bootloader is changing the address or not and if the iOS device is attempting to connect to the bootloader or not.