• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 746 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.

limits on radio buffers in cc2540

Anthony Ambuehl
Expert 1010 points


I recently enabled characteristic value notifications in my application on several different attributes.  I noticed that when 4+ values change at the same time I start getting MSG_BUFFER_NOT_AVAIL error status returned byGATTServApp_ProcessCharCfg. 

My questions:

* What is the size limit that triggers the MSG_BUFFER_NOT_AVAIL return code.

* Is it based on # of bytes or # of packets ? 

* Is there anyway to increase the size or to enable buffering using the osal_memory dynamic memory allocations?

Here is an example code:

  // See if Notification has been enabled
      stat = GATTServApp_ProcessCharCfg( qqqqConfigCoordinates, (uint8 *)&qqqqCoordinates,
                                    FALSE, qqqqAttrTbl, GATT_NUM_ATTRS( qqqqAttrTbl ),
                                    INVALID_TASK_ID );
      if (stat!=SUCCESS) lastqqqqErrorStatus = stat;

I see the lastqqqqErrorStatus == 4.

According to comdef.h:

/*** Generic Status Return Values ***/
#define SUCCESS                   0x00
#define FAILURE                   0x01
#define INVALIDPARAMETER          0x02
#define INVALID_TASK              0x03
#define MSG_BUFFER_NOT_AVAIL      0x04
#define INVALID_MSG_POINTER       0x05
#define INVALID_EVENT_ID          0x06
#define INVALID_INTERRUPT_ID      0x07
#define NO_TIMER_AVAIL            0x08
#define NV_ITEM_UNINIT            0x09
#define NV_OPER_FAILED            0x0A
#define INVALID_MEM_SIZE          0x0B
#define NV_BAD_ITEM_LEN           0x0C

  • 0
    TI__Guru 57865 points

    Hi Anthony,

    I think (for BLEv1.2.1) that you can queue 60 bytes or something like that. So assuming you have three notifications with 20 bytes, it makes sense. If you have less bytes in the notifications, you should be able to queue up more. There is a possibility that there might by stuff left in the notification buffer before you start queuing new ones, do you have control of that?

    Best Regards 

  • 0 in reply to J Lindh
    Expert 1010 points

    Is the actual amount of data buffer documented somewhere?   How much overhead does each characteristic change incur?

    I am surprised to discover it is this limited.  I believe the example stack can support multiple devices getting notification changes.  Seems like if a single attribute has 3-4 subscribers then it would be possible that a change notification would use all buffer space and not reach all devices.  Is there some other indication for dropped messages besides the return value from GATTServApp_ProcessCharCfg?  How would I know which devices received the notification and which did not? 

  • 0 in reply to Anthony Ambuehl
    Expert 1010 points

    BUMP.

    I would still like to know:

    What are the limits for tx transmission triggered by GATTServApp_ProcessCharCfg ?

    Is it a number of packets limit or is it a number of bytes limit?

  • 0 in reply to Anthony Ambuehl
    TI__Guru 57865 points

    Hi Anthony,

    I do not know the details more than it's 60-80 byte application data tops, but I am sure is a byte limitation.

    Best Regards

  • 0 in reply to J Lindh
    Expert 1010 points

    My application was only sending 3-1 byte notifications and 4-4 byte notifications in a time instant.  I believe after 3 notifications all remaining data was dropped.  So I suspect the 60-80 byte limit includes some overheads or is actually a packet limit. 

    Also this limit is extremely low, is there any plan to provide some additional buffering in the cpu?  Especially considering if I am using ProcessCharCfg  then its not possible for me to know which devices received notifications and which did not.  I believe ProcessCharCfg  will fail any time 4 devices are configured to receive value change notifications or an time 2 devices with 2 value changes occur in one time slice. 

    Take for example TI's accelerometer profile.  If 2 devices register for characteristic change notification and then the device is moved, there will frequently be dropped notification changes.