• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 50 subscribers
  • Views 1212 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.

Bug in GATT_ReadUsingCharUUID, fails to send bleProcedureComplete status

Richard Dolf
Expert 2170 points

My central device is using the GATT_ReadUsingCharUUID() API in order to discover characteristic handles on the peripheral device. This all works great when successful, but the stack behavior is inconsistent when the peripheral device fails the read request.

The normal sequence of events is:
- Application issues GATT_ReadUsingCharUUID() request.
- Application receives GATT_MSG_EVENT, method==ATT_READ_BY_TYPE_RSP, gattStatus==SUCCESS, with the characteristic handle
- Application receives GATT_MSG_EVENT, method==ATT_READ_BY_TYPE_RSP, gattStatus==bleProcedureComplete

When the peripheral fails the read request with status ATT_ERR_UNSUPPORTED_REQ
- Application issues GATT_ReadUsingCharUUID() request.
- Application receives GATT_MSG_EVENT, method==ATT_ERROR_RSP, response error code is 0x2 (ATT_ERR_READ_NOT_PERMITTED)
- Application receives GATT_MSG_EVENT, method==ATT_READ_BY_TYPE_RSP, gattStatus==bleProcedureComplete

When the peripheral fails the read request with status ATT_ERR_INSUFFICIENT_RESOURCES
- Application issues GATT_ReadUsingCharUUID() request.
- Application receives GATT_MSG_EVENT, method==ATT_ERROR_RSP, response error code is 0x11 (ATT_ERR_INSUFFICIENT_RESOURCES)
<the end>
** There are no further GATT_MSG_EVENTS, leaving the application waiting forever for ATT_READ_BY_TYPE_RSP with bleProcedureComplete status

The bug is that GATT_ReadUsingCharUUID() at times fails to send the GATT_MSG_EVENT with status=bleProcedureComplete.  The result is that the application is screwed because it can't know for sure when the transaction has been completed and the stack ready for another request.

  • 0
    Expert 2170 points

    Reviewing the GATT_ReadUsingCharUUID() API, I see that:

    This sub-procedure is complete when either ATT_READ_BY_TYPE_RSP
    * (with SUCCESS or bleTimeout status) or ATT_ERROR_RSP (with
    * SUCCESS status) is received by the calling application task.

    In both ATT_ERROR_RSP cases I experience, status==SUCCESS, so perhaps the bug is that the 1st fail case sends an additional GATT_MSG_EVENT with status==bleProcedureComplete (since sub-procedure was already complete by virtue of the error response with status==SUCCESS).

    In any case, the stack is behaving inconsistently, depending on the specific error code sent by peripheral device.

    Why doesn't the documentation mention the bleProcedureComplete status?  It seems that bleProcedureComplete really marks the end of the procedure because if I don't wait for this status, the next call to GATT_ReadUsingCharUUID() returns blePending status.