This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652RB: How to make sure new characteristics are discovered on my peripheral device after a firmware update?

Part Number: CC2652RB
Other Parts Discussed in Thread: SYSCONFIG

We are using the CC2652RB in a peripheral device based on the SimplePeripheral example, currently with SDK v4.20.  We have a one-to-many use case where a multitude of cell phones as centrals will connect to our peripheral over time.  We therefore do not use pairing or bonding.  Our problem is that after a firmware update in which we added some new characteristics to our proprietary Bluetooth service, any iOS device that had previously connected to any of our devices acted as if the new characteristics did not exist.  It seems as though the phone cached the attribute table and refuses to rediscover the now-different list.

I know that there is a "Service Changed" characteristic as part of the GATT Service as laid out in the Bluetooth Core Specification, and Apple's Accessory Design Guidelines state that it shall be used if the service may ever be changed.  However, it also specifies that this is for bonded devices, and the change is communicated via an indication on reconnection.  As we do not use bonding, and a non-bonded device would not be able to receive an indication immediately on connection, we were under the impression that we did not need this Service Changed characteristic, nor would it even work if we added it.

But, we are desperate for a solution here, so we're willing to try it unless someone has a better idea.  So, my questions:

  1. Is there a better way to do this?  How can a TI BLE device get iOS to rediscover an updated list of characteristics?
  2. Does the Service Changed characteristic work for non-bonded connections?
  3. How would one add the Service Changed characteristic using the TI libraries?  In the "related question" to which I linked this post, a workaround was given for a bug in a previous SDK.  That post is a year and a half old, however, and mentioned that a fix should be available later last year.  So what is the procedure now?
  4. The "related question" also mentions that adding this characteristic adds a large chunk of code to the image size for the COC stuff; is there a way to just get the characteristic without the indications?  Since we're not using bonding and the indications likely wouldn't work anyway, can we just try adding the characteristic to see if that's good enough for iOS to not cache the service and actually do discovery?
  • Hi,

    Please apologize for the delay; you mentioned you are not pairing or bonding, thus I am a bit surprised that iOS is caching the GATT characteristics. Does this happen with Android as well? 

    If I am reading this correctly, page 1541 of the spec indicates this should not happen with untrusted connections

    I don't know if/how iOS handles the aforementioned hash characteristic. I don't see one in our examples or code (only the pairing hash, which is not applicable here). 

    In any case the steps to add the service changed feature are shown in the GATTService section of our BLE User's Guide; A direct link is:

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_30_00_54/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gatt.html#using-the-gatt-service

    Hope this helps,

    Rafael

     

  • desouza said:

    you mentioned you are not pairing or bonding, thus I am a bit surprised that iOS is caching the GATT characteristics.

    Me too!

    desouza said:

    Does this happen with Android as well? 

    It does not.

    desouza said:

    If I am reading this correctly, page 1541 of the spec indicates this should not happen with untrusted connections

    I agree again, and yet...

    desouza said:

    In any case the steps to add the service changed feature are shown in the GATTService section of our BLE User's Guide; A direct link is:

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_30_00_54/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gatt.html#using-the-gatt-service

    I had found that, but we're using another TI-suggested workaround for our custom boards, where we ran SysConfig for initial setup, then excluded it from subsequent builds, relying rather on the initial files it had generated, along with manual changes we've made since then.  I didn't really want to redo that, so I tried to edit the build_config.opt file mentioned in the User's Guide, except... there isn't one anymore.  That file doesn't exist in the project anymore ever since SysConfig was made mandatory in the SDK.  There is a ti_build_config.opt file in the {PROJECT_LOC}\Sysconfig folder, but adding the define there didn't do anything.  I was able to finally get the characteristic to show up (I'm still awaiting word from our iOS team whether it helps) by adding BLE_V41_FEATURES=L2CAP_COC_CFG under the project Properties->Build->Arm Compiler->Predefined Symbols.  Is that good enough, or does it have to be in some options file so that some other compile/build step sees it?

  • Chris,

    Please apologize for the delay. Indeed the Sysconfig certainly changed quite a bit when compared to legacy projects. 

    I suspected that you already tried this but, if you only modify the ti_build_config.opt file on its own without any other modifications, this would probably not trigger a new build. You would have to right click on the project and issue a Rebuild Project.

    To your question, the method you choose one of the traditional ways to pass predefined symbols to the compiler, so it is perfectly safe to use. 

    Best regards,

    Rafael