No TCU communication after disconnect

Module:  PAN1026

SDK: 3.4.1

I have encountered an issue where occasionally a remote client disconnects from my custom service and fails to restart advertising (advertising must be restarted after disconnect on a rev 501 ROM).  Digging into this, I can see that when this occurs, the TCU circular buffer's uart_flag gets set to 1 but never gets reset.  It appears that right before disconnect, a TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ message was sent. The disconnect event came in before the response was received and left the circular buffer locked up with uart_flag = 1.

The current implementation in tcu_mng_le_disconnect_event_handler() makes a call to tcu_reset_circular_buff_status(), which only clears the uart_flag if there is nothing in the circular buffer to be sent.

What is the proper way to reset uart_flag after a disconnect, so that I can continue communicating with the PAN1026?

6replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • This problem was reported for SDK v3.2 and according to Toshiba is resolved in later versions.

    Can you please check that in your implementation of  tcu_le_gatt_ser_accept_response_handler() the if condition labeled as Handle response received after disconnection has a call to  tcu_clear_stored_request() ?

    This will make sure to reset the uart_flag in the end.

    If the problem persists, this might be a similar bug, but not the same.

    I will ask you to create a meaningful debug output for Toshiba to analyze then.

    Reply Like
  • Michael,

    Yes, the call to tcu_clear_stored_request() is present in that response handler, under several circumstances.

    Here's the sequence of messages up to the disconnect event that I'm seeing:

    rx: 12 00 00 d3 c3 0b 00 01 00 11 02 03 00 03 00 26 20 01   <= TCU_LE_GATT_SER_WRITE_CHAR_VAL_EVENT (remote client write)
    tx: 12 00 00 d3 25 0b 00 11 02 07 00 03 00 03 00 26 20 01   <= TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ
    rx: 08 00 00 d3 a5 01 00 00                                 <= TCU_LE_GATT_SDB_UPD_CHAR_ELE_RESP
    tx: 11 00 00 d3 06 0a 00 01 00 21 02 02 00 02 00 26 10      <= TCU_LE_GATT_SER_CHAR_VAL_INDICATION_REQ (response to remote client via indication)
    rx: 0a 00 00 d1 f1 03 00 00 d3 06                           <= TCU_LE_ACCEPT
    tx: 0c 00 00 d3 03 05 00 01 00 00 11 02                     <= TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_REQ
    rx: 0a 00 00 d3 46 03 00 01 00 00                           <= TCU_LE_GATT_SER_CHAR_VAL_INDICATION_EVENT
    rx: 0a 00 00 d3 83 03 00 01 00 00                           <= TCU_LE_GATT_SER_WRITE_CHAR_VAL_ACCEPT_RESP
    rx: 12 00 00 d3 c3 0b 00 01 00 11 02 03 00 03 00 26 20 00   <= TCU_LE_GATT_SER_WRITE_CHAR_VAL_EVENT (remote client write)
    tx: 12 00 00 d3 25 0b 00 11 02 07 00 03 00 03 00 26 20 00   <= TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ (uart_flag = 1 and never cleared)
    rx: 0b 00 00 d1 93 04 00 01 00 00 13                        <= TCU_MNG_LE_DISCONNECT_EVENT
    
    

    Here are the commands still queued in the circular buffer, which are never sent (or remain marked active):

    12 00 00 D3 25 0B 00 11 02 07 00 03 00 03 00 26 20 00       <= TCU_LE_GATT_SDB_UPD_CHAR_ELE_REQ (waiting on TCU_LE_GATT_SDB_UPD_CHAR_ELE_RESP?)
    11 00 00 D3 06 0A 00 01 00 21 02 02 00 02 00 26 10          <= TCU_LE_GATT_SER_CHAR_VAL_INDICATION_REQ
    12 00 00 E1 3D 0B 00 03 FC 08 00 D1 D4 58 05 00 00 00
    12 00 00 E1 3D 0B 00 03 FC 08 00 D1 94 49 05 00 00 00
    56 00 00 d1 08 4f 00 40 00 40 00 00 00 00 00 00 00 00 00 00 07 00 1b 02 01 01 11
       07 1b c5 d5 a5 02 00 03 a9 e3 11 8b aa a0 c6 79 e0 05 03 00 18 0a 18 00 00 00
       00 0f 0e 09 50 43 41 34 30 30 2d 2a 2b 2a 2b 2a 2b 00 00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00                                     <= TCU_MNG_LE_START_ADVERTISE_REQ
    Reply Like
  • The Toshiba support team have acknowledged that there is a buffer overflow scenario for PAN1026. This problem will be solved in the next SDK version.

    They explained that the workaround you described is not sufficient and have developed a different fix to address the situation.

    I guess you want that fix now, so please mail us at  wireless@eu.panasonic.com so I can share the details with you. I am sorry for the inconvenience, but due to data protection laws we are not allowed to directly write a mail to the address that you used for the forum registration.

    Reply Like
  • A note to anybody else reading this issue:

    The fix is to change the file tcu_internal.h.

    The following line

    #define MAX_GAP_REQ (1 + MAXIMUM_DEVICES)

    needs to be replaced with

    #define MAX_GAP_REQ (2 + (2 * MAXIMUM_DEVICES))

    Reply Like
  • Michael Hunold I sent an email to that address, but never received a reply.  Is there more to do than increasing MAX_GAP_REQ?

    Reply Like
  • Got the email, thanks.  I haven't seen this issue happen since applying the patch.

    Reply Like
reply to topic
Like Follow
  • Status Answered
  • 6 mths agoLast active
  • 6Replies
  • 156Views
  • 2 Following