Wait for nRF52 BLE client data before sending queued frames

This commit is contained in:
mikecarper committed 2026-10-19 13:12:54 -07:00
1 parent c557d96bf0
commit 85a786e796
4 files changed
+119 -3

No files matched your search

+12
View File
@@ -1033,6 +1033,10 @@ size_t SerialBLEInterface::writeBleUartFrame(const Frame& frame) {
const uint16_t mtu = conn->getMtu();
if (mtu <= 3) return 0;
#if defined(MESH_NRF52_BLE_TRACE) && MESH_NRF52_BLE_TRACE
// Record only public framing metadata, never characteristic payload data.
meshBleTrace(0xf036, handle, frame.buf[0] | (frame.len << 8), mtu);
#endif
// BLEUart::write() reports either the full requested length or zero, even
// when its internal multi-notification loop queued an earlier fragment
@@ -1293,6 +1297,14 @@ size_t SerialBLEInterface::checkRecvFrame(uint8_t dest[]) {
return 0;
}
// Restored bonded subscriptions can be enabled while the client is still
// discovering services and negotiating its MTU. An unsolicited push at the
// default MTU can exhaust the notification slots partway through a frame.
// The independent UART RX callback (or explicit mOTA activation) establishes
// application readiness. Keep queued frames and their TX watchdog idle until
// then; the secured-link no-data timer still bounds an abandoned connection.
if (!_companionDataSeen.load(std::memory_order_acquire)) return 0;
if (send_queue_len > 0) {
if (!isConnected()) {
BLE_DEBUG_PRINTLN("writeBytes: connection invalid, clearing send queue");