• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 4424 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.

CC2640: GATT_Notification() responses with blePending

Ming Leung50
Intellectual 720 points
Other Parts Discussed in Thread: CC2541, CC2640

I called this API to send char notification:

bStatus_t GATT_Notification( uint16 connHandle, attHandleValueNoti_t *pNoti, uint8 authenticated );

I got quite a lot of 0x16 as a return code, which indicates blePending. 

How do I check the pending status turning to complete? Normally, GATT_Notification() doesn't come with a ATT response, like GATT_Indication() does. 

And what happen if I ignore the blePending and start sending another notification? Would it cause a previous or current packet dropped? And this is the problem (pkt loss) I am seeing kind of.

We used this API in CC254x and never see a problem. It would return MSG_BUFFER_NOT_AVAIL to indicate no room to send, and just have to retry.

thanks,

../ming

  • 0
    TI__Guru** 105180 points
    Hello Ming,

    Did you try increasing the MAX_NUM_PDU to see if you are enqueuing too many notifications before they are sent over the air?

    Best wishes
  • 0 in reply to JXS
    Intellectual 720 points
    Hi JXS,

    Increasing the MAX_NUM_PDU can only deal with the burst traffic, not the sustaining traffic. I need a mechanism to slow down my send requests, or better way to say, to adapt to the OTA outgoing rate. I need GATT_Notification(), through return code, rsp msg, or callback, to tell me the send request was not successful because no more buffer was available. Then I will retry right after or some time later.

    In CC2541, the GATT_Notification() will response MSG_BUFFER_NOT_AVAIL as return code and it works perfectly well. What is the equivalent in CC2640?

    ../ming
  • 0 in reply to Ming Leung50
    TI__Mastermind 29650 points

    Hi Ming,

    The CC2640 stack will also return MSG_BUFFER_NOT_AVAIL if the Icall Heap alloc fails through gattIndNoti(). See ICallBleAPI.c for implementation details. You might need to increase HEAPMGR_SIZE as well if you still see an issue. MAX_NUM_PDU is an additional layer buffering up TX packets.

    Notifications does not return a success status once transmitted over the air and acknowledget but I think Indications will do that.

    .:svend

  • 0 in reply to svendbt
    Intellectual 720 points

    Hi Svend,

    It looks like the MSG_BUFFER_NOT_AVAIL return code for GATT_Notification() in CC2541 and CC2640 stack has different practical meaning. In CC2541 it means tnotification PDU buffer is full, while in CC2640 it means there is no memory can be allocated from the heap to just send the request to the stack. My issue is I need the status of "notification PDU buffer is full", which CC2640 stack seems not providing.

    However, I suspect the "blePending" return code (which this question was originally asked) is indeed the indication of "notification PDU buffer is full". So I make my code to resend the notification when blePending is returned, just like what it does in CC2541 when MSG_BUFFER_NOT_AVAIL is returned.  Guess what, in the transmission test, I got the same in and out bytes counts and the data integrity is 100%. Therefore, that blePending return code does mean "notification PDU buffer is full".

    ../ming