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.

CC2640R2F: No Write response with Android O

Part Number: CC2640R2F

Hi Team,

   When TV write stop command to CC2640R2F RC, RC does NOT respond to write request to TV. SDK version is cc2640r2_sdk_1_50_00_58, host is AndroidO.

 

   Write charactoristic with response is used. Log file is as below.v02.2_pairThenVoiceVoice.cfa.zip

  • Hi Holly,

    It looks like you're in the middle of streaming of voice at this time.

    Sometimes it can be difficult to get the response enqueued while performing high throughput applications using the stack.

    Is the customer's application processing blePending when receiving GATT messages? See a relevant code snippet from simple_peripheral.c::SimpleBLEPeripheral_processGATTMsg

      if (pMsg->hdr.status == blePending)
      {
        // No HCI buffer was available. Let's try to retransmit the response
        // on the next connection event.
        if (HCI_EXT_ConnEventNoticeCmd(pMsg->connHandle, selfEntity,
                                       SBP_HCI_CONN_EVT_END_EVT) == SUCCESS)
        {
          // First free any pending response
          SimpleBLEPeripheral_freeAttRsp(FAILURE);
    
          // Hold on to the response message for retransmission
          pAttRsp = pMsg;
    
          // Don't free the response message yet
          return (FALSE);
        }
      }

    In summary, sometimes the GATT server cannot enqueue the message to be sent by the lower stack layers and in this case the stack will send a GATT message to the application where the application will have to store any messages with status blePending for further response in the stack.

    If a blePending message is received, the application should stop streaming voice and attempt to resend the packet (you can copy the simple_peripheral application for reference. Once the message is sent successfully, the voice stream can be resumed. Synchronous ATT traffic should always be prioritized if possible over notifications.