接着上回繼續分析公司遺留的問題三分析，問題三就蠻棘手的，因爲是隱性問題，不容易復現，有時候，一個月才復現一次，出現這樣的問題給定位帶來了很大的困難，首先說一下我們產品的掉線、重連機制。
產品掉線重連機制：設備正常通信的時候倒還好，如果出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，畢竟開源部分稍微多一點