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.