ESP-IDF中NimBLE协议栈Peer.c断言失败问题分析与解决方案

问题背景

在ESP32-C3设备作为BLE中央设备（Central）与Silicon Labs BG22外设（Peripheral）进行通信时，部分用户报告在设备服务发现过程中出现了断言失败的问题。该问题表现为随机性崩溃，触发点在Peer.c文件的第328行assert语句，发生频率较低（约每月2次）。

问题现象

从日志分析可以看出，当ESP32-C3设备作为BLE中央设备启动并与BG22外设建立连接后，在服务发现过程中出现了异常。具体表现为：

1. 连接建立成功
2. 配对过程完成
3. MTU更新事件正常处理
4. 开始服务发现过程
5. 在特性发现阶段触发断言失败

根本原因分析

经过深入分析，发现问题根源在于：

1. BG22外设在某些异常情况下（如低电压重启）可能发送不正确的服务信息
2. 当服务发现过程中收到的svc_start_handle与现有服务列表不匹配时，会导致peer_chr_add函数中的断言触发
3. 这种情况通常发生在服务器端提供错误值的情况下，特别是在非正常断电或低电压重启场景

解决方案

官方提供了以下修复方案：

1. 将原来的断言失败改为错误处理机制
2. 增加对服务句柄有效性的检查
3. 当发现无效服务句柄时，输出错误日志并终止当前发现过程

核心修改是将peer.c中的：

assert(0);

改为：

MODLOG_DFLT(ERROR, "Service with start_handle=0x%04x not found!", svc_start_handle);
return BLE_HS_EINVAL;

验证结果

经过修改后测试验证：

1. 在40多次重新绑定连接（通用广播）或重新连接（定向广播）测试中未再出现断言失败
2. 通过模拟BG22外设低电压重启场景，能够稳定复现错误情况
3. 修改后的代码能够正确识别错误并输出日志，而非直接崩溃

最佳实践建议

对于使用ESP-IDF NimBLE协议栈的开发者，建议：

1. 在BLE中央设备实现中增加对服务发现错误的处理逻辑
2. 对于关键业务场景，考虑实现重试机制
3. 设备供电设计应确保稳定，避免因电压不稳导致的通信异常
4. 定期检查并更新ESP-IDF版本，获取最新的稳定性修复

总结

该问题展示了BLE通信中服务发现过程的一个边界情况处理缺陷。通过将断言改为适当的错误处理，显著提高了系统的鲁棒性。这种修改方式不仅解决了特定场景下的崩溃问题，也为处理类似通信异常提供了更好的实践模式。