BLE data is lost when writing to an Indication (Server to Client transfer)

[JHedgesBartec]

Answers checklist

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

AT+GMR

AT+GMR
AT version:3.5.0.0-dev(8bfb16f - ESP32C6 - Jan 6 2025 09:10:51)
SDK version:v5.1.5-196-g64849cb703-dirty
compile time(5302cdc78ac8f28a28a20c9b6a83e8760bd6e7dd):Jan 29 2025 11:35:15
Bin version:v1.0.1.1(ESP32C6-4MB)

OK

ESP-AT Firmware Source

Compiled from master but with AT lib patched with a version provided by an Espressif employee to fix an issue with characteristics and pairings

Hardware Information

ESP32-C6 connected to STM32F1x microcontroller automating commands and data transmission

Power Supply used

External 3.3V

What is the expected behavior?

When the AT+BLEGATTSIND returns OK the module is ready to receive more data and data can be sent without loss

What is the actual behavior?

When using AT+BLEGATTSIND to send data to a client, waiting for OK then writing new data without time delay, the data can be lost and the connection is closed within 30 seconds after the last attempt of data transfer.
Reason for closed connection is 534

Note this is not seen with an iPhone, but is seen regularly with Windows as the client.

Adding a delay, tested at 50ms, between commands then there is no data loss, proving that even when the OK is received, the ESP32-C6 is not ready to receive more data.
Indications require a confirmation from the connected client, this should be used to return OK.

Probability of recurrence

1 in 5
Normally when sending data that is MTU-3 followed by new data

AT+SYSRAM?

AT+SYSRAM?
+SYSRAM:235640,223692
OK

Steps to reproduce

1. Initialise the ESP32 as a BLE server
2. Establish a connection between a windows client and the server
3. Send multiple packets of data out from the BLE server using AT+BLEGATTSIND
4. Not all packets are received by the client
5. After approximately 30 seconds the connection is closed by the ESP32

AT command port output

ESP-AT >> (00135716ms) AT+BLEGATTSIND=0,1,2,23
ESP-AT << (00135726ms) 
ESP-AT << (00135734ms) OK
ESP-AT >> (00135749ms) AT+BLEGATTSIND=0,1,2,200
ESP-AT << (00135761ms) 
ESP-AT << (00135768ms) OK
ESP-AT >> (00135777ms) AT+BLEGATTSIND=0,1,2,13
ESP-AT << (00135787ms) 
ESP-AT << (00135795ms) OK
ESP-AT >> (00135817ms) AT+BLEGATTSIND=0,1,2,16
ESP-AT << (00135826ms) 
ESP-AT << (00135834ms) OK
ESP-AT << (00166172ms) +WRITE:2
ESP-AT << (00166182ms) 
ESP-AT << (00166192ms) +BLEDISCONN:0,"d4:54:8b:fd:6d:0c"

AT log port output

ESP-DEBUG >> (00165992ms) subscribe event; conn_handle=0 attr_handle=8 reason=2 prevn=0 curn=0 previ=1 curi=0
ESP-DEBUG >> (00166000ms) handle = 8 , ret_node->handle=65535
ESP-DEBUG >> (00166006ms) handle = 8 , ret_node->handle=16
ESP-DEBUG >> (00166015ms) handle = 8 , ret_node->handle=65535
ESP-DEBUG >> (00166021ms) handle = 8 , ret_node->handle=65535
ESP-DEBUG >> (00166032ms) handle = 8 , ret_node->handle=20
ESP-DEBUG >> (00166038ms) handle = 8 , ret_node->handle=65535
ESP-DEBUG >> (00166048ms) handle = 8 , ret_node->handle=65535
ESP-DEBUG >> (00166053ms) get node by handle fail
ESP-DEBUG >> (00166063ms) subscribe event; conn_handle=0 attr_handle=20 reason=2 prevn=0 curn=0 previ=1 curi=0
ESP-DEBUG >> (00166069ms) handle = 20 , ret_node->handle=65535
ESP-DEBUG >> (00166079ms) handle = 20 , ret_node->handle=16
ESP-DEBUG >> (00166085ms) handle = 20 , ret_node->handle=65535
ESP-DEBUG >> (00166097ms) handle = 20 , ret_node->handle=65535
ESP-DEBUG >> (00166103ms) handle = 20 , ret_node->handle=20
ESP-DEBUG >> (00166113ms) disconnect; reason=534 handle=0 our_ota_addr_type=0 our_ota_addr=4083b0bb:00:15:4082c000:00:42176c70
ESP-DEBUG >> (00166120ms)  our_id_addr_type=0 our_id_addr=4083b0ad:00:15:4082c000:00:42176c70
ESP-DEBUG >> (00166133ms)  peer_ota_addr_type=0 peer_ota_addr=4083b0c2:00:15:4082c000:00:42176c70
ESP-DEBUG >> (00166141ms)  peer_id_addr_type=0 peer_id_addr=4083b0b4:00:15:4082c000:00:42176c70
ESP-DEBUG >> (00166153ms)  conn_itvl=48 conn_latency=0 supervision_timeout=960 encrypted=1 authenticated=1 bonded=1

More Information.

There is no log port output whilst transmitting data, only when the connection is closed by the ESP32