After successful iOS DFU, the App gets disconnected. Connecting again the phone with the development board shows wrong information as values for some characteristics

[Cristi Paval]

Dear Nordic Team,

I am able to perform a successful DFU on a development board pca10040 using the DFU library for iOS. The thing is that after the DFU process, the phone gets disconnected. When I as a user perform a new connection between the development board and the nrf Connect App on iOS, some characteristics show weird values:

• The characteristic for Software revision string shows the value which is actually from Firmware revision string characteristic
• A custom characteristic has as value 'Battery Level' string which is actually the name descriptor for the Battery Level characteristic

After manually turning OFF and then ON again the Bluetooth services from iPhone settings, the issue it's solved. It is solved also if I go to Bluetooth phone settings and unpair the development board and pair it again with the phone. I read some other similar issues here in DevZone. The thing is that the Service Changed characteristic is set on both the bootloader and the App and the issue is still always reproducible.

Could you advise what else I should check?

Thanks a lot!

[Sigurd]

Hi,

What SDK version are you using? Are you using nRF5-SDK or nRF Connect SDK(NCS)?

NCS: Do you have CONFIG_BT_GATT_SERVICE_CHANGED=y?

nRF5-SDK: Do you have NRF_SDH_BLE_SERVICE_CHANGED set to 1 in sdk_config? Are you using the Peer Manager?

[Cristi Paval]

Hi Sigurd!

Thanks for replying!

We use NRF5 SDK v16.0.0. 

With regards to the last two questions, the answer is yes for the application and no for the boot loader.

We use the DFU as provided by Nordic as Buttonless Secure DFU without bonds.

[Sigurd]

Cristi Paval said:

We use NRF5 SDK v16.0.0. 

Ok, good, there were a bug in SDK 15.3.0 (in PM implementation) and earlier that could cause the service changed indication to become dropped if it overlapped with a MTU exchange.

Try calling pm_local_database_has_changed() when the device connects, and see if that helps. Or only call it when you know the attribute table has changed or is likely to change. For instance, calling it just to prior to entering DFU mode (Must not be connected at this point as that may cause the indication to be sent before DFU instead of after)