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

CC2564: Lost RFCOMM Packets During CC2564B A2DP SBC Setup

John Gassel
Intellectual 365 points
Part Number: CC2564


We believe we’ve found an issue with the CC2564B Bluetooth chip that we’re using and I wanted to see if anyone else has observed this before.

It appears that the chip can potentially lose a packet when the A2DP audio is turned on or off.  This only seems to happen when the controller is configuring itself.  We’ve seen it lose RFCOMM SPP data and credits.  If we disable A2DP (or even just the SBC decoder within the TI controller), this lost packet problem goes away.

I confirmed we are using the latest patch.  Is this a known problem with the chip?  Perhaps it’s resolved in the newer CC2564C revision?

  • 0
    TI__Mastermind 29311 points
    John,

    This issue is not expected in either CC2564B or CC2564C? Do you have any logs showing a capture of this issue?

    What host MCU stack are you using?

    Best regards,
    Vihang
  • 0 in reply to Vihang Parmar
    Intellectual 365 points
    Hi Vihang,

    We're using Dotstack running in an STM32F429.

    I'll get some logs posted shortly.

    Thanks,
    John
  • 0 in reply to Vihang Parmar
    Intellectual 365 points

    Hi Vihang, I've attached the following log to show more clarity than the previous one.  

    The trouble begins when a phone requests to start a stream. This is the first packet in the stack's log. The headset configures the controller.

    Configuration completes on page 3 with "PCMPORT_PA:A3DP stream started" message. Now the phone is streaming and the controller plays the audio.

    At this time the Solos app sends an image. The first fragment of the image is on page 4. I highlighted all packets that comprise the image with green color. There should be 16 fragments. Their numbers in the

    BPA600 log are: 13831, 13833, 13835, 13853, 13855, 13857, 13880, 13947, 13949, 13951, 13953, 13979, 13981, 13983, 13987, 14010.  The stack's log is missing two of them: 13880 and 14010.

    All this time that the image was being sent the phone was also sending audio. A request to stop the stream is on page 29. It seems that packets are lost not only when the controller is being configured but also when it is processing audio frames.

    missing_rfcomm_frames-3.zip

  • 0 in reply to John Gassel
    Intellectual 365 points

    Have you had a chance to look through these logs yet?  Thanks!

  • 0 in reply to John Gassel
    TI__Mastermind 29311 points

    John,

    Sorry for the delay.

    I went through the sniffer capture and your notes. For both of the missed/dropped RF frames, I see the CC2564B does send the baseband layer ack to the master. Unfortunately, the air sniffer logs are not enough to debug this issue. As a next step, I would recommend capturing the same air sniffer logs in conjunction with the CC256x FW logs (Instructions) so that there is a relative time sync between the two logs. This way, we might be able to get more insight into why the host is not seeing these ACL data frames.

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Intellectual 365 points

    Hi Vihang, we've reproduced the problem again with the additional CC256x FW logs as you requested.  Some background info:

    The test apps (on the phone and the stack) send data as fast as they can. Packets from the phone have structure - a header and a data portion. The header includes sequence number. The problem occurs after the stack received packet #11176. In the stack's log this is line #450170. In the BPA600 log this is frame #94074. This frame contains last fragment of the packet #11176 and the start of packet #11177. The next frame that contains a fragment of the packet and which was received by the stack is #94078 (line #450179 in the stack's log). This is the last RFCOMM frame with data that was received by the stack. After this the phone sent 4 more frames - 94095, 94097, 94099, 94101 - but these frames were not sent to the stack. Because of this the stack never sent credits to the phone. The phone now had 0 credit so it stopped sending.

     When the problem occurred the phone was streaming audio. Streaming began on line #448112 in the stack's log and ended on line #454880. In the controller's log this corresponds to the range from frame #42984 to #43291.

     missing-frames-log-02112017.zip

  • 0 in reply to John Gassel
    Intellectual 365 points

    Any news on this?

  • 0 in reply to John Gassel
    TI__Mastermind 29311 points

    Hello John,

    Apologies for the delay. The FW logs and sniffer logs you provided did help a lot in analyzing the issue. It appears these missing packets are somehow being mis-interpreted by the AVPR as AVDTP packets. And thus, not being sent down to the host.
    We are evaluating possible fixes to this race condition. I will keep you posted on the progress.

    Best regards,
    Vihang