• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 401 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.

Original question:

RTOS/CC2640R2F: L2CAP CoC Connection Oriented Channels support

RTOS/CC2640R2F: support for full L2CAP API still missing in SDK 2.40

Oliver Mueller
Prodigy 90 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Tool/software: TI-RTOS

Hello,

while L2CAP CoC offer some support since SDK 2.30, any useful support is still missing in 2.40.

I'm succesfully using lower level APIs like `L2CAP_SendSDU` but the whole purpose of L2CAP CoC is defeated when APIs like `L2CAP_SendData` are not available.

There is no streaming support without those functions. What are your plans to support this?

Or am I missing something vital?

Also on the receiving side, I only managed to receive data packages up to 255 bytes.

  • 0
    TI__Mastermind 33460 points

    Hi Oliver,

    >> There is no streaming support without those functions. What are your plans to support this?

    What do you mean by streaming support? Do you mean Streaming Mode as defined by Version 5.0, Vol 3, Part A, Section 2.4?

    As the CC2640R2 contains only an "LE only" controller it operates in LE Credit Based Flow control mode. Here is an excerpt from the spec regarding LE Connection Oriented Channels: "LE Credit Based Flow Control Mode is used for LE L2CAP connection oriented channels for flow control using a credit based scheme for L2CAP data (i.e. not signaling packets). This is the only mode that shall be used for LE L2CAP connection oriented channels."

    So in summary, we only support LE Credit based flow control mode. That said, I believe that it should be possible to implement a streaming based application based on the L2CAP CoC feature within the stack, so long as the data rate is sufficient to meet the consumption rate.

    >> I'm succesfully using lower level APIs like `L2CAP_SendSDU` but the whole purpose of L2CAP CoC is defeated when APIs like `L2CAP_SendData` are not available.

    L2CAP_SendSDU is the higher level API. An SDU is a higher level application packet that may be (internally) fragmented by the L2CAP layer into multiple PDUs based on the PDU size negotiated with the peer. In summary, at the L2CAP layer an SDU is segmented into multiple PDUs. Once the SDU is segmented, the L2CAP_SendData API is used to achieve sending the PDUs over the Link Layer. So in summary, our stack is performing segmentation and reassembly. Is there a reason you would need to access the sending of individual PDUs from your application?

    >> Also on the receiving side, I only managed to receive data packages up to 255 bytes.

    The stack supports a maximum SDU size of L2CAP_SDU_SIZE which is set to 512 in the library builds included in the SDK.

    You should be able to send and receive SDUs of this size from your application. Have you negotiated your MTU for this channel appropriately?

  • 0 in reply to Sean2
    Prodigy 90 points
    thanks for your response!

    >> What do you mean by streaming support?
    sorry I was vague...I mean I expected that I do not need to chunk up my data and reassemble it. e.g. sending data > then the SDU requires multiple calls to L2CAP_SendSDU instead of calling L2CAP_SendData just once.
    In that way I'd consider L2CAP_SendSDU a "lower level" since I can build up my own L2CAP_SendData function from it. From the API I take it that the max. amount of data I can send with the L2CAP_SendSDU is the MTU of the peer. (otherwise there is an error: bleInvalidMtuSize : SDU size is larger than peer MTU.)

    >> Have you negotiated your MTU for this channel appropriately?
    * as a peripheral I configure the MAX_PDU_SIZE size to 255 (max supported by the stack)
    * I observe MAX_PDU_SIZE to see my MTU is updated to 251

    I was able to receive with a maximum SDU size of 512!

    one question remains: do I have the correct understanding of the not-yet available API call L2CAP_sendData?
  • 0 in reply to Oliver Mueller
    TI__Mastermind 33460 points
    Hi Oliver,

    Your understanding is correct. However, you just have the API names don't correlate exactly to your understanding. L2CAP_SendData is used internally by the BLE-Stack to send data over a fixed channel. This is why it is not a public API and used only internally by the stack. For example ATT and SM will use this API internally for fixed channel traffic.

    >> I mean I expected that I do not need to chunk up my data and reassemble it
    This is correct. And for connection oriented channels, L2CAP_SendSDU is the API you are looking for.
    It will take one SDU (which with the TI BLE-Stack can be up to 512 octets) and it will fragment/segment it into a number of link layer PDUs which can range from 27 to 251. At an application level you should only be presented with complete 512B SDUs.

    Have you negotiated an MTU of 512 for your connection oriented channel? Then you should be able to send this in a single API call from app to stack and the stack should segment the SDU for you.

    In summary: L2CAP_SendData is internal for fixed channel. L2CAP_SendSDU is the correct API for high level usage and should hande segmentation/reassembly for you.
  • 0 in reply to Sean2
    TI__Mastermind 33460 points
    In response to our engagement, I have improve some the L2CAP chapter of our BLE-Stack user's guide:
    dev.ti.com/.../index.html

    Perhaps you might find it helpful. My apologies for the broken images, it is something we are aware of and will fix on the next SDK.
  • 0 in reply to Sean2
    Prodigy 90 points
    thanks Sean, you are most helpful. Also the updated documentation chapter is really nice.