CYW920721 Wiced application connection call back returns wrong junk BD address

[Lavanya]

We are using CYW920721 in our project and our application is based out of the example code Audio watch.

Connection initiator side BD address:8e 6d 17 42 c5 2c

Peer side BD address: a6 4b 12 42 6e 2c

BD address correption:

We are seeing wired issue when the connection is initiated with some BD address, connection call back from the stack result in first bytes corrupted sometimes results in pairing failure. 

Connection initiator side log

[2023-05-25 09:04:04.205] hci_control_handle_bond:wiced_bt_connect a6 4b 12 42 6e 2c
[2023-05-25 09:04:04.684] wiced_bt_start_authentication(CALLED):result=1
[2023-05-25 09:04:04.731] hci_connection_status_change_callback handle:000b ac:46:12:42:6e:2c isConn=1, handle=000b, reason=0, transport=1 cnt{conn=1|notConn=0}
[2023-05-25 09:04:04.731] btm_event_handler 0x13

Pairing failures with status 5:

Also, the device retries connection to the same address that time call back has the right address but pairing complete with status 5 means pairing not allowed whereas remote devices pairing is configured to be allowed.

Peer side log

[2023-05-25 09:03:53.103] hci_control_ag_init:pcmCfg mode=0 role=1 lsbFirst=0 fillBits=0 fillData=0 fillNum=3 rightJustify=0 frame_type=0
[2023-05-25 09:03:53.103] + hci_control_proc_rx_cmd
[2023-05-25 09:03:53.103] cmd_opcode 0x03
[2023-05-25 09:03:53.103] + hci_control_proc_rx_cmd
[2023-05-25 09:03:53.103] cmd_opcode 0x08
[2023-05-25 09:03:53.145] + hci_control_proc_rx_cmd
[2023-05-25 09:03:53.145] cmd_opcode 0x09
[2023-05-25 09:03:53.145] Set the pairing allowed to 1
[2023-05-25 09:03:53.145] + hci_control_proc_rx_cmd
[2023-05-25 09:03:53.145] cmd_opcode 0x0f
[2023-05-25 09:03:53.145] Local Bluetooth Address: [a6 4b 12 42 6e 2c ]

---

Connection initiator

[2023-05-25 09:04:40.554] hci_control_handle_bond:wiced_bt_connect a6 4b 12 42 6e 2c
[2023-05-25 09:04:41.143] wiced_bt_start_authentication(CALLED):result=1
[2023-05-25 09:04:41.143] hci_connection_status_change_callback handle:000b a6:4b:12:42:6e:2c isConn=1, handle=000b, reason=0, transport=1 cnt{conn=1|notConn=0}
[2023-05-25 09:04:41.143] btm_event_handler 0x13
[2023-05-25 09:04:41.143] BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT: find device a6 4b 12 42 6e 2c
[2023-05-25 09:04:41.143] Key retrieval failure
[2023-05-25 09:04:41.143] btm_event_handler 0x08
[2023-05-25 09:04:41.143] BTM_PAIRING_IO_CAPABILITIES_BR_EDR_REQUEST_EVT bda a6 4b 12 42 6e 2c
[2023-05-25 09:04:59.107] btm_event_handler 0x0b
[2023-05-25 09:04:59.107] BTM_PAIRING_COMPLETE_EVT
[2023-05-25 09:04:59.107] pairing complete evt: a6 4b 12 42 6e 2c as 2c 6e 42 12 4b a6 status 5

After few retries device pairs successfully. Kindly share your thought. I wanted to raise this as high priority issue because it affects our connection cycle. 

[Owen_Zhang123]

Are you using the MTB SDK? What's the peer device?

[Lavanya]

Hi Owen_Zhang,

  Kindly help me understanding the BD addr first few bytes are masked. We could see that in the sniffer trace. What could be reason and how to make radio not to mask those bytes. 

Thanks,

Lavanya

[Lavanya]

Yes, we are using MTB SDK. Peer device also uses CYW920721 and same watch application (a2dp sink and HFP-HF etc )

[Owen_Zhang123]

I am not quite clear about you problem. I didn't see the bd address error. It is always a6 4b 12 42 6e 2c.

Besides, the watch demo only shows the a2dp_source profile. Could you try to test with watch and headset demo?

[ScottKerstein]

Owen, they are using modified code from the MyCase system which builds source and sink so they can choose the profile at runtime.  I will forward the email to you.

Scott 

[Lavanya]

Hi Owen/Scott,

  Any finding on this? As the BD address is corrupted it is not doing proceeding for the pairing process further and peer side does not receive any thing in the air. We see this as critical issue, Kindly help us root causing this.

Thanks.

[Lavanya]

We are not using the eval kits, it is our own board, and the application is customized. Also, I have not copied the entire logs here. 

We are using two boards both use CYW920721 chip and our application is customized watch application. During the connection - disconnect - reconnect process we see at times after we initiate the bond with some BD address say a6 4b 12 42 6e 2c, connection status change call back says it found some other device ac:46:12:42:6e:2c. Note we have initiated the connection for a6 4b 12 42 6e 2c and in the call back we get the first two bytes changed as ac:46 instead a6:4b so obviously pairing will not be  successful using this wrong BD address. Kindly refer the below mention log line

[2023-05-25 09:04:04.731] hci_connection_status_change_callback handle:000b ac:46:12:42:6e:2c isConn=1, handle=000b, reason=0, transport=1 cnt{conn=1|notConn=0}

 Once this problem is seen the next immidiate few pairing request fails due to the pairing complete with status 5.

Hope this clarifies. Feel free to ask more questions.

[advait_kulkarni]

Hi @Lavanya / @ScottKerstein ,

I have posted a response in the case management, can you please check the same?

Thanks and regards,

Advait Kulkarni

[Lavanya]

Hi Advait,

  Can you please give me more details of because related to this case I dont have anything in the case management?

[advait_kulkarni · Accepted solution]

Hi @Lavanya ,

Providing the screenshots of the air logs here as well which I have provided in the case. Blocking this thread to avoid duplicates, kindly get back to us in the case management.

Thanks and regards,

Advait Kulkarni