关于ble产品出现死机时的问题分析（2020-10-20）

                                   关于ble产品出现死机时的问题分析

最近做的一个ble产品，在开发过程中出现了概率性极低的死机现象，大概2%，很是头痛。但不管怎样，既然出现问题，我们就要从源头找到原因。死机无外于这两种大的方向：软件死机和硬件死机。 以下是我的分析思路： 

1. 软件死机
   • While死循环：这个是可以通过看门狗处理掉的。但是现在程序中是有看门狗的，所以这个原因可以排除。
   • While死循环里面有喂狗语句：这个看门狗处理不了。我看了程序，应用端的代码里面while循环里面有好几处都有喂狗语句，同时也有退出循环的条件判断，应该不会一直处于死循环。而且即使是出现死循环，晶振还是会起振的，然而在复现死机的时候有测过设备的晶振是不起振的，所以这个也可以排除。
   • Suspend： 从目前抓到的两次log来看都是进入suspend后没有退出，再根据晶振不起振的现象，问题很有可能是设备进入suspend后，（suspend是一种ble产品的低功耗模式）切换了时钟，降到了一种功耗比较低的运行频率，然而再退出suspend无法再切换回原来正常工作时的时钟。目前看软件配置是没有问题的，不会造成suspend不正常。

 

     2. 硬件死机

              硬死看门狗是解决不了的，只能通过断电来解决。比如：引脚电平超过芯片引脚的极限电平，或者晶振不良等原因造成硬死。

    

       所以，判断方向是硬件晶振不起振造成的死机。对程序进行修改，底层会判断晶振是否正常工作，当出现问题时会在特定的flash位置进行写flag。这样有一个好处，就是当设备再次起来广播时，我可以去指定地址读取是否有死机的标志，然后广播。通过nrf connect工具可以扫描出来，而且对于这种概率极低的死机现象，可以方便做大批量测试。最后在产线几百台设备测试的情况下，发现了几台flag异常的设备，从而验证了猜测是对的。