接着上回继续分析公司遗留的问题三分析，问题三就蛮棘手的，因为是隐性问题，不容易复现，有时候，一个月才复现一次，出现这样的问题给定位带来了很大的困难，首先说一下我们产品的掉线、重连机制。
产品掉线重连机制：设备正常通信的时候倒还好，如果出NWK_ERROR_ASSOC_CNF_DENIED情况，也就是失网的情况下，停止设备上报数据，初始化网络，进入NLME_OrphanJoinRequest状态，重新加入之前的网络，如果一段时间没有重新入网成功，就一段时间之后复位，为了低功耗，我们重新入网的时间一分钟，失败就进入低功耗模式，一个小时之后复位重新连接，避免环境差的情况一直不停的入网、重新，降低电池使用寿命
问题现象：1、一部分设备掉线后一个晚上才能重新连上来，也就是我们说的重新入网，速度很慢，很少一两个小时就能上来的，理论上一个小时复位重连一次，基本上一两个小时应该能连上来的；2、有极少设备掉线后就一直上不来，也就是不能自恢复重新入网。
问题难度点：1、偶发现象，不一定多久才能出现，多大概率才能出现。2、关键困难的地方是该设备没有预留串口debug，只能通过抓包分析，增加了调试难度。
首先遇到这样的问题很棘手，要冷静分析，我想了分五个步骤去分析解决：1、既然是偶发现象，就增大偶发概率，以前失网后入网，失败后进入低功耗模式，一个小时复位重连，把一个小时改成2分钟；2、很多设备失网后重新入网慢，从逻辑上分析，如果把失网后入网慢这个问题解决了，也有概率解决了不能自恢复重新入网的问题，即使解决不了不能自恢复的问题，也会增快复现速度；3、模拟还原现场环境，拿一个密封的水壶，把设备放进去信号就屏蔽，过一小段时间就会掉线，因此把设备不断的入网、掉线、重新入网，抓包分析；4、拿一部分设备引出debug串口，接入电脑，用seacurCRT,长期debug存下log日志；5、拿出不能自恢复重入网的设备，按下按键复位，抓包分析原因。
因为不能自恢复现象出现概率很小，因此先易后难，先步骤2调查重新入网速度过慢的原因，同时采取1、3、4方法为辅助。
经过抓包以及打印发现，失网后NLME_OrphanJoinRequest收到回复后，就走NLME_ReJoinRequest的流程了，但是这个函数返回错误概率很高(这个应该就是TI的BUG，很早就听闻CC2530的坑比较多)，一旦出错，就直接初始化网络ZDApp_NetworkInit，这里就有个问题，之前的代码为了做低功耗，防止代码一直不停的初始化网络，在初始化网络ZDO_NETWORK_INIT事件内，加入了限制，条件允许的时间可以入网，不允许不能入网，防止一直耗电。如下图
而zdappNwkReinitTimeout在开机初始化时候置位并定时5秒钟，因此如果一次失败，就入不了网，只能等待下次复位重连了，修改后，掉线后重连入网速度快了很多，此外，修改后，不能自恢复的问题复现速度也增快了很多，同时采取步骤3不久就出现了有大约6个不能自恢复的设备，我拿下来一一抓包分析。
6个不能自恢复的设备拿出来经过debug与抓包分析，发现了不能自恢复主要有两个原因造成的：1、该设备居然连接到其他网关上了，读取该设备flash里NV信息，居然有另一个网关MAC地址；2、该设备一直不停的NLME_ReJoinRequest，返回值一直是错误，重连不了。
问题1：经过分析，之前代码里有个BUG，一旦中间掉线几次后，有一条件触发重新加入网络(不是Orphan以及ReJoin流程，而是beacon以及Join流程)，如果其他网关处于绑定阶段就可以直接绑定，关联到其他网关上。修改部分：在代码里重新入网，加上限制，不是随便找任何一个网络关联，而是入之前的网络，代码如下：
问题2：这个是TI的CC2530的BUG，NLME_ReJoinRequest会概率性的一直返回错误，估计里面状态位出问题了，后来判断如果Orphan后被托管失败，直接调用ZDO_MultipleJoinReq，重新加入网络，直接Join网络，但是加入_NIB.nwkPanId记录的网络。
由这两个方法后，基本解决了以上各个问题。
总结了一下规律，CC2530的坑比较多，长期运行会遇见很多奇怪的问题，如果要快速出货，建议选用siliconlabs的efr32方案，会稍微贵一点，如果想要价格便宜，有信息自己挖坑的话或者抱着学习的态度，可以选用CC2530，毕竟开源部分稍微多一点