About L2CAP TX queue flow control

Misa,

I would highly recommend for you to use the newer GA version available from TI. It has many fixes and updates and should overall help you with getting your application going.

The payload can be up to 110 bytes, however the stack splits the data to the relevant size. The flow control that you're seeing is normal and takes care of messages that might not have arrived from one layer to another. Are you missing data? It's not clear whether you really have any issues.

Gustavo

Hi,Gustavo

Thank you very much for your help.

If I have more the develop time, I want to try the newer GA.

Please tell me again.

After CPU reset, execute the program,  It's no problem , SPP connect ok, SPP's data are exact value on the master PC .

But a few seconds later, It has executed the below code (1) -> (2).

appl_spp_l2cap_tx_queue_flow_cb()
{

    /* Flow Off - Don't send data */

    else {
       /* Set data can't be sent */                ----- (1)
    }

}

appl_spp_notify_cb()
{

    case SPP_SEND_CNF:

            } else {
                SDK_SPP_CHANGE_DATA_STATE(rem_bt_dev_index, TRUE);  ----------- (2)
            }

}

What's happen ?

Regards,

Misa

These are call back functions that are registered with the Bluetooth library.

The appl_spp_notify_cb() is called for any SPP notifications like SPP connection confirmation, SPP connection indication, SPP disconnection etc. The appl_spp_l2cap_tx_queue_flow_cb() is called to check for the flow control status.

Hi, Balaji

I want to know whether L2CAP's TX buffer has changed from not full(i.e., it can receive the data) to full (i.e., it can't receive the data).

First, In PC(BD master) has received normally the BT_spp_send()'s data from the board(BD slave) ,

It is executed avobe code 's line (1) part (actually, add dummy code for breakpoint ,e.g. i++;)  -> line (2) part sequentially,and

PC hasn't receive the data from the board,but BT_spp_send() is continue on the board.

Is this mean that L2CAP's TX buffer has changed from not full to full?

Regards,

Misa

Miguel,

Following on this thread, I also have similar issue with the BT_spp_send function.

I'm trying to send dynamic packet over the BT, which may range from 50b - 2kb, so does that mean I have to break the packet up into pieces in order to send it via the appl_spp_l2cap_tx_queue_flow_cb()?

Details:

While sending a 900b packet, the SDK errors, and a SDK_BT_MEM_ALLOC_FAIL, so I've been looking also into this thread, and I still not quite understand the flow here.

If one would want to transfer a large packet, how would that be accomplished?

Adam.

Srisenthilkumar,

Thank you for your quick response, that is one mystery uncovered.

I have developed a bridge between Android device and the PAN1315, and true, while sending packets which are less than ~250b the operation works, but once the packet is bigger, I receive the error as I've described earlier.

Now that I understand how to aggregate the packet chunks, and call onto the BT_spp_send function, with the packet chunk from the appl_spp_l2cap_tx_queue_flow_cb(), the question remains, when does the peer actually gets notified of the packet?

I've debugged the flow and noticed, that although I get the SPP_SEND_CNF on the spp call back function, and although the l2cap has aggregated the packet, the peer is not notified of the packet, until sometime after the call. Why is that?

Does the buffer gets empty only after it has been sent to peer?

Thanks,

Adam. 

Hello Adam,

There is no flow control between SPP profiles. You would have to implement it on top of the SPP profile as part of your application. What exactly do you want to achieve?

Regards,

Miguel

Hi Adam Zehavi,

    We could dump packets with available l2cap buffers. lets take currently configured 260bytes buffer is 2, even you can increase the no.of buffers also from 2 to some N based on your MCU memory.

   From Transmitter side, once l2cap put packet into link layer & physical layer using hci then you will get a SPP_SEND_CNF,and next chunk of bytes you could dump here.

  From Receiver side, once you received packet from peer device you will get a nofication  case SPP_RECVD_DATA_IND: in appl_spp.c

apppl_spp_l2cap_tx_queue_flow_cb -  L2CAP calls this callback when the number of  buffers occupied in the ACL Transmission Queue goes above or below a set limits.

Regards

Guys,

It took my a lot of debugging, and your constructive help, to complete the packet protocol, finally I understand the l2cap flow and how to use it.

I had a very serious problem with debugging the embedded program, with the debug messages delay intervals which effected the behavior of the program (connection specifically), and even worst problem understanding what went wrong, while the kit was not connected to the debugger. Since I'm trying to construct a bridge between the Android mobile and the kit, I've decided to send the kit debug logs to the Android phone, and integrate the logs as packets, this was not a pleasant task.

I've completed the protocol, only to find out that I did not take packet losses under consideration while designing it. I'm working up a solution, and have posted this question.

Thanks again for your help.

Adam.