• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 52 subscribers
  • Views 2360 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.

Linux: Different performance, CC2564B works well, CC2564C has headset lost connection during sniff mode

Hong Gao
Intellectual 850 points

Other Parts Discussed in Thread: CC2564C

Tool/software: Linux

Hello,

When we use CC2564C chip in our phone and it's paired with a bluetooth handset and a bluetooth headset at the same time with headset profile.

We found that during speech with handset, headset goes into sniff mode. After about 2 minutes, headset is disconnected and reconnected again.

Disable sniff mode can sovle the problem, but we don't want to do that, for it cost device's battery.
And for make supervision timeout longer can reduce the lost connection but can't completely solve the problem.

We have done  test to disable sending HCI_Change_Connection_Packet_Type, but the problem is still there.

The logs for CC2564B and CC2564C cases are collected, both BT handset and headset are paired in exactly the same test procedure.

For CC2564C case, the headset lost connection during handset in speech and reconnected and speech transfer to headset (phone behavior), and after a while, handset lost connection and reconnect, so there are 2 times of lost connection happened to headset and handset seperately.

For CC2564B, there is no disconnection happened and handset keeps in speech.

Why CC2564C doesn't work properly? Please help check it. Thanks.

Regards

Gao Hong

0513.fw log.rar

  • 0
    TI__Mastermind 29361 points

    Hi Gao,

    Looking at the logs of the CC2564B vs CC2564C, I do not see much change in behavior except that the unit with CC2564C is missing a log of sync events on the first connection. This eventually ends up in disconnection due to connection timeout (LSTO). Although I would not expect much difference between the CC2564C and the CC2564B regarding the sniff mode, but it appears that many sniff instances are missed in the unit with the CC2564C (i.e. #158842, #158876, #159051 and many more).

    - Have you ensured equivalent RF performance from both units: the one with CC2564B and the one with CC2564C in it?

    - Does this issue only happen when the device is used with these 2 specific headsets? Or is it much more common?

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Intellectual 850 points

    Hello,

    The RF performance are the same for both units and it happens to other headsets, the problem is common.

    Is there any other clue to check the reason for lost of sync in sniff mode of CC2564C? Do you need other test logs?

    Regards

    Gao Hong

  • 0 in reply to Hong Gao
    TI__Expert 5285 points
    Hi Gao,

    I'm looking at the difference in the log files.
    what really jumps is the when using the CC2564C there are many SBC decoder out of sync ERRORS.

    Is the configuration of the PCM different between the two versions?

    Chen
  • 0 in reply to Chen Loewy
    Intellectual 850 points

    Hello, Chen,

    All are the same from application level and the bts files for two versions are attached. One for CC2564B and one for CC2564C.

    We both use MSBC for handset and CVSD for headset with HSP profile. And we also tried to set CVSD to two devices, but the problem still exists.

    The pcm setting in our application for both versions to set up sco are:

    {
     0x01,0x06,0xfd,0x22,

     0x00,0x01,
     0x01,
     0x40,0x1f,0x00,0x00,
     0x01,0x00,
     0x01,
     0x00,

     0x00,
     0x10,0x00,0x01,0x00,0x00,0x10,0x00,0x01,0x00,0x01,0x00,0x10,0x00,0x11,0x00,0x00,
     0x10,0x00,0x11,0x00,0x01,0x00
    }; // set PCM 8k

    {
     0x01,0x06,0xfd,0x22,

     0x00,0x02,
     0x01,
     0x80,0x3e,0x00,0x00,
     0x01,0x00,
     0x01,
     0x00,
     
     0x00,

     0x10,0x00,
     0x01,0x00,
     0x00,
     0x10,0x00,
     0x01,0x00,
     0x01,

     0x00,

     0x10,0x00,
     0x11,0x00,
     0x00,
     0x10,0x00,
     0x11,0x00,
     0x01,

     0x00
    };set PCM 16k

    Regards

    Gao Hong

    image.rar

  • 0 in reply to Hong Gao
    TI__Expert 5285 points

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/TIInit_5F00_2564C_5F00_Test.btsHi Gao,

    can you please try the following .bts

    and update me if there is any difference.

    Thanks,

    Chen

  • 0 in reply to Chen Loewy
    Intellectual 850 points

    Hello,

    The problem is still there and we can't collect log with the bts file you provided.

    Regards

    Gao Hong

  • 0 in reply to Hong Gao
    Intellectual 850 points
    Hello,
    Is there any special setting for the test bts file you provided?
    We found we can not collect fw log anymore even after we change back to the original bts file.

    Regards
    Gao Hong
  • 0 in reply to Hong Gao
    TI__Mastermind 29361 points

    Hong Gao said:
    Is there any special setting for the test bts file you provided?

    The BTS file only added one command related to the AVPR. It is not supposed to change any behavior related to the logger.

    Hong Gao said:
    We found we can not collect fw log anymore even after we change back to the original bts file.

    Are you sure this is not because of some issue on your hardware/test setup? I.e. the connection to the TX_DBG pin got damaged or something like that.

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Intellectual 850 points

    Hello,

    With the test file the lost connectio still happened.

    The log file is attached, pelease help to check.

    Thank you very much.

    Regards

    Gao Hong

    NewTestFail.rar

  • 0 in reply to Hong Gao
    TI__Expert 5285 points
    Hello Gao,

    I have went over the last attachment.
    Still can't find something conclusive.

    Can you please remove the AFH and test again.

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

    Hello,

    The file you send is about AVPR not AFH.

    And the log without AVPR is already send before in 0513.fw log.rar.

    Regards

    Gao Hong