No response after indication sent

Module: PAN1026

SDK version: 3.4.1

I am occasionally encountering an issue where an indication is sent (TCU_LE_GATT_SER_CHAR_VAL_INDICATION_REQ), but the response is never received (either TCU_LE_ACCEPT or TCU_LE_GATT_SER_CHAR_VAL_INDICATION_EVENT).  I would think the Bluetooth module would provide a timeout after some period, but nothing comes back.  I see a LE_GATT_STATUS_TIMEOUT_OCCURED referenced in tcu_le_gatt_ser_accept_response_handler(), which supports my assumption.  However, a TCU_LE_ACCEPT is never received.

Is it safe to retry the indication at the application layer?

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Michael Hunold Any response to this?  This is really becoming a problem for our application. I can make this happen consistently if I send commands in a loop.

    I am supporting an app development team, and the only workaround for this issue we know of is to power cycle the device and reconnect BLE.

  • For my understanding. Your application is running normally and sending in a loop. For every TCU_LE_GATT_SER_CHAR_VAL_INDICATION_REQ you receive a TCU_LE_ACCEPT and later a TCU_LE_GATT_SER_CHAR_VAL_INDICATION_EVENT.

    Then at some point for a TCU_LE_GATT_SER_CHAR_VAL_INDICATION_REQ no TCU_LE_ACCEPT is received.

    I assume that you have checked that no TCU_LE_ACCEPT is stuck in the UART buffer. Can you confirm this?

    Do you have the chance to monitor the UART line with a bus analyzer and confirm that the TCU_LE_ACCEPT is really not sent by PAN1026A?

  • Yes, my application sends indications until there is no more data to send (this is an adapted SPPoverBLE).  I do normally get the TCU_LE_ACCEPT and then the TCU_LE_GATT_SER_CHAR_VAL_INDICATION_EVENT.  Then when this issue occurs, neither packet is received.

    I'll verify that the UART buffer is empty.  I did check that the UART overrun flag was not set.  I'll also take a look at the UART line - only have an oscilloscope to check though.

  • I applied the patch described in this thread, and can no longer reproduce this issue.  Seems like it was another victim of a buffer overrun.

  • I am glad to hear that this problem is solved as well. Thank you for the feedback.

Like Follow
  • Status Answered
  • 2 yrs agoLast active
  • 5Replies
  • 228Views
  • 3 Following