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

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

bjorn-spockeli — Tue, 14 May 2019 14:59:31 GMT

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.

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

chaitz — Mon, 13 May 2019 14:30:20 GMT

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?

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

bjorn-spockeli — Mon, 13 May 2019 14:00:34 GMT

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.

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

chaitz — Mon, 13 May 2019 13:17:34 GMT

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?

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

bjorn-spockeli — Mon, 13 May 2019 12:06:03 GMT

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.

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

bjorn-spockeli — Mon, 13 May 2019 12:06:02 GMT

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.

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

chaitz — Mon, 13 May 2019 11:19:04 GMT

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?

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

bjorn-spockeli — Mon, 13 May 2019 08:17:54 GMT

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.

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

chaitz — Thu, 09 May 2019 10:57:06 GMT

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?

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

bjorn-spockeli — Fri, 03 May 2019 12:03:41 GMT

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