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.

CC2564B seems to be stuck during BLE scan / A2DP sink / RFCOMM

Other Parts Discussed in Thread: CC2564

Hi 

With our device, we are doing very long run to verify the robustness of our BT solution, based on TI CC2564B + third party BT stack (not BT Utopia stack).

We noticed that when the problems happens the TI CTS is raised for a very long time. We don't have the capture showing this.

This occurrence is difficult to reproduce but we have

  • TI BT logger
  • Coupled HCI trace / BPA600 trace 

See our analysis based on the attached traces :

HCI trace 

219,367               Command           9          00:00:00.006024             4/29/2016 11:15:25.596338 AM 

219,368               ACL Data          624        00:00:00.000281             4/29/2016 11:15:25.596619 AM 

219,369               ACL Data          855        00:00:00.011341             4/29/2016 11:15:25.607960 AM 

219,370               Event             8          00:00:00.004904             4/29/2016 11:15:25.612863 AM 

219,371               Command           9          00:00:00.002544             4/29/2016 11:15:25.615407 AM 

219,372               Command           6          00:00:00.002412             4/29/2016 11:15:25.617819 AM 

219,373               ACL Data          23         00:00:00.001374             4/29/2016 11:15:25.619193 AM 

219,374               ACL Data         855         00:00:00.002474            4/29/2016 11:15:25.616719 AM  --> Last received HCI packet before the issue

219,375               ACL Data         406         00:00:00.054838             4/29/2016 11:15:25.671558 AM --> Last sent HCI packet before the issue

 

Packet Data [406]: --> Incomplete packet on the HCI sniffer because CTS is raised in the middle of UART TX, and CTS is never de-asserted

02 01 00 91 01 8d 01 44 00 09 ef 10 03 ef be ad

de 4a 5b 02 13 80 00 01 c8 ad 00 00 56 44 32 11

21 b1 16 34 ae c2 42 dd 1f 1b 07 07 34 c9 d3 62

b2 9d 43 68 d9 a1 5c 31 b9 c8 b1 71 a5 0b 4f b0

73 56 1f 64 56 29 26 a9 62 36 aa 54 5b 08 54 61

98 a4 00 01 f8 ad 00 00 45 44 43 12 21 82 bb 53

55 0e d6 d0 d4 29 a1 4a 2d 76 65 44 53 10 70 d4

a7 35 d5 c6 99 25 89 82 32 64 65 4d 58 64 ba 15

b5 6b 12 4d 35 20 1b 56 ef 98 97 be 12 b4 00 01

08 ad 00 00 45 44 43 12 21 74 b5 5c 1a 94 d6 62

4a ca 38 eb 29 68 14 23 1a 4b 36 98 96 1b d5 c5

73 0e 79 6b 4a 9c 5e c9 17 15 c2 a6 40 24 ce 52

83 d3 49 11 14 d4 e7 99 a9 44 00 01 38 ad 00 00

16 44 42 22 20 6f 21 a7 19 57 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 c0 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00

 

 

BPA600  traces

217,012               0x0310e504        65           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK                                                       D            L2CAP    Go          Go          0             1             850                                                     862        00:00:00.000624             4/29/2016 11:15:07.491116 AM 

 --> Last phone packet correctly received. Based on HCI traces and Sequence Number we confirm that this packet was correctly forwarded over HCI

 

