• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 52 subscribers
  • Views 1721 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564C: Failure occurs when reconnect a headset device via HSP

peijie shi
Intellectual 650 points
Part Number: CC2564C

Steps:

1. A terminal(based on TI chip) with a low bluetooth sdk version just supporting legacy pair method.already paired with a headset device.

2. Upgrade to a higher bluetooth sdk version with supporting simple secure pair method.

3. Reconnect between terminal and headset device with same information like linkkey needed by sdk. But connection fails.

a.Use another device same procedure as above, connection succeeds.

b.If downgrade bluetooth sdk to previous version, reconnect succeeds again.

So i want to make sure whether this is related with controller or not ? 

Also i attach the two air trace log.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/reconnectFailsAirTrace.7z

  • 0
    TI__Expert 5285 points
    Hi.

    it sounds to me that you are having an issue with a device that is already saved in the whitelist of the application.
    Please clean the whitelist of the devices that are already paired and try again.

    Please let me know if that solved the issue.

    BR,
    Chen Loewy
  • 0 in reply to Chen Loewy
    Intellectual 650 points

    Thanks for your reply.

    Yes, the re-connection is expected to be successful based on new bluetooth sdk which is a kind of bluetooth stack when it works on old sdk stack version, but it cannot work on new stack version.

    And I don't know why another handset device with HS profile can work normally based on both same application and new bluetooth stack.This makes me confusing.

    I also checked this two air trace logs, failure and success, found that difference is authentication failure. 

    After consulting with bluetooth stack supplier, they have no efficient explanation except for re-pair and suggest me submit this issue to TI to check.

    Is it possible that is caused by TI controller when legacy paging information used in both devices support SSP?

    BR,

    PeiJie Shi

  • 0 in reply to peijie shi
    TI__Expert 5285 points
    Hi,

    it seems that different authentication methods are used - new SDK vs old SDK.
    therefore the data saved by the Host in the white-list is irrelevant.
    Therefore if i understand the scenario correctly you will have to remove the connection from the white-list and reconnect.
    and everything should work well from that moment.

    BR,
    Chen Loewy
  • 0 in reply to Chen Loewy
    Intellectual 650 points
    I think this issue is related with bluetooth SDK. Further discussion should be taken with the supplier.
  • 0 in reply to peijie shi
    Intellectual 650 points

    Hello,

    Sorry to mention this topic again since I need more assistance.

    I have communicated with bluetooth SDK supplier about this use case and they confirmed that their software works well for CSR BT chip.

    Considering that there are a plenty of products will be affected by this issue which is required to be solved.So this is urgent for us.

    Could you help analyze TI chip layer logs captured when issue happens if logs can be assisted to find the root cause?

  • 0 in reply to peijie shi
    Intellectual 650 points

    hcisniff.txt

    I attach one file with HCI command between controller and application which shows an unexpected disconnection event from controller after connection established.

    ================================================================================================

    Okay, so in this situation both radios support SSP (headset and Alcatel), but because the BlueSDK version didn’t support SSP, a legacy Combination key was generated.  However, once you upgrade the BlueSDK version, full SSP support will be available.  It’s possible that the encrypt operation would succeed in this case using the old key, as I was able to get this  to work with a CSR and Broadcom 4.0 chipset, but perhaps this isn’t guaranteed in all cases for all controllers.

    In this case if you know that you have upgraded the application to support SPP, a legacy key exists, and a subsequent encryption attempt fails, then I would recommend deleting the bond and re-pairing to generate an SSP key.  This will ensure things behave correctly moving forward.

    >>>>>>>>>>>>>>

    The part above is given by stack applier.

    Hope these message could be used for analyzing.

    Best Regards

  • 0 in reply to peijie shi
    TI__Expert 5285 points
    Hello,

    in order to be able to help you i will need you to attach the FW logs so i can see what does the chip see in this specific situation.

    BR,
    Chen Loewy
  • 0 in reply to peijie shi
    Intellectual 650 points
    Hi,

    I attach two FW log files of OK & NOK.
    Please check.
  • 0 in reply to peijie shi
    TI__Expert 5285 points
    Hello,

    Going over the two files i can see totally different scenarios.

    The one that works well:

    We create a connection to one device (we initiate the connection) 00:13:7B:5A:E6:2F - and the connection succeeds.
    Then we connect a second device: 0C:E0:E4:0E:8D:61 and succeed. we add encryption and all works well

    So we are master on two connections

    The one that fails:

    We are slave - we accept a connection from : 0C:E0:E4:0E:8D:61 and then we do a role-switch to become Master.
    We begin the encryption - and it fails somewhere along the way - the other side sends us a detach.

    I would start by doing the following:

    Can you please try to recreate the exact same scenario which means.
    Remove the page_scan from the device - and see how it goes when the device initiates the connection.

    BR,
    Chen Loewy
  • 0 in reply to Chen Loewy
    Intellectual 650 points

    Hello,

    Page_scan, as I known, is a state waiting to respond a paging request from the other side.

    If remove the page_scan from the device, whether this means that the device cannot be respond the paging request from our side?

    If what I understand is right, the problem is that I don't know how to operate that(remove page_scan from the device) since the device belongs a 3rd party. Otherwise, please correct me.

    Thanks.

  • 0 in reply to peijie shi
    TI__Expert 5285 points
    Hi,

    you are correct.
    However i mean stopping the page scan from our side.
    this way we will not respond to a page request from the other device - however if we initiate the page procedure the other side (not your device) will still answer.

    I would like to see the same scenario and understand what could be the issue.
    currently these are two different scenarios - in the working one we are the master.
    in the failed one we are the slave.

    BR,
    Chen Loewy
  • 0 in reply to peijie shi
    TI__Expert 5285 points
    Hello Pierre,

    When i go over this log i can't see a problem.

    We are the Master - we keep connecting to the other device.
    We keep getting disconnections from the other device - User detached the connection which is totally fine.

    So i don't see any problem with the attached log.
    BR,
    Chen Loewy