在開發BLE的時候經常會遇到連接突然斷開的情況，比如剛連接上就斷開、連接成功之後傳輸數據隨機斷開（有時候連接很穩定不斷開）。以上這些斷開連接的情況或多或少都遇到過，很是讓人頭疼。當然鹹魚也不例外，也碰到過BLE突然斷開的問題。鹹魚根據自己的經驗做一些這方面的總結，希望能對大家有所幫助。
導致以上問題的原因一般有4種，分別爲：天線匹配、芯片兼容性、連接參數以及代碼邏輯。
對於天線匹配一般嚴格按照官方DEMO板的參考設計不會有什麼問題，可能爲了適應自己板子的要求做了一些修改，可能造成天線匹配問題，造成信號不穩定、信號範圍小等問題，從而導致連接不穩定。這個就需要做阻抗匹配、找天線廠家匹配天線等。另外晶振參數（尤其是頻偏）也可能影響到RF射頻的性能，所以選用晶振的時候最好使用官方DEMO板建議的晶振或者相同參數的晶振代替（頻偏必須一致）。
對於芯片兼容性的問題，可以通過調節連接參數進行改善，如果還不行就只能換一個芯片試一下，或者直接找原廠的FAE吧。
以上兩個原因是硬件問題，只能具體去調試，這裏不做過多說明。下面就重點講一下固件代碼方面的原因，鹹魚就以NORDIC的BLE5.0藍牙SOC——NRF52832官方SDK中的ble_app_uart例程（以下簡稱藍牙串口例程）爲例。
對於連接參數的調節，可能是廣播間隔、最大連接間隔、最小連接間隔、連接監聽時間等，這個可以在代碼中進行調整。在藍牙串口例程中，連接參數都是在main.c文件中以宏定義的形式進行設置，每個宏定義的含義後面都有註釋。如下圖所示：
如果是由於代碼邏輯導致的斷開連接，一般都會觸發看門狗導致芯片復位，所以可以檢測一下斷開連接的時候芯片有沒有復位。一般有兩種情況，一個是剛連接就斷開，在連接成功之後執行的一些代碼有問題，直接排查連接之後執行的函數即可。另一種情況就是連接成功之後，可以傳輸數據，但是會隨機斷開，有時候連接很穩定。尤其對於定時發送數據的時候，當把時間間隔調的長一點時，穩定性明顯提高；時間間隔短的時候穩定性就明顯降低。出現這種情況是因爲BLE將數據發送出去之後需要收到底層的確認信號才能進行下一次發送，如果在沒有收到底層的確認信號就調用發送函數會報錯，從而觸發看門狗復位導致斷開連接。所以在高數據率通信的情況下，調用BLE發送函數之後，一定要在收到底層的確認信號之後才能再次調用BLE發送函數進行下一次數據的發送。以NRF52832的藍牙串口例程爲例，當我們調用發送函數ble_nus_string_send發送函數發送數據之後，如果發送成功則會進入ble_nus_on_ble_evt（串口服務的ble事件中斷），該函數中有一個事件爲發送完成BLE_GATTS_EVT_HVN_TX_COMPLETE，如下圖所示：
可以設置一個標誌位flag，定義的初始值爲1，調用發送函數之前先判斷該標誌位是否爲1，是則調用發送函數發送數據，否則不調用發送函數，每次調用發送函數之後就將該標誌位清零。該標誌位在發送完成的事件函數裏置1，代碼邏輯如下所示：
main.c
......
unsigned char flag = 1;
void user_function(void)
{
......
if(flag)
{
ble_nus_send_string(...);
flag = 1;
}
......
}
ble_nus.c
......
extern unsigned char flag;
void ble_nus_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
......
case BLE_GATTS_EVT_HVN_TX_COMPLETE:
......
flag = 1;
......
break;
......
}
......
對於以上問題可以優先排除連接參數和代碼邏輯問題，因爲這些修改容易、成本低。如果問題依然存在就是天線、兼容性的問題了，後面再集中精力去解決。最後，如果有條件直接聯繫原廠的技術支持是最好的。
更多文章請關注微信公衆號：ubug404
