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.

cc2540连续工作时间长了,数据吞吐量会变小??

Other Parts Discussed in Thread: CC2540

我的应用是每s传输3k字节的数据量

现象:丢包,经过反复测试发现刚开始几个小时是不丢包的,十个小时后开始丢包,而且是因为带宽不够丢的包。 

           硬件复位CC2540,又可以持续几个小时不丢包。

分析:初步怀疑里面有堆栈申请没有释放

处理: 

     将g_nData.pValue = (uint8 *)GATT_bm_alloc( 0, ATT_HANDLE_VALUE_NOTI, GATT_MAX_MTU, &len );改为

g_nData.pValue = (uint8 *)GATT_bm_alloc( 0, ATT_HANDLE_VALUE_NOTI, 20, &len );

  测试发现,没有作用

内存释放是这样的,应该没有问题,抄的TI的demo

if(GATT_Notification( 0, &g_nData, FALSE )!=SUCCESS)
{//发送失败

GATT_bm_free( (gattMsg_t *)&g_nData, ATT_HANDLE_VALUE_NOTI );

  • 协议栈用的是BLE-CC254x-1.4.2.2,不会是协议栈里面的bug搞出来的事吧

  • GATT_bm_alloc和GATT_bm_free为什么不是标准的成对出现?

    发送出错才释放内存?

    发送成功就不需要释放内存了?有或者在GATT_Notification函数里隐蔽地释放了?

  • 可否用TI的吞吐量例程来测试一下: http://processors.wiki.ti.com/index.php/CC2540_Data_Throughput

  • wiki那个例程还是低版本协议栈的,不需要动态分配内存。

  • 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.

    You can refer below code:

    static void SimpleBLEPeripheral_blastData()
    {
      // Subtract the total packet overhead of ATT and L2CAP layer from notification payload
      uint16_t len = MAX_PDU_SIZE-TOTAL_PACKET_OVERHEAD;
      attHandleValueNoti_t noti;
      bStatus_t status;
      noti.handle = 0x1E;
      noti.len = len;
    
      // Store hte connection handle for future reference
      uint16_t connectionHandle;
      GAPRole_GetParameter(GAPROLE_CONNHANDLE, &connectionHandle);
    
      while(1)
      {
        // If RTOS queue is not empty, process app message.
        // We need to process the app message here in the case of a keypress
        while (!Queue_empty(appMsgQueue))
        {
          sbpEvt_t *pMsg = (sbpEvt_t *)Util_dequeueMsg(appMsgQueue);
          if (pMsg)
          {
            // Process message.
            SimpleBLEPeripheral_processAppMsg(pMsg);
    
            // Free the space from the message.
            ICall_free(pMsg);
          }
        }
    
        noti.pValue = (uint8 *)GATT_bm_alloc( connectionHandle, ATT_HANDLE_VALUE_NOTI, GATT_MAX_MTU, &len );
    
        if ( noti.pValue != NULL ) //if allocated
        {
    
          // Place index
          noti.pValue[0] = (msg_counter >> 24) & 0xFF;
          noti.pValue[1] = (msg_counter >> 16) & 0xFF;
          noti.pValue[2] = (msg_counter >> 8) & 0xFF;
          noti.pValue[3] = msg_counter & 0xFF;
    
          // Attempt to send the notification
          status = GATT_Notification( connectionHandle, &noti, GATT_NO_AUTHENTICATION);
          if ( status != SUCCESS ) //if noti not sent
          {
            PIN_setOutputValue(hSbpPins, Board_LED1 , Board_LED_ON);
            GATT_bm_free( (gattMsg_t *)&noti, ATT_HANDLE_VALUE_NOTI );
          }
          else
          {
            // Notification is successfully sent, increment counters
            PIN_setOutputValue(hSbpPins, Board_LED2 , Board_LED_ON);
            msg_counter++;
          }
        }
        else
        {
          // bleNoResources was returned
          asm(" NOP ");
        }
    
        // Reset debug pins
        PIN_setOutputValue(hSbpPins, Board_LED1 , Board_LED_OFF);
        PIN_setOutputValue(hSbpPins, Board_LED2 , Board_LED_OFF);
      }
    }

    https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/411466/1461483

  • 我仔细核对了,就是那样写的。可能以前就参考的那个。

    现在没法定位问题了。