第1章：冲突现象全景 — 多连接写入失败、数据错乱、连接断开、应用无响应

1.1 现象识别

多连接场景下，数据写入冲突通常表现为四种可观测现象，且往往相互伴发。工程师需首先根据现场症状快速归类，进入对应的排查分支。

1.2 数据采集

在定位根因之前，必须对冲突现场完成系统化数据采集。以下为最低采集清单及标准采集方法。

采集清单

• HCI 日志：开启 HCI_CMD / HCI_ACL / HCI_EVT 全通道导出，时长至少 30 秒复现周期。
• 协议栈内部状态：HEAP_USAGE、FREE_BUFFER_COUNT、L2CAP_QUEUE_DEPTH。
• RTOS 任务统计：每个 BLE 相关任务的 stack_watermark、suspended_time、context_switch_count。
• GATT 操作回溯：记录每次 bt_gatt_write() / bt_gatt_write_without_response() 的入口时间戳和返回错误码。
• 连接参数：所有活动连接的 connection_interval、supervision_timeout、latency。

采集命令示例

# 启用 HCI 日志（Zephyr / NCS 环境）
CONFIG_BT_HCI_HOST_LOG_LEVEL_DBG=y
CONFIG_BT_HCI_RAW_PACKET_LOG=y

# 协议栈内存查看命令（通过 shell 或 debug monitor）
bt stat
bt mem

# RTOS 任务栈水位（CMSIS RTOS2 示例）
osThreadGetStackSpace(ble_main_thread_id);
osThreadGetStackSpace(ble_gatt_thread_id);

1.3 原因定位

基于采集到的数据，使用以下层级判断规则逐步锁定根因。

1.4 修复动作

本章为全景现象识别，尚不深入单个根因的修复。但以下通用修复动作可以在现场即刻执行，缓解绝大多数冲突症状。

• 增大协议栈 buffer 池：将 CONFIG_BT_BUF_ACL_RX_SIZE / CONFIG_BT_BUF_ACL_TX_SIZE 翻倍。
• 降低写入并发度：在每连接写入回调未返回前，不允许该连接发起下一个写请求。
• 添加互斥锁保护：对所有被多连接引用的 GATT 特征值写操作加 mutex_lock() / mutex_unlock()。
• 缩短连接间隔 + 延长监督超时：如当前连接间隔 ≥ 50 ms，尝试降低至 20 ms，同时将 supervision_timeout 从 2 s 调整至 6 s。
• 提升协议栈事件循环优先级：确保 BLE 协议栈任务优先级高于所有应用业务任务，且不被打断超过 5 ms。

1.5 复测

完成以上修复动作后，执行标准化复测场景，验证问题是否彻底解决。

复测场景组合

1. 场景 A：3 个连接同时以最小连接间隔（如 7.5 ms）持续发送 write request，持续 5 分钟。
2. 场景 B：5 个连接混合使用 write request 与 write command，每秒 100 次，持续 10 分钟。
3. 场景 C：极端压力 — 8 个连接，每个连接每秒 200 次 write command，暴露缓冲区和调度极限。
4. 场景 D：长时间稳定性 — 3 个连接持续写入 24 小时，检查无连接断开、无数据错乱、无应用崩溃。

验证方法

• 自动化判断：检查 HCI 日志中无任何 GATT/ATT 错误响应。
• 端到端校验：在接收端（另一个 BLE 设备或 app）对比每次写入的 payload 是否与发送端一致。
• 压力复测循环：四个场景依次执行至少 3 轮，每轮间隔 30 秒复位设备。
• 回归基准：复测通过后，执行一次原问题复现的精确测试用例，确认原现象 0 次出现。

1.6 预防

在后续新项目或固件版本迭代中，从代码和架构层面植入以下预防措施，避免同类问题反复出现。