217,013               0x0310e50e        65           S (0xca-fe-fa-de-01-d8) (#1)          1             NULL     OK                                                       D            N/A [0]  Go          N/A [0]  0             1             0                                                          12           00:00:00.003126             4/29/2016 11:15:07.494242 AM  

217,014               0x0310e55c        68           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK                                                       D            L2CAP    Go          Go          1             0             731                                                     743        00:00:00.024374             4/29/2016 11:15:07.518616 AM 

217,015               0x0310e568        28           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK (Retransmitted packet)   D            L2CAP    Go          Go          1             0             731                                                     743        00:00:00.003750             4/29/2016 11:15:07.522366 AM 

217,016               0x0310e574        77           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK (Retransmitted packet)   D            L2CAP    Go          Go          1             0             731                                                     743        00:00:00.003750             4/29/2016 11:15:07.526116 AM 

217,017               0x0310e580        70           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK (Retransmitted packet)   D            L2CAP    Go          Go          1             0             731                                                     743        00:00:00.003750             4/29/2016 11:15:07.529866 AM 

217,018               0x0310e58c        68           M (0x3c-bb-fd-50-17-67) (#1)       1             3-DH5    OK (Retransmitted packet)   D            L2CAP    Go          Go          1             0             731                                                     743        00:00:00.003750             4/29/2016 11:15:07.533616 AM 

-> Packet not received by TI baseband controller. The phone is keep retransmitting the packet, but there is no response. The TI does not reply anymore with NULL packets.

 

 

TI Logger:

336479  11:15:07.349   +0:21:49.709         finish afh rssi scan pattern, scan valid = 1

336480  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336481  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336482  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336483  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336484  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336485  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336486  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336487  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336488  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336489  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336490  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336491  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336492  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336493  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336494  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336495  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336496  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336497  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336498  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  0 

336499  11:15:07.349   +0:21:49.709         last scan PHY grade:  0,   0,  0,  255 --> Last TI log before reboot 

BR,

  Franck

  • The traces can be downloaded from the below link :

    http://dl.free.fr/sulLmrFSq
  • Hi,

    Can you please attach the logs to this post?
    The link you gave is blocked here.

    Regards,
    Gigi Joseph.
  • Hi,

    In my previous update, the big ZIP file has been split into 5 files.

    I used the free tool hjsplit to split the file into 5 pieces, and renamed each piece with extension LOGGER_HCI_BPA600_traces.00x.zip, so that each piece can be uploaded, with ZIP extension recognized by the website.
    So, please rename each file LOGGER_HCI_BPA600_traces.00x.zip, as LOGGER_HCI_BPA600_traces.zip.00x, and use the free tool hjsplit to join the 5 pieces.

    Br,
    Franck
  • Hi Frank,

    Please see the below reply from our expert.

    ***

    it seems as the BT chip was just turned off in the middle, as I don’t see any traces in the time when there is constant retransmission from the peer.

    You can see below that there’s a gap of 6 seconds where there’s no activity, and that could explain the issue you’re seeing. You should check that all voltage/clocks are input correctly to the chip, as I would expect to see some traces even if there was some issue with the chip.

    When you try to reproduce the issue again and analyze the voltage/clocks etc, please upgrade to the latest FW as there were quite lots of fixes in version 1.4.









    ***

    Regards,
    Gigi Joseph.

  • Hello,

    We have reproduced the hang issue with the 1.4 revision of firmware. As for traces, we have added the following:

    Send_HCI_VS_Masked_Traces_Debug 0xFD7A, 0x000, 0x0000, 0x0224, 0x0000, 0x000, 0x0600, 0x000, 0x0000, 0x008b, 0x3c06, 0x000

    Please note that we're resetting the BT connection after it times out.

    Logs are here:

    NONE_AUDIO_EVT.7z

     Best Rgds/Seb.

  • Hi,

    We have reproduced the hang issue with 1.4 revision of firmware, with one additional fix. This is the FW  Init_btip_ORCA_L_PG2_0_TI_P7_16.

    As in the description of top of this thread, we can see :

     "Incomplete packet on the HCI sniffer because CTS is raised in the middle of UART TX, and CTS is never de-asserted"

    As in the below attached image, we cannot see :

    • there is none activity during 3 seconds, then our host triggers a power cycle  / reset of CC2564B, because we consider it as stuck
    • CTS remains raised indefinitely up to the reset.
    • No activity on TX UART of BT logger.

    Do you see additional things on your side from the TI logger traces, that are also attached.

    On our side, you need a slight rework of our board to check that all voltage/clocks are input correctly to the chip, when the problem happens. This is the next step on our side.

    I have 2 additional questions regarding the TI logger trace VS firmware :

    1. Let's say the firmware is stuck, is there a internal watchdog timer that generates a reset of the CC2654, whose traces can be seen on TI logger ?
    2. Would it possible that the CC2564 remains several seconds without generating trace on TI logger

    If the answers are  YES to 1), and NO to 2), then you may have some HW issues as you suspect.

    Br,

     Franck

    TI_logger.zip