CC2745R10-Q1: On the usage issue of the L2CAP sending API

Hi, Nima

I have a question regarding the sample code in the reference documentation. After executing L2CAP_bm_alloc in the sending function, memory is only released when the send operation fails. Could this potentially cause issues (e.g., memory overflow) when sending bulk data?

bStatus_t Application_sendL2capData(void)
{
  l2capPacket_t pkt;
  bStatus_t status = SUCCESS;

  // Tell L2CAP the desired Channel ID
  pkt.CID = cocCID;

  // Allocate space for payload
  pkt.pPayload = L2CAP_bm_alloc(sizeof(appData));

  /* Copy payload data */
  memcpy(pkt.pPayload, appData, sizeof(appData));

  if (pkt.pPayload != NULL)
  {
    pkt.len = (sizeof(appData));

    // Print transmit data to serial terminal, expected data is /0 terminated
    MenuModule_printf(11, 0, "L2CAP Data TX - %s", pkt.pPayload);

    // Send packet
    status = L2CAP_SendSDU(&pkt);

    // Check that the packet was sent
    if (SUCCESS != status)
    {
      // If SDU wasn't sent, free
      BM_free(pkt.pPayload);
    }
  }
  else
  {
    status = bleMemAllocError;
  }

  return (status);
}

Best regards!

Preston

Hi, Nima

Additionally, I would like to confirm: Have the Bluetooth functionalities between CC2745 and CC2340 (including device pairing and L2CAP data transmission) been properly tested and verified as operational?

CC2340 SDK version:8.20.0.119

Best regards!

Preston

Hello,

Peisheng Yang said:

I have a question regarding the sample code in the reference documentation. After executing L2CAP_bm_alloc in the sending function, memory is only released when the send operation fails. Could this potentially cause issues (e.g., memory overflow) when sending bulk data?

The developer is in charge of managing this memory:

For data packet payloads, the higher level protocol (ATT, SM, Application) is responsible for allocating using L2CAP_bm_alloc(...). In the case of ATT and SM, this is done transparent to the user. For CoC SDUs, the user owns the memory associated with the payload.

However, you raise a good point in the reference code. That packet should be free'd regardless of whether it was successful or not.

Peisheng Yang said:

Additionally, I would like to confirm: Have the Bluetooth functionalities between CC2745 and CC2340 (including device pairing and L2CAP data transmission) been properly tested and verified as operational?

I would recommend using the latest version of the SDK (8.40 at the time of writing this), especially if you're using the CC2745. Are you running into an issue?

Best,

Nima Behmanesh

Hi, Nima

I'm establishing a Bluetooth connection between CC2745 and CC2340 for L2CAP data transmission. After transferring approximately over 1KB of data (with a maximum single-frame payload of around 100+ bytes), the L2CAP transmission failed. During debugging on the CC2745 side, the program consistently hangs at osal_start_system().

Does the BLE enter some abnormal state? Could there be compatibility issues when connecting and transmitting data between different SDK versions?

Best regards!

Preston

Hello,

Do you mind attaching the callstack? osal_start_system() is called to start the tasks and the scheduler. A callstack will provide me the information needed to see what's going on the CC2745.

Best,

Nima Behmanesh

Hi, Nima

How can I obtain the callstack information?

Best regards!

Preston

Hello,

By debugging the project, the debug window should open. In the upper left hand, there should be a callstack.

Best,

Nima Behmanesh

Hi, Nima

Is this the one?

After sending data via L2CAP that caused an exception, the system repeatedly stalled at osal_start_system(). The initialization appears to have failed, and Bluetooth advertising was terminated(CC2745).

Best regards!

Preston

Hello Preston, 

I have been re-assigned to the ticket. I apologize for the delay in response. 

I am going to look through the location in the call stack you are seeing. To clarify, are you freeing the memory after a successful or unsuccessful attempt? The problem seems like it could be a memory leak of some sort, which would more than likely mean the packet memory is not being freed after the L2CAP transaction. 

Additionally, communicating between two different SDKs is not a problem. At the end of the day, both SDKs comply with the Bluetooth specification. 

Thanks, 

Isaac

Hi, Isaac

Memory will be freed whether the operation succeeds or fails. Memory will be re - requested the next time data needs to be sent. I think my handling method is correct, but I don't know why it causes a memory leak. May I ask what methods can be used for troubleshooting?

Best regards!

Preston