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.

Handle discovering with GATT_DiscAllChars()

Other Parts Discussed in Thread: CC2650, CC2540

Hello,

I saw many and many other topics with the same subject but no one is reponding to my issue.

I'm using the CC2650 with a central and tried to discover the 5th "simple profiles" of my peripheral.

To do that I did on the SimpleBLECentral_handleKeys() :

if (keys & KEY_DOWN)
{

     if (state == BLE_STATE_CONNECTED)
     {
        status = GATT_DiscAllChars(connHandle,(uint16_t)0,(uint16_t)65000,selfEntity);
     }
}

And on the  SimpleBLECentral_processGATTMsg() I add a case with the ATT_READ_BY_TYPE_RSP answer which gives :

static void SimpleBLECentral_processGATTMsg(gattMsgEvent_t *pMsg)
{

static uint8_t led;

  if (state == BLE_STATE_CONNECTED)
  {
    // See if GATT server was unable to transmit an ATT response
    if (pMsg->hdr.status == blePending)
    {
      // No HCI buffer was available. App can try to retransmit the response
      // on the next connection event. Drop it for now.
      Display_print1(dispHandle, 4, 0, "ATT Rsp dropped %d", pMsg->method);
    }

    else if ((pMsg->method == ATT_READ_RSP)   ||
             ((pMsg->method == ATT_ERROR_RSP) &&
              (pMsg->msg.errorRsp.reqOpcode == ATT_READ_REQ)))
    {
      if (pMsg->method == ATT_ERROR_RSP)
      {
        Display_print1(dispHandle, 4, 0, "Read Error %d", pMsg->msg.errorRsp.errCode);
      }
      else
      {
        // After a successful read, display the read value
    	led=pMsg->msg.readRsp.pValue[0];
    	Display_print1(dispHandle, 6, 0, "Nombre valeurs lue: %d", pMsg->msg.readByTypeRsp.numPairs);
        Display_print1(dispHandle, 4, 0, "Read rsp: %d", led);
      }

      procedureInProgress = FALSE;
    }
    else if ((pMsg->method == ATT_WRITE_RSP)  ||
             ((pMsg->method == ATT_ERROR_RSP) &&
              (pMsg->msg.errorRsp.reqOpcode == ATT_WRITE_REQ)))
    {
      if (pMsg->method == ATT_ERROR_RSP)
      {
        Display_print1(dispHandle, 4, 0, "Write Error %d", pMsg->msg.errorRsp.errCode);
      }
      else
      {
        // After a successful write, display the value that was written and
        // increment value
        Display_print1(dispHandle, 4, 0, "Write sent: %d", charVal++);
      }

      procedureInProgress = FALSE;

    }
    else if (pMsg->method == ATT_FLOW_CTRL_VIOLATED_EVENT)
    {
      // ATT request-response or indication-confirmation flow control is
      // violated. All subsequent ATT requests or indications will be dropped.
      // The app is informed in case it wants to drop the connection.

      // Display the opcode of the message that caused the violation.
      Display_print1(dispHandle, 4, 0, "FC Violated: %d", pMsg->msg.flowCtrlEvt.opcode);
    }
    else if (pMsg->method == ATT_MTU_UPDATED_EVENT)
    {
      // MTU size updated
      Display_print1(dispHandle, 4, 0, "MTU Size: %d", pMsg->msg.mtuEvt.MTU);
    }
    else if (discState != BLE_DISC_STATE_IDLE)
    {
      SimpleBLECentral_processGATTDiscEvent(pMsg);
    }
    else if (pMsg->method == ATT_READ_BY_TYPE_RSP)
    {
  	  Display_print1(dispHandle, 6, 0, "Nb valeurs lue: %d", pMsg->msg.readByTypeRsp.numPairs);
    }
  } // else - in case a GATT message came after a connection has dropped, ignore it.

  // Needed only for ATT Protocol messages
  GATT_bm_free(&pMsg->msg, pMsg->method);
}

I never saw the case with ATT_READ_BY_TYPE_RSP works so I took the CC2540miniDK dongle and used it as sniffer (BTW I hope to use the CC2540 dongle isn't bad to work with CC2650)

I got five "ATT_READ_BY_TYPE_RSP" and took the screen :

I'm joinning you the file which contains the record of this picture (Open with Packet Sniffer from TI).

handle.psd

I need to understand 2 things here :

1/ Why did I never get the "ATT_READ_BY_TYPE_RSP" case on my SimpleBLECentral_processGATTMsg() function ?

2/ Can I read the handles of my 5 simpleprofiles from the sniff ?

Thank you by advance.

Best regards,

John.

  • PS : when I do : status = GATT_DiscAllChars(connHandle,(uint16_t)0,(uint16_t)65000,selfEntity);
    status is equal to success
  • From a brief readover it appears you are doing everything correct here. I'll need to set up a similar test to answer more.

    Yes, you should be able to read the handles from the sniffer.
  • Hi John,

    We have replicated your issue using the modifications you made to SimpleBLECentral on the CC2650EM and the SimpleBLEPeripheral project running on the CC2650LP. I will let you know when we have more information.

  • Hi John,

    I was able to successfully send a Read By Type Request by changing the Starting Handle to 1. Can you make that change to your code and see if that fixes the issue?
  • Hi RachelP,

    Thank you about your research and your answer and sorry about the long respond time.

    It's working better but not completely right. Indeed, I now have my "ATT_READ_BY_TYPE_RSP" case but i only read 3 pair numbers, I should have 5 isn't it ?
     

    I made some research on my side about the sniffer BLE but I was unable to get our the handles from the the sniff I posted early, if you can help me about that i should be able to see which simpleprofile are missing.

    Best regards,

    John

  • Hi John,

    I would suggest you take a look at Vol 3, Part F, Section3.4.4 of the Bluetooth Core Specification v4.2. That will explain how Read By Type Requests and Responses are structured.

    For example, in your sniffer capture, the first characteristic handle you discovered was 0x0002. I think the reason you are only seeing 3 pairs is that you are only displaying the number of pairs in one data packet.

    If I do a complete characteristic discovery on the SimpleBLEPeripheral project using BTool, I can discover 17 characteristics which matches the output from your sniffer log. If you only want to discover the "Simple Profile Characteristics", you will need to change your the handle range in your GATT_DiscAllChars call.

  • Hi RachelP,

    Thank you about all these explanations, seems really clearly now and it works !


    Best regards,
    John