• State Not Answered
  • Replies 7 replies
  • Subscribers 69 subscribers
  • Views 2692 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 220795
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems after DFU on IOS

Richard Yin

Hi,

We developed our device with KEIL 5, SDK15.2 and SoftDevice 6.1.1. After we upgrade the SDK on our device from version 14 to 15, our IOS phone encountered the following problem:

Use nRF connect on IOS to do DFU successfully and connected with the device again on the same IOS phone, the nRF connect couldn't search any service except the DFU service, but meanwhile, all the other phones can search all the service normally. On this situation, I only turn of the bluetooth and turn on it manually on the IOS phone, then nRF connect can search all the service.


Best regards,
Richard

Parents
  • 0

    Hi,

    When you have a changing GATT table you should also have a "Service Changed" characteristic, and you should handle it properly both in bootloader and application. Otherwise the peer device may assume that the GATT table did not change, which is exactly what iOS does. (Most smart phones do service discovery every time regardless, which explains why they get the new GATT table without problem.)

    iOS does not display the Service Changed characteristic, but if you use nRF Connect for Android or for Desktop you can check to see if your application (before and after) and DFU bootloader does use this characteristic. See for instance the thread Buttonless DFU Error: Enabling indications failed.

    Regards,
    Terje

  • 0 in reply to tesc

    Dear  Terje,

    How to handle "Service Changed" in bootloader and application? Could you please send any  any example code to demonstrate this process?

    Thanks and Regards,

    Richard

  • 0 in reply to Richard Yin

    Hi,

    For the bootloader it should not be an issue, as if you use NRF_DFU_BLE_REQUIRES_BONDS it will send service changed notifications. (If you do unbonded DFU then it will increment the BLE address by one when in DFU mode in order to avoid the issue. It then goes back to the old BLE address again for the (old or new) application.)

    For the application, if you use the Peer Manager you should use pm_local_database_has_changed() after a bonded DFU, or after any DFU that has updated the GATT table. You may have a look at the GATT Service Server Example Application for an example of notifying a database change (although in that example it is triggered by button press.)

    You also need to set NRF_SDH_BLE_SERVICE_CHANGED to 1 in sdk_config.h, in order for the GATT service to include the Service Changed Characteristic.

    Regards,
    Terje

Reply
  • 0 in reply to Richard Yin

    Hi,

    For the bootloader it should not be an issue, as if you use NRF_DFU_BLE_REQUIRES_BONDS it will send service changed notifications. (If you do unbonded DFU then it will increment the BLE address by one when in DFU mode in order to avoid the issue. It then goes back to the old BLE address again for the (old or new) application.)

    For the application, if you use the Peer Manager you should use pm_local_database_has_changed() after a bonded DFU, or after any DFU that has updated the GATT table. You may have a look at the GATT Service Server Example Application for an example of notifying a database change (although in that example it is triggered by button press.)

    You also need to set NRF_SDH_BLE_SERVICE_CHANGED to 1 in sdk_config.h, in order for the GATT service to include the Service Changed Characteristic.

    Regards,
    Terje

Children
Related