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: Streaming interruption

Part Number: CC2564
Other Parts Discussed in Thread: EK-TM4C1294XL

In my scenario I have a Bluetooth device which streams data to the CC2564 (Bluetopia 1.2 stack on Tiva MCU), on SPP with a rate of 100kbps.

After some hours, the CC2564 doesn't receive anything anymore. Using the step by step debug, I can see that the Bluetopia task is running, but I don't receive the etPort_Data_Indication event anymore. So I get the HCI logs using the Logger tool, and I can see the following situation: ACL statistics drop from 105 kbps to 42 kbps, and then I don't receive anything. But the physical link is still active.

Do you find anything strange in the attached log?

AutoSave Session 01 - #0006.lgr.zip

  • Yes, due to some reason it appears the ACL connection rate seems to dramatically fall down to 0..
    What is the CC2564 partnumber and/or module used? Is this with TIVA C Launchpad or custom board?

    Thanks
  • Hi Hari

    We use the module CC2564MODNCMOE.

    We worked on both the TIVA C Launchpad (EK-TM4C1294XL) and our custom board, both with SPP demo acting as SPP client. As further information, we noticed that our device (SPP server) at a certain point seems to pause the transmission because it has no RFCOMM outgoing credits left. Does it sound familiar? How can I improva the RFCOMM credits management?

    Thank you

  • humm.. The client has send the credits.. If the Client's buffers are full or any other reason on its side, may not send the credits.. Please check RFCOM specs:

    :
    The credit based flow control feature provides flow control on a per - DLC basis. When
    used, both devices involved in a RFCOMM session will know, for each DLC, how many
    RFCOMM frames the other device is able to accept before its buffers fill up for that
    DLC. A sending entity may send as many frames on a DLC as it has credits; if the credit
    count reaches zero, the sender shall stop and wait for further credits from the peer. It is
    always allowed to send frames containing no user data (length field = 0) when credit
    based flow control is in use. This mechanism operates independently for each DLC, and
    for each direction. It does not apply to DLCI 0 or to non-UIH frames
    :

    Thanks
  • Yes, I was thinking about client's buffers too... So I tried the RFCOMM_Set_Data_Queuing_Parameters API with parameters 0, disabling the queuing mechanism and using the available RAM only, but the results are the same.
    I also noticed that if I connect to my SPP server from a PC serial COM (instead of Bluetopia), it doesn't show any problem... The big difference on my SPP server is that the outgoing credits improve from 3 (Bluetopia case) to 13... So it seems to be more resistant to stressful transmissions.

    Is there a way to manually renegotiate credits on Bluetopia library?
  • Can, you check how much initial credits are set: RFCOMM_Get_system_parameters..

    IMO, since credits are intended for flow control, any credit value should be fine.. Do, you have the ability to take any BT air sniffer logs?

    Thanks
  • Sorry I can't take BT air sniffer logs.
    I get more details: My tx packet are 800 byte long, so, starting from SPP Demo, I've to increase MaximumFrameSize. I set it to its maximum value (1020), and then I increase tx and rx buffer to 4000 and 6000 (to have more margin).

    SetConfigParams 1020 4000 6000

    I think that when it hangs, it's because the rx buffer gets full, and it doesn't send new credits. So I decided to reduce rx buffer, in order to get my device stuck in less time. I gave the command

    SetConfigParams 1020 4000 3000

    and it never hangs! It's still going on for 30 minutes without problems...
    Is there a contraindication to not increase rx buffer above a certain threshold?
    What are the best values, considering my packet size?

    Thank you
  • Glad to hear, you got it resolved.. It seems, the default frame size if 127, as listed in the RFCOMM.h header file..

    The RFCOMM protocol allows peers to negotiate the frame sizes, they can accept. So, the frame size, you select will get negotiated with the peer.

    thanks
  • Yes this is clear. But I'm talking about receive buffer size.

    In particulare the API

    SPPConfigurationParams.MaximumFrameSize   = (unsigned int)1020;
    SPPConfigurationParams.TransmitBufferSize = (unsigned int)4000;
    SPPConfigurationParams.ReceiveBufferSize  = (unsigned int)3000;
    
    SPP_Set_Configuration_Parameters(BluetoothStackID, &SPPConfigurationParams);

    With this configuration it works. The documentation talks about the minimum buffer size:

    The Transmit and Receive Buffer sizes *MUST* be AT LEAST the size of the Maximum Frame Size that is being set.

    But there's nothing about the maximum value. How can I adjust it? Is it better to choose a size similar to maximum frame size? The problem is that I don't understand why it works at 3000 and it doesn't work at 6000... Maybe a memory problem? I don't know how library allocates memory.

  • Yah.. the heap size maintained by the Bluetopia Kernel is capped.. Please, check the "MemoryBuffer" size in BTPSKRNL.h/c.. If it working with 3000, just leave it there..

    thanks