芯耀
386
問題背景
客戶使用 BlueNRG-345MC 開發(fā)了一個 BLE 外設(shè)，和手機(jī)連接。在測試中發(fā)現(xiàn)，手機(jī)連接上外設(shè)之后，不斷地在手機(jī)上點擊藍(lán)牙的開關(guān)按鈕，造成設(shè)備不斷地斷開、重連；少則幾次，多則幾十次。點擊之后，必然出現(xiàn) BLE 外設(shè)無廣播信號的現(xiàn)象。該問題已經(jīng)得到了解決。本文將展開聊聊該問題的解決過程和思路，并就該問題總結(jié)、分享一些 BLE 連接過程的處理經(jīng)驗。
定位問題
拿到該反饋描述后，第一時間和客戶溝通了幾個問題，明確了大概的方向。溝通的思路按照：硬件問題、軟件問題？硬件問題是和設(shè)備相關(guān)，板子相關(guān)、還是芯片相關(guān)？軟件問題根據(jù)設(shè)備類型，是和 APP 相關(guān)、手機(jī)系統(tǒng)相關(guān)、BLE 主機(jī)固件相關(guān)、還是 BLE 外設(shè)固件相關(guān)這樣的思路進(jìn)行排查。通過以下問題，粗略地進(jìn)行問題的定位：
“對端設(shè)備是什么，如果是手機(jī)的話，是否有 APP？“——對端是手機(jī)，并且有配套的APP。該問題確定了設(shè)備類型，和軟件類型。
“該問題是否必現(xiàn)，且穩(wěn)定復(fù)現(xiàn)，問題出現(xiàn)后，狀態(tài)是否能保持？“——問題穩(wěn)定復(fù)現(xiàn)且必現(xiàn)，而且狀態(tài)能保持，這是一個重要的依據(jù)，由此依據(jù)，我們可以進(jìn)一步發(fā)問：
“殺死配套 APP 的后臺，用其它手機(jī)、第三方 APP（BLE 調(diào)試助手等）是否能搜到設(shè)備的廣播信號“——殺死配套 APP 的后臺，確保設(shè)備斷連、處于廣播狀態(tài)，然后通過第三方的手機(jī)、APP 搜索設(shè)備的廣播，確定當(dāng)問題出現(xiàn)后，出現(xiàn)異常的是主機(jī)方、還是從機(jī)方?？蛻舴答伒谌?APP 搜索不到該設(shè)備，說明此時從機(jī)方出現(xiàn)了異常且保持在異常狀態(tài)中。
“問題出現(xiàn)后，設(shè)備是否還能正常運行“——確定了從機(jī)方出現(xiàn)異常后，我們需要進(jìn)一步定位該異常。該問題可確認(rèn)問題是局部問題，還是系統(tǒng)問題。如果此時系統(tǒng)還能正常運行（比如，有 LOG 輸出，有 LED 閃爍，有按鍵反應(yīng)等），就說明是局部問題，系統(tǒng)還沒死機(jī)?？蛻舴答佅到y(tǒng)還正常，這真是一個好消息！藍(lán)牙問題最怕是系統(tǒng)性的問題，即因為系統(tǒng)奔潰，導(dǎo)致的藍(lán)牙奔潰，如果是系統(tǒng)性的問題，那可能性就多很多了，丟給客戶的問題就可能包括：
“是否和低功耗管理有關(guān)，關(guān)掉低功耗試試？”
“是否和特定板子有關(guān)，換塊板試試？”
“是否和供電穩(wěn)定性有關(guān)，用直流電源試試？電量低是否更容易復(fù)現(xiàn)？”……
既已確定了是局部藍(lán)牙的問題，那么，如果對藍(lán)牙的 LL 狀態(tài)機(jī)和基本的 GAP 流程熟悉的話，那基本就可以通過這個問題來定位該問題了：
“請仔細(xì)檢查下用戶層的操作邏輯，是否能確保藍(lán)牙斷連時，必能調(diào)用使能廣播的 API，且拿到成功的狀態(tài)返回？”——客戶拿到該問題后，不知道從何下手，于是，現(xiàn)場支持。
BLE 背景知識
話接上文，解決該問題需要對 LL 狀態(tài)機(jī)和 GAP 流程有一定的了解。本章節(jié)便先對相關(guān)背景知識先做一個補(bǔ)充陳述。
藍(lán)牙鏈路層（Link Layer）的運轉(zhuǎn)過程可通過一個狀態(tài)機(jī)進(jìn)行描述。
對于該狀態(tài)機(jī)的理解，需要注意以下幾點：
- 設(shè)備斷開連接之后，LL 層進(jìn)入的是 Standby 狀態(tài)，而不會自動重新發(fā)起廣播，此時必須由 Host 主動啟動廣播才能讓設(shè)備被主機(jī)搜索到。
- 設(shè)備處于 Standby 狀態(tài)時，必須先進(jìn)入廣播狀態(tài)，才能由此進(jìn)入連接狀態(tài)。對于從機(jī)，如果設(shè)備不進(jìn)入廣播狀態(tài)，即使主機(jī)發(fā)起回連，也不可能被連接成功。
- 廣播中的設(shè)備，當(dāng)它被上層停止廣播、或者被主機(jī)連接時，便會退出廣播狀態(tài)。此處需要注意的是，當(dāng)鏈路建立，協(xié)議棧會將鏈路建立事件層層上傳，其中，就包括 GAP層 。GAP 層在接收到鏈路建立事件之后，便會開始執(zhí)行一系列的流程……
這些流程包括，特性交換流程，MTU 交換流程，連接參數(shù)更新流程，安全流程（配對流程、綁定流程、加密流程），GATT 服務(wù)發(fā)現(xiàn)流程等。剛連上那會的幾秒鐘，是 BLE 外設(shè)最繁忙的時間段，也是最容易出現(xiàn)問題的時間段。有經(jīng)驗的工程師，一般都會將一些時間敏感的任務(wù)的處理，和這段時間段進(jìn)行錯開。
解決問題
相信通過 BLE 背景知識的介紹，部分人已經(jīng)大概了解了問題的原因了。到達(dá)客戶現(xiàn)場調(diào)試時，通過藍(lán)牙抓包器、并讓客戶當(dāng)場復(fù)現(xiàn)問題，我把藍(lán)牙主、從機(jī)的空中交互過程記錄下來。仔細(xì)觀察抓包器的記錄過程，發(fā)現(xiàn)當(dāng)問題發(fā)生時，斷開連接的事件出現(xiàn)得非常早期：在鏈路建立、特性交換流程剛執(zhí)行完后，即發(fā)生了斷連。
小結(jié)
藍(lán)牙協(xié)議棧是個分層的協(xié)議，當(dāng)我們說藍(lán)牙已連接時，想表達(dá)的意思應(yīng)該是鏈路層鏈路建立，而現(xiàn)實中，很多工程師都把藍(lán)牙已連接理解成了可以收、發(fā)數(shù)據(jù)了。實際上，從藍(lán)牙鏈路建立，到協(xié)議?？梢詾橛脩魧邮?、發(fā)數(shù)據(jù)，中間還差了十萬八千里。總而言之，從本文的解題思路出發(fā)，我總結(jié)以下幾點經(jīng)驗：
- 用戶程序應(yīng)該深刻理解“藍(lán)牙已連接”的概念， 做好狀態(tài)管理。
- 鏈路建立后是藍(lán)牙最繁忙的時刻，用戶任務(wù)處理應(yīng)盡可能避開該時間段。
- 加快鏈路建立繁忙時間段的方法包括：
o 鏈路建立后，使用較快的連接間隔，并在之后調(diào)慢以平衡功耗
o 使用 GATT CACHING 特性
