cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Bluetooth

StN__1917156
Contributor

Bug report: wiced_bt_get_identity_address(*,*) function fails outside of the power cycle when last device was paired.

Tested with: WICED 6.2.1 on CYBT-413034- EVAL (CYW-20719)

Attached is a hello_sensor example modified with couple lines to printout wiced_bt_get_identity_address result immediately after new connection is established and connected BT device’s Public address is available.

  1. As soon as a BT device is successfully paired/bonded,  wiced_bt_get_identity_address returns status Ok and correct identity address on every connection to the same BT device
  2. As soon as CYW 20719 is reset, with any further connections to the same paired/bonded device before,  wiced_bt_get_identity_address returns status Fail and wrong  identity address is reported in the result parameter.

If you publish the code behind the wiced_bt_get_identity_address function might give you more serious hint what could be wrong there, but right now – just wild guess – the IRK etc. data stored in the NVRAM and restored after reset to address resolution database is not enough for wiced_bt_get_identity_address to works properly.

Thanks

0 Likes
4 Replies
Charles_Lai
Moderator
Moderator

Hi,

I tried your code on my CYBT-413034-EVAL for several times but I seem not to repeat the fault?

After I press the reset button and the board restarts, I reconnect to CYBT-413034-EVAL and didn't find the FAIL result as what you posted. See my logs below:

connection_down 00 a0 50 __ __ 9c conn_id:1 reason:19

hello_sensor_management_cback: 17

Advertisement State Change: 4

wiced_bt_start_advertisements 0

>>>resetting

Hello Sensor Start

hello_sensor_management_cback: 15

local keys read from NVRAM result: 0

hello_sensor_management_cback: 0

hello_sensor_application_init

wiced_bt_gatt_register: 0

wiced_bt_gatt_db_init 0

>>>IRK loading

hello_sensor_load_keys_for_address_resolution 00 a0 50 __ __ 9c result:0

hello_sensor_management_cback: 17

Advertisement State Change: 3

wiced_bt_start_advertisements 0

hello_sensor_timeout: 1, ft:962

hello_sensor_timeout: 2, ft:1947

hello_sensor_timeout: 3, ft:2930

hello_sensor_timeout: 4, ft:3914

>>>conn_up; IdentityAddress retrieved

hello_sensor_conn_up 00 a0 50 __ __ 9c id:1

:**IdentityAddress: 00 a0 50 __ __ 9c result:Ok

hello_sensor_management_cback: 17

Advertisement State Change: 0

ADV stop

Stopping Advertisements0

NVRAM write 9

hello_sensor_management_cback: 17

Advertisement State Change: 0

ADV stop

hello_sensor_timeout: 5, ft:4867

hello_sensor_timeout: 6, ft:5852

hello_sensor_gatts_req_cb. conn 1, type 5

Taking into consideration, I'm using CySmart 1.3 on Windows, with CY5677 USB Dongle. And the keys were saved to the resolving list at CySmart side in previous power cycle.

Please let me know if I misunderstood something.

<<<<<<<<<<<<<>>>>>>>>>>>>>

Best regards,

C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes
StN__1917156
Contributor

Hi C.L.

That is because your client (CySmart 1.3 on Windows) using it's public address, not RPA for connection - pay attention that in your log returned connection/disconnection addresses are the same as your identity address!  Try some device that will use RPA, not its public or static address for connection - you can see in my log which I posted: all the connections/disconnection events were from BD 57 68 55 9a f5 0e  then (and now is already something else .. ),  which is RPA,  while the identity address of this device (when successfully reported is always e4 xx xx xx xx 4b ).

The  device that I were using for this log is with Android 7.1 - same for Android 6.1 and I think back to Android 5 all were using RPA, but cant find older log before I upgraded this device (will double check and keep you posted if find something)

Android 4.4.4 though connects with its Public address and  does not have the issue reported too (I didn't pay attention till now though - before I read your post ).

So  obviously bug happens only when RPA is used, but not on those devices that don't use  RPA/privacy and maybe have and some dependency and which Bluetooth version (4.0, 4.2 etc. is used)

Regards

0 Likes
Charles_Lai
Moderator
Moderator

Hi,

I also tried using CySmart app, LightBlue app, and even LE Hello Client app (which can be found in <SDK_6.2>\common\peer_apps\hello_sensor\Android), on Android 7.1, to connect to your program. But they all failed to connect.

So then I went back using CY5677 on WIndows, which gave me the results showed above. In fact, even CY5677 can't connect to your program everytime.

As a contrast, the default hello_sensor program running on the same CYBT-413034- EVAL doesn't face the same problem and can be debugged successfully.

<<<<<<<<<<<<<>>>>>>>>>>>>>

Best regards,

C. L.

<<<<<<<<<<<<<>>>>>>>>>>>>>

0 Likes
StN__1917156
Contributor

"My" program is exactly the Cypresse's  program from SDK 6.2.1 with only added those lines @836 and this can be verified right away with any file compare utility like Examdiff:

// ss ***:

    {

        wiced_bt_device_address_t identity_address;

        result = wiced_bt_get_identity_address ( p_status->bd_addr,  identity_address );  // 1 Ok, 0 false

//        WICED_BT_TRACE("**IdentityAddress: %B result:%d \n", identity_address, result );

        WICED_BT_TRACE("**IdentityAddress: %B result:%s \n", identity_address, result?"Ok":"--FAIL--" );

    }

Feel free to use any source code whatever you want, just try to get result from wiced_bt_get_identity_address when the client using RPA and the bonding to the client happened before current power cycle.

Regards

P.S. I also have problems with connecting bonded only devices as reported here and wiced_bt_get_identity_address (if was working) was one of the ways I was trying to bypass the other bug

0 Likes