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?
-
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 -
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 -
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 -
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 -
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 -
Got the email, thanks. I haven't seen this issue happen since applying the patch.
Reply
