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.

Using GATT_Notification on CC2650

Other Parts Discussed in Thread: CC2540, CC2541

Hy there,


I successfully developed an application on CC2540, that uses multiple calls to GATT_Notification to transfer some kBytes. Now, I try to port this application to C2650. Unfortunately, it does not work instantly...

For one, I have noticed, that the attHandleValueNoti_t struct definition has changed: In th CC2540 code, the value portion is defined as 20byte array within the struct, now, the data is only a pointer. Any reason for that?

And when I call GATT_Notification, nothing happens. What could I do wrong?

uint8 notifyData[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xA, 0xB, 0xC, 0xD, 0xE, 0xF, 0x10, 0x11, 0x12, 0x13};
static void sendData(void )
{
  uint16_t gapConnHandle;
  GAPRole_GetParameter(GAPROLE_CONNHANDLE, &gapConnHandle);
  attHandleValueNoti_t nData;
  nData.len = 20;
  nData.handle = 0x24;   // handle of LYTENPROFILE_ACCDEBUG UUID. Don't know how to find out dynamic handle yet.
  nData.pValue = notifyData;
  //memcpy( nData.pValue, scanRspData, nData.len); // not used any more, because struct contains pointer rather than allocated memory
  // Send the Notification
  GATT_Notification( gapConnHandle, &nData, FALSE );
}

  • Hello Harald,
    Have you tried to look at the implementations in these functions:
    gattServApp_SendNotiInd()
    OAD_getNextBlockReq()
    They call on GATT_bm_alloc()
  • Hy Eirik,

    thanks a lot for your help! This brought me in the correct direction.

    The solution consists of several changes:

    - use nData.pValue = GATT_bm_alloc(connHandle,ATT_HANDLE_VALUE_NOTI, 20, NULL); to allocate memory

    - use the correct handle: In my old version, the "handle" seemed to be the index of the attribute table, now it became the address. Right?

    gattAttribute_t *pAttr = GATTServApp_FindAttr(dataProfileAttrTbl, GATT_NUM_ATTRS(dataProfileAttrTbl), dataProfileReadPage);
    nData.handle = pAttr->handle;

    - Need to double check, if notifications are enabled for this characteristic. In the old version, I just called the GATT_Notification function, no matter if notify was enabled or not and I always received the messages in BTool. Now, my whole program crashes when I call the function without having set notification.

    So at this moment it works OK, but there are still some questions:

    - I call GATT_bm_alloc, but never GATT_bm_free. Is this OK? Or when should I call GATT_bm_free?

    - At this moment I call GATT_Notification in a for loop 4 times and again after a 40ms timer. With this, I get a transfer speed of approx 800 Byte/s. What parameters would I need to change to have faster speeds?

    Best regards

    Harald

  • Hello. The stack will call GATT_bm_free so you do not need to. To get the highest throughput, you could just continuously call GATT_Notification in an infinite (or as long as possible if this is not simply a test) loop. You should also be using the smallest possible connection interval (7.5 ms). Of course doing this will likely cause bm_alloc to fail since you will run out of buffer space but you can simply retry in this case. You should also be checking the return value of GATT_notification.
  • Hello Tim.

    I'm trying to solve a similar problem I have with notifications.

    I believe I've wrote my notification related code quite identical to the gattServApp_SendNotiInd() example, and also to the other demo projects which include notification (HeartRate, Glucose meter).
    However, once I enable notification, my FW stops respoding after ~1 minute.
    I've found that this corresponds to my event-loop period (1 sec), and my allocation size (3 bytes). Allocating in a while-loop fails after 79 allocations (equal to 1 minute and 19 seconds).

    This leads me to think that the Stack is not calling on GATT_bm_free, or is failing the de-allocation.

    How can I verify that the stack is indeed deallocating the notification associated memory allocations?

    Thanks

    Koby
  • Sorry.
    Bug on my part.
    De-alloc is indeed called by the Stack....
  • Thank you,
    I will probably attempt this throughput on the CC2541 (my current BLE uC), BLE Stack 1.4.1.

    Any chance to know the software & device used to generate the throughput logging ? A TI tool?

    processors.wiki.ti.com/.../Throughput3.png

    Best regards,

    Koby