LAT1371 关于STM32WB OTA 速率提升引发的讨论

引言

客户的 STM32WB 产品考虑功耗和 OTA 传输速率的平衡，在正常工作和做 OTA 升级时会使用两套不同的 BLE 连接参数。这就涉及到 BLE 连接参数更新。客户的问题也正是由更新 BLE 连接参数引起。连接参数的更新除了会影响 BLE 的传输速率，还需要考虑 OTA接收到数据后的擦写 Flash 操作。

BLE 连接参数及更新过程

我们先简单回顾一下影响 OTA 传输速率，也就是 BLE 传输速率的因素：

• PHY：BLE 的 PHY 是选用 1M, 还是 2M
• DLE: Data length extension 允许数据包大小容纳更大的负载最大为 251 字节，禁用时为 27 字节

• ATT MTU ，当开启 DLE 时建议最大值设 247 字节
• 连接间隔（connection interval），范围是 7.5ms 至 4000ms
• 连接事件（connection event），每个连接事件的最大数据包数，受限于 BLE 堆栈，Android 和 IOS 设备会有差异。

• 从机端的间隔唤醒（Slave Latency）: 定义从机可以忽略主机发起的连接事件数。

• 发送数据后是否需要 RSP,不需要的时候选用 write without RSP/notify 的方式速度更快。

客户的应用中其 BLE 连接参数更新其实只涉及 connection interval 和 slave latency 两个。

问题产生

从上面的描述可知，客户的程序设计是每接收到 4KB 数据，就要做 BLE 连接参数的更新。频繁的 BLE 连接参数更新会引发了一些问题。首先是连接参数更新是由从设备STM32WB 发起把更新请求发给主机，主机收到更新请求后，正常会回一个 response 给从机，告诉从机后面可以按新的连接参数进行通信。但有些主设备有可能不支持参数更新或更新参数的时机有差异。导致更新失败。这就产生了兼容性的问题。

问题解决

为了解决 BLE 连接参数更新带来的问题。有两个建议，一个是可以在 OTA 更新数据之前将 Flash 区域提前擦除，后面收到 OTA 数据后直接写 Flash。因为在 BLE 射频 IDLE 时间内写 Flash 的操作不受限制，这样就可以不用频繁更新 BLE 连接参数，完成 OTA 升级。另一个是建议对于 STM32WB BLE 协议栈，只要主机对从机更新连接参数请求有response，从机收到这个 response 后就可以再次发起连接参数更新请求，而无需等待30s。这样也不会影响 OTA 的升级速率。

其实上面是针对使用的是 STM32Cube_FW_WB_V1.8 的协议栈版本的解决方案，它必须使用 ACI_L2CAP_CONNECTION_PARAMETER_UPDATE_REQ 命令发送更新请求。

小结

本文分享了客户为提升 STM32WB OTA 速率引发的关于 BLE 连接参数更新的讨论。最后根据客户需要频繁更新连接参数，给出了相应的处理办法。以上供大家参考。