v1.0.3 未能解决问题，并出现credit持续缓慢下降，重新连接蓝牙无法恢复

[ldbds]

故障表述 v1.0.3 版本程序。 下载文件过程中仍有概率丢包。下载文件速度为0。 调试日志显示 credit 持续缓慢下降。 不同于 #36， 重新连接 蓝牙无法恢复此故障。

开启debug调试测试，除了观察到 credit 持续下降，还出现 hardfault 问题。 故障位置为 SPI flash read。 推测为 堆栈溢出故障， 考虑加大 STACK 空间。

复现流程

下载大文件，长时间运行即出现

期望行为

场景截图

固件版本

• 硬件版本 [v10.1]
• 软件版本 [v0.6.6.2]

• 其他备注

[ldbds]

1. 调试中发现，当前蓝牙协议栈，如果在发送notify的发送回调中获取credit，wds_credits 数据会有概率不正常， 甚至可能出现 11 （默认 FIFO 最大 10）。推测协议栈有缺陷。

2. 此蓝牙协议栈以连接间隔为周期进行消息集中处理，间隔约为20ms。每个间隔处理的notify命令回调 为 3~6个 ，不稳定。

3. 发生credit丢失时，位于 sppdebug 通道 发送 notify 响应的位置 。猜测 发送 notify 操作 和 notify 发送成功回调 底层的不良实现导致 多个操作对 credit 的修改发生竞争。

4. credit丢失时，查看蓝牙HCI日志， 发现蓝牙 HCI 缺少一包 filedata 数据 offset '7764'。 该 filedata 包 是倒数第8个数据包。 倒数第8个transmit 发送时间是 11-04#22:03:51.612 127。 猜测数据包有如下对应关系：

其中 148 数据 offset '7764' 数据包 被 175 数据 offset ‘7850’ 的数据包 代替。 实际向

时刻 11-04#22:03:51.627 的 处理内容较为反常，依次处理了以下数据消息：

• filedata transmit
• SPPDEBUG access write
• SPPDEBUG access write respond
• filedata callback
• filedata callback
• sppdebug transmit
• filedata transmit

[ldbds]

给 SPPDEBUG NOTIFY 的 函数调用 加锁 后 ，没有再出现上述问题。