Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Bluetooth SDK

Level 3
First like received 25 sign-ins 10 replies posted
Level 3

Please help me to understand how to implement the following scenario: my device based on CYW20706 is BLE peripheral that is able to accept pairing from multiple clients and maintain bonding info over power cycles.

According to WBT101-04B-BLE-Ntfy-Sec.pdf document, if bonding info for the remote device being connecting exists, it shall be loaded upon receiving BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT. Now comes the question: the proposed solution is to find the proper bonding info in NV database, based on the MAC address of the remote. However, if the address is random, the one from the database and the one coming with the BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT don't match. I checked the data provided in the wiced_bt_device_link_keys_t structure delivered with BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT, and there only 'bd_addr' (the random one) and 'key_data.le_keys_available_mask' are set. So, there's no chance to find out whether the data from NV database belongs to the remote device being connecting.

However, if we use only one device, it works pretty well: when BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT is received we load bonding data without checking MAC address, and it gets accepted.

I did find some tickets that discuss similar issues, for example, this one https://community.infineon.com/t5/Wi-Fi-Combo/How-to-resolve-random-ble-address/m-p/235008#M17495, but they describe scenario with one remote device only.

For my tests I'm using latest version of ModusToolbox 2.4.0 with Bluetooth SDK 3.1.0 on CYW920706WCDEVAL, with LE_Battery_Service sample application.

1 Solution
Moderator First question asked 1000 replies posted 750 replies posted

Hi @kf ,

We had a discussion with our developer team and it was concluded that there will not be any more updates to WICED STUDIO since it is considered as deprecated. Therefore our team recommends you to move to Modustoolbox to resolve this issue. We brought up the two concerns you had in moving to Modustoolbox. Those were addressed as below:

1. MTB lacks BTM_SetDefaultLinkSuperTout() API that is essential to our product.

Infineon:  We will provide official support for this API in the next release of BTSDK (MTB).

2. Our product is already Bluetooth-qualified. Using different SDK would mean new qualification, isn't it?
Infineon: The customer can move to BTSDK/MTB even though they have done the listing. It should make no difference.


View solution in original post

21 Replies