BLE模组工作异常问题

BLE_001

　　背景

　　某用户使用我司E系列BLE蓝牙模组来配置DTU设备，近期反馈蓝牙模组在有一定比例典型现象为待机功耗高，手机搜不到蓝牙广播，还有模块无法识别串口指令

　　过程

　　一、没拿到异常板子时的排查方法

　　1、针对手机搜不到蓝牙广播问题：推荐客户使用手机APP去连接模块，看是否能搜到模块广播信息？主要看是模块自己未发出广播包，还是，模块发出了但是由于信号差，手机没接收到？通过看广播包信号强度是多少，来判断模块的射频部分是否正常？（安卓用nRF Connect，苹果用Light Blue）

　　AN-5108 2款常见BLE调试APP简介——nRF Connect、Light Blue

　　用户反馈，手机紧挨着模块时，也无法搜到模块广播。据此推断模块可能硬件坏了，或软件上根本没有处于广播态。

　　2、针对待机功耗高问题：推荐用户将异常模块吹下后，不仅要换一个新模块上去试试，还要单独测一下此异常模块的电流，拿1个全新模块进行相互对比。

　　用户反馈，换上新模组后，电流就降低成正常水平了，但是没有对此异常模块做进一步测试。

　　3、针对有模块无法识别串口指令问题：

　　●首先，怀疑原理图设计是否有误？

　　具体可以看出，BT_CTL蓝牙控制引脚默认接GND，MODE_CTL模式控制引脚、PWR_CTL休眠控制引脚默认接VCC，即模块上电默认处于开启广播、透传模式、低功耗状态，且这3个控制引脚都分别接到了MCU上控制。

　　RST引脚外部接VCC，上电模块正常运行。

　　TX、RX引脚也是接VCC，外部直接上拉至高电平。（推荐有条件的客户如此操作）

　　总结，客户原理图设计是OK的。

　　●其次，怀疑是代码处理是否有误。具体可能是用户误在PWR_CTL脚为高电平时，即模块在低功耗模式下给模块配置指令（MCU发指令模块确实不回），所以推荐用户自行排查代码，也可用逻辑分析仪来抓板子上模块各引脚波形，提供给我司分析，我们从中可清晰的看出MCU与模块之间的交互情况。

　　客户也可单独测试吹下来的此模块，断开与MCU之间的连接，具体可通过USB转串口工具连到PC上，串口调试助手发给模块指令，看模块是否有回复？

　　二、拿到板子排查方法

　　1、 分析几片异常模块，主要查串口指令是否识别、平均功耗和双向数据通信是否正常这3个方面。

　　注意：
　　●开始测试前，需弄清楚出现异常时，模块的几个控制引脚分别是什么电平？
　　●需额外拿一片正常模块做对比项。

　　测试条件如下：
　　BT_CTL=0，开启蓝牙
　　MODE_CTL=1，透传
　　PWR_CTL=1，休眠（即低功耗模式）

　　使用仪器：功耗测试仪（能保存一段时间内电流波形）、USB转串口工具、PC+串口调试助手、手机nRF Connect APP。

　　2、 使用功耗测试仪给模块3.3V供电，模块串口经USB转串口工具接到PC，上电后，看功耗测试仪上是否出现广播电流波形？并记录下此时广播电流、广播间隔，这个电流值是正常的。

　　同时，手机APP开启扫描，手机靠近蓝牙模块，看能否搜到此模块？记录下广播名称、广播包RSSI值。

　　3、手动让PWR_CTL=1，进入唤醒状态；MODE_CTL=0，进入指令模式，透传串口调试助手给模块发“MAC地址查询指令”，看返回值MAC地址跟手机APP扫描到的广播包MAC地址是同一个吗？是的话，说明手机扫描到的就是此模块。无返回值的话，说明模块串口确实有异常。

　　注意：事先需跟用户确认，是否有修改过模块的串口波特率。

　　4、 透传模式下，手机APP去连接模块，看是否能连接成功？连接成功的话，记录下此时的连接电流、连接间隔，这个值也是正常的。连接失败的话，截图记录下手机APP的log，看是主、从机谁主动断开了连接，连接断开原因是什么。

　　5、手机APP给模块发一串数字，看PC串口调试助手是否收到？串口调试助手发另一串数字，看手机APP是否收到？通过双向通信是否畅通，来判断是哪一环节出了问题。

　　手机APP在“Device Information"服务通道，查询得到模块固件版本号，并记录。

　　注意：手机APP必须事先开始notify使能，才能收到数据。

　　至此，可看出：
　　●1号模块存在的问题，是底电流偏高。
　　●2号模块存在的问题，是底电流偏高且发射功率偏低。
　　●3号模块存在的问题，是上电后代码没有跑起来，导致无广播，也连接不上，串口也无返回。

　　6、对于1、2、3号模块底电流偏高，2号模块发射功率偏低的问题，给它们烧录定频固件（模块单纯处于发射、接收、休眠状态，只射频部分工作），看发射功率、电流是否正常，如果正常，那么跟硬件关系不大，需从软件方面分析。如果电流异常，比如一直保持底电流，无发射电流出现，那么说明模块硬件有问题，可能是芯片被损坏（比如说静电、外力破坏，操作不当VCC与GND之间短路引发大电流等原因）。

　　从上，可看出：
　　●1、2号模块的射频电流都正常，说明底电流的来源是CPU部分带来的，2号模块发射功率底，可能是天线或其他射频部分有损坏导致的。
　　●3号模块代码烧不进去，说明芯片内部flash可能被损坏了。

　　7、对于3号模块串口无返回，进一步排查原因： 把模块内部代码读出来，首先跟标准固件进行对比，看是否完全相同？一般有以下几种情况：一是J-link识别不到芯片，那么怀疑芯片内部flash出故障了。二是，能连接上，但是读出来的代码跟标准固件相对比，发现有些字节变掉了，那么怀疑是烧录环节出了问题，或者是固件bug，或者是外力导致flash这部分字节变掉了。三是，能连接、代码也能读出来，且跟标准固件一模一样，那么怀疑是固件串口代码部分有bug。

　　说明，3号模块的芯片内部flash确实已被损坏。

　　8、拓展：分析到这一步，如果出现读异常模块内部flash代码，跟标准固件完全一样，那么可采用烧录更新版本固件来验证，看是不是此版本的固件有bug。

　　结论

　　本次3个异常模块，原因分析如下：
　　●1、2号模块的底电流偏大，怀疑原因是静电或操作不当导致芯片CPU部分有短路。
　　●2号模块的发射功率偏低很多，怀疑原因是天线或其他射频部分，使用过程中被损坏。
　　●3号模块完全没有工作起来，原因是flash硬件被损坏掉了。