CC2640: Write not permitted for RACP characteristic after updated SDK v2.2.4

Additionally,

If I set "glucoseAttrTbl[10].permissions" to GATT_PERMIT_ENCRYPT_WRITE or GATT_PERMIT_WRITE, it works fine of course.

Hey Calvin,

I've looped in someone on my team to assist. 

Calvin,

This issue seems similar to https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/282596. Have you looked at the solution proposed?

I'm doing more investigation in the meantime.

Thanks,

Luis

Hi Luis,

I checked the link but I think this is not the same issue.

Thanks,

Calvin

Calvin,

It's probable that the handle changed. Could you try to read the complete table in both versions of the SDK and post the results? You can use host_test and the BTool to do this.

Thanks,

Luis

Hi Luis,

I attached the table and it's same.

gatt-table.zip

I don't have a devkit for CC2640F128 so could you check this issue with glucose sensor example of SDK2.2.4?

(ble_sdk_2_02_04_06\examples\cc2650em\glucose_sensor)

The RACP characteristic's permission set as GATT_PERMIT_AUTHEN_WRITE by default in glucservice.c 

// 10.Characteristic Value

    {

      { ATT_BT_UUID_SIZE, recordControlPointUUID },

      GATT_PERMIT_AUTHEN_WRITE,

      0,

      &glucoseControl

    },

Thanks,

Calvin

Calvin,

Thanks for the tables. You're right, they are the same.

I don't have access to the LAUNCHXL-CC2650 myself immediately, but I am trying to get one and also consulting with the experts in these devices and SDKs.

In the meantime, I'd like to ask you a couple of questions and to do some things:

• Are you seeing these differences in behavior based on the glucose_sensor examples provided by TI? or, are you using some custom code / application?
• Please try to analyze the code differences in your project with the two versions of the stack
• Please try things like resetting the phone and "forgetting" the device
• Also, have you observed the same behavior on other characteristics? Can you try?

As I said, I'm working with other members of my team to get you the answer. Thanks for your patience.

-Luis

Hi Luis,

• Are you seeing these differences in behavior based on the glucose_sensor examples provided by TI? or, are you using some custom code / application?

-> I'm using my custom application and the code is based on the glucose_sensor examples.

• Please try to analyze the code differences in your project with the two versions of the stack

-> My application code is exactly same in both project and I compared whole files of the two versions of SDK

    I found below difference in the gatt.h and nothing else was special.

• Please try things like resetting the phone and "forgetting" the device

-> Yes, I'm doing test everytime after "forgetting" the device.

• Also, have you observed the same behavior on other characteristics? Can you try?

-> Yes, I tried and the result is same. If I set permission to GATT_PERMIT_AUTHEN_WRITE on any other characteristics, it's not working.

Thanks,

Calvin

Calvin,

Thanks for your reply. I think that the fact that other characteristics are showing the same behavior is an important piece. I'm working with the team to try to understand the root cause.

Thanks for your patience.

-Luis

Calvin,

I received my LaunchXL-CC2650 and will try to reproduce the issue.

In the meantime, I received from my team this e2e ticket that may provide us some answers: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/708906/2618755. In particular, please verify that you succeed in authenticating with MITM pairing, especially with this tip from the same thread: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/708906/2618755#2618755

Can you please review it?

Thanks,

Luis

Hi Luis,

An engineer from WPG korea test about this issue with LaunchXL-CC2650 and glucose example.

He confirmed that the issue reproduced on 2.2.4 and not on 2.2.2.

Any update on this?

Thanks,

Calvin

Calvin,

I'm sorry for the delay. I'm trying to find an answer to this issue. I'll be working with someone from my team and provide you an update by 4/20/20.

-Luis

Calvin,

Here's a quick update. I found a couple of things that I would like you to try:

• As indicated in the developer's guide (you can search for SWRU393e on our website ti.com), the properties in the declaration of the characteristic must match the permissions in the characteristic value attribute entry. See sections 5.3.4.2.1.2 and 5.3.4.2.1.3, and in particular the note in between those. So, glucoseControlProps should be set to some GATT_PROP_ values (using bitwise OR), and the characteristic value permission should be set to some GATT_PERMIT_  values (using bitwise OR). Please let me know if this makes sense, or I can expand.
• Changing the permissions at runtime might be an issue. Please try the desired configuration (...AUTHEN_WRITE) and the passkey entry statically defined at compile time (i.e. the values are all set statically, and the values are passed to the BLE Stack during initialization)

I hope this helps.

-Luis

Hi Luis,

1. Originally the glucoseControlProps is set as below

glucoseControlProps = GATT_PROP_INDICATE | GATT_PROP_WRITE;

I added GATT_PROP_AUTHEN like below and test it but the issue is not solved.

glucoseControlProps = GATT_PROP_INDICATE | GATT_PROP_WRITE | GATT_PROP_AUTHEN;

2. Defining statically -> The issue is not solved.

Did you test glucose example? Please let me know the result.

Thanks,

Calvin

Calvin,

I was able to reproduce the issue.

First, I confirmed that the glucose_example allows writing RACP with passkey entry on BLE Stack v2.2.2.

Second, I also confirmed that the glucose_example does not allow writing it on BLE Stack v2.2.4. I got the same response as you -- write not permitted.

I'm looking for a solution with the team. I'll provide you an update by 4/28.

Thanks,

Luis

Calvin,

I have another quick update. I also tried the simple_peripheral example, and modified characteristic 5 to AUTHEN_WRITE, and got the same result. I'm working with the team to understand the root cause. Thanks for your patience.

-Luis

Calvin,

Our R&D team is now aware of the issue and will investigate. Once I hear from them, I will update you with a solution or a workaround.

Thanks,

Luis

Calvin,

This has been confirmed as a functional defect and is planned to be fixed on our next release.

I'm sorry for the inconvenience. If a workaround is available, I will publish it on this thread.

-Luis

Hi Luis,

Thank you for your help.

I'll wait for the next release.

When it be the release date roughly?

Thanks,

Calvin

Calvin,

My apologies, I had not seen your reply. I'll try to get you the dates when a new version with the fix will be released.

-Luis