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.

Receiving L2CAP data/events also calls HCI_ACL_Data_callback() ?

Other Parts Discussed in Thread: MSP430F5438A, CC2564

Hi community,


I'm working on a project using the CC2564 on a TiWi-uB2 Module on an MSP430F5438A.

We're using HCI to synchronize a sensor network of MSP430's.

Parallely, I'm working on a streaming functionality using L2CAP. I've discovered that whenever an L2CAP event/data is received, L2CAP_Event_Callback() is called first and after that HCI_ACLDataCallback() is called.

If it was an L2CAP data packet that was just received, the first 4 bytes of the HCI ACLData[] array contain the L2CAP payload length and the L2CAP CID of the sender. Then the L2CAP payload follows.


This behavior makes kind of sense, since L2CAP is located above HCI and therefore all L2CAP data is passed through HCI (I guess). But it also causes serious problems: HCI_ACLDataCallback() now receives data that it shouldn't receive and which is in a structure that it will misinterpret.

Is there a way to tell the HCI driver (or anything else) that HCI_ACLDataCallback() should only be called, if an actual HCI packet was received?

Thank you!

Samuel

  • Hi Samuel,

    I'm not familiar with the APIs you mentioned. Can you clarify the stack you're using (and the version of it)?
    Are you referring to the L2CA_Register_PSM() and HCI_Register_ACL_Data_Callback() APIs of the TI Bluetooth stack?

    If so, then if you don't need the ACL data callback you can choose not to call HCI_Register_ACL_Data_Callback()

    Regards,
    Gigi Joseph.
  • Hi Gigi,


    thanks for your fast reply!

    We're using Bluetopia Stack v1.5 R2 for MSP430 (LargeMTU, coffabi) from www.ti.com/.../CC256XMSPBTBLESW.

    You're right:

    We call HCI_Register_Event_Callback() and HCI_Register_ACL_Data_Callback() and establish an HCI connection between two MSP430F5438A microcontrollers.

    Then we call L2CA_Register_PSM() on our "Coordinator"-uC and L2CA_Connect_Request() on our "Slave"-uC. L2CAP connection gets established without problems.

    Now we get the problem, that incoming L2CAP data (independently from the actual L2CAP event) calls the HCI data callback function that was registered using HCI_Register_ACL_Data_Callback().

    We can't unregister the HCI data callback function though. We planned to use HCI for our synchronization algorithm and L2CAP for data streaming. Of course this won't work if the HCI data callback function is called for incoming L2CAP data.

    Is there a way to block HCI data callback for L2CAP packets? Or to clearly identify data as L2CAP data and discard it within HCI data callback?

    Thanks!

    Samuel

  • Hi Samuel,

    Thanks for the clarification.
    Can you share some details about the HCI synchronization algorithm? I believe you can add some mechanism in your algorithm to distinguish between the synchronization packets and the ACL data.

    Regards,
    Gigi Joseph.
  • Hi Gigi,

    I myself don't work on the synchronization but on the streaming interface. I just know that synchro uses HCI/ACL and streaming uses L2CAP.

    It all comes down to the question if the the stack can distinguish between L2CAP data and HCI/ACL data automatically and only call the corresponding callback function. Or if we have to deal with the fact that both HCI/ACL and L2CAP data trigger the HCI/ACL data callback function. Do you have an answer to that?

    If the latter is the case, we will (obviously have to) find a solution. To me it just seems counterintuitive that incoming L2CAP data would trigger the HCI/ACL callback function, so that was my first approach.

    Thank you!

    Samuel

  • Hi Samuel,

    Please note that all L2CAP data packets are also HCI/ACL data packets.
    The HCI layer expects two types of packets:

    (1) Event packet that you can hook with HCI_Register_Event_Callback()
    (2) An ACL data packet (which as per the BT spec is also an L2CAP packet).

    The stack can distinguish between the two. What you've implemented with " HCI synchronization algorithm" is something that I don't understand. Are you sure it's an ACL data? If so, what sort of a profile/protocol connection you have with the remote device. You can as well have an ACL connection, but for data transfer, you must have an L2CAP channel. In which case, you'll still get both callbacks.

    Regards,
    Gigi Joseph.
  • Hi Gigi,

    thanks for your patience.

    We're working on a body sensor network. The sensor nodes all record different types of data, like one node records ECG, another oxygen saturation etc. Sampling is triggered by timers with a fixed frequency. But on different nodes the clock drifts are also different, which results in asynchronous data streams. In order to compare or combine data from different nodes, we need to synchronize the clocks on the nodes.
    We implemented a custom-made synchronizing algorithm which definitely uses only ACL data packets.

    I'm not sure if I can follow this sentence: "If so, what sort of a profile/protocol connection you have with the remote device. You can as well have an ACL connection, but for data transfer, you must have an L2CAP channel"
    I thought ACL is a protocol. Then the protocol we are using would be ACL.
    Also, data transfer works for us even without L2CAP. We just call HCI_Send_ACL_Data() on one device and the HCI callback function on the other device gets called. Are you sure that data transfer is only possible with L2CAP?

    Regarding L2CAP:
    We just call L2CA_Register_PSM() on one device and L2CA_Connect_Request() on the other device. The Callback function that we took from the following discussion handles the rest:
    e2e.ti.com/.../777269

    Looking forward to your answer!
    Regards, Samuel