CC2640R2F: Attributes handles changed after update from CC2640R2F SDK 2.20 to 3.30 (BLE5)

Anders Esbensen88

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

We are in the process of updating our products from SDK version v2.20 to v3.30 (both ble5 stack variants).

After update to new stack handles values are different, due to changes in the attribute table. This seems to be related to removal of the "Peripheral Privacy Flag" in the Generic access service.

As I undertand privacy flag has been obsolete since BLE 4.1 so this seems to be a reasonable change.

The problem now is that when I update my devices, then already paired phones that has cached the attribute table, now refer to wrong handles when reconnecting.

This requires users to switched on/off Bluettooth on their phones to clear the attribute cache (at least this is the case for IOS devices)

The correct way to handle this seem to be with Generic Attribute Service/Service Changed indication characteristic. This is not default included, and as mentioned in other post this requires approx 5 KB additional code space when enabled( requires enabling L2CAP_COC_CFG)

This is not an option since we already are on the limit with codespace in our application.

The question now is whether it is possbible to add some kind of dummy attribute to the Generic access service, or any other way move the handles back to their original values?

Best regards

Anders

over 5 years ago

0 Eirik V over 5 years ago

TI__Guru 56590 points

I assigned an expert to comment.

0 Marie H over 5 years ago

TI__Guru* 79011 points

Hi Anders,

Attribute handles can change when you make code changes. It's never recommended to hard code attribute handles.

You can try to experiment with adding something to your services, but I would think it's better to ask the user to clear their Bluetooth cache.

0 Anders Esbensen88 over 5 years ago in reply to Marie H

Prodigy 130 points

Hi Marie

Thank you for the quick reply.

Attribute handles are not hardcoded locally in our app, but due to caching in the central devices, this issue arises when porting new stack. Is it in anyway possible to readd the legacy privacy flag in the new stack?

In other posts it is indicated that a fix is expected that allows enabling service change characteristic with less increase in code space than what currently is the case,

When do you expect this to be included in the SDK.

Best regards

Anders

0 Marie H over 5 years ago in reply to Anders Esbensen88

TI__Guru* 79011 points

Hi Anders,

I'm sorry I can't help you. The generic access service is part of the BLE-Stack library that we provide precompiled in the SDK, so there is no way for you to change it back.

Can you link me an E2E which references this, I couldn't find it.

0 Anders Esbensen88 over 5 years ago in reply to Marie H

Prodigy 130 points

Hi Marie

The space issue is mentioned is this thread:

http://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/824508?CC2652R-Service-changed-indication-in-ble5stack

"Please notice!
As this is a temporary fix, it enables the use of L2CAP COC (Connection Oriented Channels) functions which will probably occupy some extra flash space. This should be corrected by the time the fix is out with the newer SDK."

Do you have any time frame for this to be optimized

Best regards

Anders

0 Marie H over 5 years ago in reply to Anders Esbensen88

TI__Guru* 79011 points

Hi Anders,

I see.

No as far as I can see this has not been implemented in a released SDK and I can not tell you when it will be included.

Bluetooth®︎

Bluetooth forum

CC2640R2F: Attributes handles changed after update from CC2640R2F SDK 2.20 to 3.30 (BLE5)