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.

CC2642R: Central Address Resolution characteristic 0x2AA6 suddenly added to Generic Access Service after update and broke previous bonding data

Part Number: CC2642R

SDK 3.10.0.53

We have a project based on a Simple Peripheral project with separate stack_library. In the next release we merged the stack_library with the main project and it works fine.

But we found that when we update the firmware, it breaks bonding data (or something) and our paired iOS app can't connect to the device. We have to forget the device and pair again.

It is not acceptable for our customers.

We investigated the problem and found that the old version with separate stack-library has less characteristics than the new one and the service that initiates pairing (it has encrypted characteristics) is shifted now and has different number. So when we connect to the device we see strange garbage there instead of our data.

We found that in the previous version (with separate stack_library) we didn't have the Central Address Resolution 0x2AA6 characteristic, but it appeared in the new version for some reason. SDK is the same.

How could we hide/delete/disable the 0x2AA6?

  • Hi Alex,

    Unfortunately, this may be a bit tricky. As per this thread: You may need to exclude many services, then add back any that you wish to keep. Confirming with others if there is another solution possible too.

    Best,

    Nate

  • Hi Nathan,

    Thanks for the answer. But why the Central Address Resolution was not added in the Generic Access Service in the project with the separate stack_library?

  • I read that the Central Address Resolution is used for central devices, but our device is peripheral.

    Do you know the bit map of the "services" parameter for the GGS_AddService(uint32_t services)? Usually we just use GATT_ALL_SERVICES, but is it possible to selecet some specific options for GGS with this parameter?

    Is the "Central Address Resolution" related to the GATT_NO_CLIENT somehow?

  • Hi Alex,

    I read that the Central Address Resolution is used for central devices, but our device is peripheral.

    Actually the Central Address Resolution characteristic is optional (not "excluded") in the case of the Peripheral.You can find the characteristics requirements for the GAP service in each of the GAP roles in BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part C, §12, Table 12.2:

    You can also review BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part C, §12.4 for more details about the Central Address Resolution characteristic.

    From my understanding the Central Address Resolution characteristic is now added by default - and may have been the case before.

    Is the "Central Address Resolution" related to the GATT_NO_CLIENT somehow?

    Not really. The symbol GATT_NO_CLIENT allow flash size reduction by disabling all the GATT client capabilities of the device. This prevents the device to use Privacy (because in that case Supported Privacy Feature Information exchange is not possible). If you are interested, more details are available here and here.

    Do you know the bit map of the "services" parameter for the GGS_AddService(uint32_t services)? Usually we just use GATT_ALL_SERVICES, but is it possible to selecet some specific options for GGS with this parameter?

    Actually the GAP service is one and only one service (whose bit field is hold by the "GAP_SERVICE" symbol). By changing the parameter passed to GGS_AddService(), you will NOT manage to add/remove the Central Address Resolution characteristic.

    To finish, you may want to explore the option offered in the thread provided by Nathan.However, by reviewing the thread I am not 100% sure nothing is missing. I mean, if you follow this, the proper read / write callbacks should also be implemented (more or less it is done for other elements of the GATT table).

    I hope this will help,

    Best regards,

  • Thank you very much for the detailed answer! Now it is much more clear.

    I have implemented a custom "clone" of the GAS profile with the great "Service Generator" and implemented it in our project. Now it passes the firmware update and pairing information is not broken.