CC2640R2F: Still can send Indication even if the characteristic property is Notification

Intellectual 1980 points

Part Number: CC2640R2F

Hi Team,

My customer uses CC2640R2F with SDK version 3.30. BLE 4.2.

In Simple Peripheral project, a characteristic is defined "GATT_PROP_NOTIFY"(char 4). But on the phone app side, they "enable" its "indication" (write 0x0002 instead of 0x0001 to its CCC). Then from sinffer logs, they can see char 4 can send indication.

It's not a proper operation from application layer(you should not use "indication" on a char that is defined for "notification"), but seems in this case, "GATT_PROP_NOTIFY" property is not really working down there in the stack. If the char is notify property, then the stack should prevent this behavior to be happening even if application layer try something improper, correct?

Any ideas?

Thanks!

over 4 years ago

0 Evan Wakefield over 4 years ago

TI__Mastermind 38920 points

Hey Yan,

I've assigned your post to someone within the team to follow up.

0 Jan over 4 years ago

TI__Mastermind 34770 points

Hi Yan,

I have a few questions I would like answered, so that I can better help. Has the customer modified the Simple Peripheral project in any way? By default, char 4 should allow notifications only, as you described. What tool are they using to interact with the characteristics? Are they using a custom phone app or a publicly available BLE scanner? I used BTool to connect to a board running Simple Peripheral and was not able to enable indications (writing 0x02) which is the expected behavior. If indications were attempted to be enabled in BTool then the following message is displayed: INVALID_VALUE. Can the customer verify if this issue still occurs when using BTool?

Regards,

Jan

0 YZ over 4 years ago in reply to Jan

TI__Intellectual 1980 points

Hi Jan,

More information from customer.

They use Android phone app. They just enable notification via Android app, and use below modified code to send indication.

0 Jan over 4 years ago in reply to YZ

TI__Mastermind 34770 points

Hi Yan,

From my understanding, it seems the customer does not enable indications through the use of GATT_PROP_INDICATE in the project, but then attempts to enable indications and sends out an indication? I believe this is not supported behavior. Is there any reason why the customer is attempting to do this?

Regards,

Jan

0 YZ over 4 years ago in reply to Jan

TI__Intellectual 1980 points

Hi Jan,

Yes, they don't enable indication through the use of GATT_PROP_INDICATE, they just use the code to force the device to send indication while actually the characteristic is GATT_PROP_NOTIFY.

It is not a normal operation from core spec perspective of view, they do this just for test, to make sure the stack would not operate improperly while the application layer gives the wrong action requests by mistakes.

In other words, they are testing the TI BLE stack reliability :)

0 Jan over 4 years ago in reply to YZ

TI__Mastermind 34770 points

Hey Yan,

I did some research and it seems that in a case like this it is up to the developer to implement a check to prevent this from happening. An indication is still being transmitted because the developer is sending one from within the simple_gatt_profile.c. This file is technically not a part of the stack. The stack itself is not causing this indication to be sent out, but instead the developer is explicitly calling for it. Since we are within the profile, then the developer should have complete control over what is done within the file and should be able to prevent any indications from being sent.

Regards,

Jan

0 YZ over 4 years ago in reply to Jan

TI__Intellectual 1980 points

Hi Jan,

Thanks for your reply again, I understand your point.

The problem is, simple_gatt_profile.c is included in TI's SDK. In customer's point of view, this is simply TI SDK problem, if you stand at customers position, quite a few customers can distinguish which part of the SDK is "BLE stack", which part of SDK is not, for them, profile layer is also considered as part of "BLE stack".

Customers usually don't want to touch the code that they consider as "BLE stack" and would mostly like to keep them as they are from original SDK. And TI provided GATTServApp_ProcessCharCfg() function, this function also applies the above consideration.

That's also our target goal of easy to use for customers, right? Let customers focus on their application, don't touch parts they are not familiar as less as possible.

BTW, customer also tested other vendor's SDK, they don't have this problem, indication or notification would not be sent like this behavior.

I hope we can improve this in the SDK level, not only in the "BLE stack" level :)

Thanks!

0 YZ over 4 years ago in reply to Jan

TI__Intellectual 1980 points

Hi Jan,

Some more inputs from customer:

They call GATT_Indication() directly from application layer to replace GATTServApp_ProcessCharCfg(), SDK still have the same behavior.

In this case, I don't think this is only just application layer call to judge what behavior should do, it should be in the "BLE stack". The implementation of GATT_Indication() is not exposed in the SDK, and it is GATT Profile, it's "BLE stack" host part, not application layer code.

Some more comments? Can you consider this as a bug and fix it in the library code?

0 Jan over 4 years ago in reply to YZ

TI__Mastermind 34770 points

Hello Yan,

Thank you so much for the additional information. The simple_gatt_profile.c file is intended to be used a starting point for implement a profile and should never be left unmodified in a final customer implementation. However, I agree that it may cause confusion. I will file this as a bug and we will attempt to rectify this issue so that future releases of the SDK prevent this behavior from occurring at all. Thank you for the feedback! :)

In the meantime, a workaround may be implemented as follows:

if(simpleProfileChar4Props & GATT_PROP_INDICATE != 0)
{
    // Send indication
    simpleProfileChar4Config->connHandle = 0;
    simpleProfileChar4Config->value = 2;
    GATTServApp_ProcessCharCfg( simpleProfileChar4Config, &simpleProfileChar4, FALSE,
                                simpleProfileAttrTbl, GATT_NUM_ATTRS( simpleProfileAttrTbl ),
                                3, simpleProfile_ReadAttrCB );
}

This will ensure that an indication is not sent unless the indication flag has been set in the characteristic properties.

Regards,

Jan

0 YZ over 4 years ago in reply to Jan

TI__Intellectual 1980 points

Hi Jan,

Thank you!

Bluetooth®︎

Bluetooth forum

CC2640R2F: Still can send Indication even if the characteristic property is Notification