芯耀
408
引言
客戶的 STM32WB 產(chǎn)品考慮功耗和 OTA 傳輸速率的平衡，在正常工作和做 OTA 升級時會使用兩套不同的 BLE 連接參數(shù)。這就涉及到 BLE 連接參數(shù)更新?？蛻舻膯栴}也正是由更新 BLE 連接參數(shù)引起。連接參數(shù)的更新除了會影響 BLE 的傳輸速率，還需要考慮 OTA接收到數(shù)據(jù)后的擦寫 Flash 操作。
BLE 連接參數(shù)及更新過程
我們先簡單回顧一下影響 OTA 傳輸速率，也就是 BLE 傳輸速率的因素：
- PHY：BLE 的 PHY 是選用 1M, 還是 2M
- DLE: Data length extension 允許數(shù)據(jù)包大小容納更大的負載最大為 251 字節(jié)，禁用時為 27 字節(jié)
- ATT MTU ，當開啟 DLE 時建議最大值設(shè) 247 字節(jié)
- 連接間隔（connection interval），范圍是 7.5ms 至 4000ms
- 連接事件（connection event），每個連接事件的最大數(shù)據(jù)包數(shù)，受限于 BLE 堆棧，Android 和 IOS 設(shè)備會有差異。
- 從機端的間隔喚醒（Slave Latency）: 定義從機可以忽略主機發(fā)起的連接事件數(shù)。
- 發(fā)送數(shù)據(jù)后是否需要 RSP,不需要的時候選用 write without RSP/notify 的方式速度更快。
客戶的應(yīng)用中其 BLE 連接參數(shù)更新其實只涉及 connection interval 和 slave latency 兩個。
問題產(chǎn)生
從上面的描述可知，客戶的程序設(shè)計是每接收到 4KB 數(shù)據(jù)，就要做 BLE 連接參數(shù)的更新。頻繁的 BLE 連接參數(shù)更新會引發(fā)了一些問題。首先是連接參數(shù)更新是由從設(shè)備STM32WB 發(fā)起把更新請求發(fā)給主機，主機收到更新請求后，正常會回一個 response 給從機，告訴從機后面可以按新的連接參數(shù)進行通信。但有些主設(shè)備有可能不支持參數(shù)更新或更新參數(shù)的時機有差異。導(dǎo)致更新失敗。這就產(chǎn)生了兼容性的問題。
問題解決
為了解決 BLE 連接參數(shù)更新帶來的問題。有兩個建議，一個是可以在 OTA 更新數(shù)據(jù)之前將 Flash 區(qū)域提前擦除，后面收到 OTA 數(shù)據(jù)后直接寫 Flash。因為在 BLE 射頻 IDLE 時間內(nèi)寫 Flash 的操作不受限制，這樣就可以不用頻繁更新 BLE 連接參數(shù)，完成 OTA 升級。另一個是建議對于 STM32WB BLE 協(xié)議棧，只要主機對從機更新連接參數(shù)請求有response，從機收到這個 response 后就可以再次發(fā)起連接參數(shù)更新請求，而無需等待30s。這樣也不會影響 OTA 的升級速率。
其實上面是針對使用的是 STM32Cube_FW_WB_V1.8 的協(xié)議棧版本的解決方案，它必須使用 ACI_L2CAP_CONNECTION_PARAMETER_UPDATE_REQ 命令發(fā)送更新請求。
小結(jié)
本文分享了客戶為提升 STM32WB OTA 速率引發(fā)的關(guān)于 BLE 連接參數(shù)更新的討論。最后根據(jù)客戶需要頻繁更新連接參數(shù)，給出了相應(yīng)的處理辦法。以上供大家參考。
