在开发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
