TI中文支持网芯片：均为CC2530
协议栈:：HA1.2.2a
网络：协调器*1，路由设备*2，终端设备*1
问题描述：
早上将子设备接入网络后，中午发现路由设备均无法上传信息。抓包显示：路由设备上传信息后，没有收到协调器的mac ack。
后将终端设备重新上电，发现接到另一个PanID的协调器下。
验证测试：①将路由设备全部断电，上电协调器。终端设备可加入协调器，短地址不变，PanID：7307。
②将协调器断电，上电路由设备。终端也可以加入路由设备，短地址不变,PanID：CC05。
③协调器，路由器均断电在上电，也无法加入同一网络。
附上抓包数据：第3行开始，为测试①数据。第68行开始，为测试②数据。
猜想：在发现问题前，信道内存在50个设备再发数据，是否可能因为信道环境太差，导致协调器切换panID。
请问该问题如何解决，谢谢！
协调器异常切换信道.zip
Kevin Qiu1：
加入网络是根据RSSI的强度来选择加入的，有测试是什么导致断开连接的吗？ 信道环境太差可能有影响，切换信道后测试过吗。
user5032796③协调器，路由器均断电在上电，也无法加入同一网络。
附近有其他协调器，重新上电时先给协调器上电测试下
user5032796：
回复 Kevin Qiu1:
感谢您的回复，现在反复测试还无法复现问题，也是第一次发现。目前路由设备复位后，ubiqua的network explorer中显示了PANID：cc05下存在一个路由设备和一个协调器，可是这个协调器并没有存在（无发出linkstasus）。我们将信道内的其他设备全部关闭了，仅剩测试设备，目前连接是稳定的。
user5032796：
回复 Kevin Qiu1:
测试内容：协调器先上电，路由设备再上电。保留原来的异常网络。
附上测试抓包：第3行：协调器上电后，发出route request，PANID：7307。
第12行：路由设备上电，立即上报心跳包，PANID：CC05。重发多次没有收到MAC层ACK。第20行发出route request
上电测试.zip
Kevin Qiu1：
回复 user5032796:
附近看起来有好几个zigbee网络，PANID一直在变，将终端和协调器的NV RESTORE都加上试试
user5032796：
回复 Kevin Qiu1:
是的，附近同时也有几个协调器挂着。网络呢所有设备都是有加上NV_RESTORE的。
反馈：早上测试，协调器又跳了PANid，但这次下面的设备有跟着过来，也依然能控制。
由于抓包数据被清除了，并且可能子设备有做重上电动作，所以还是没能分析到是什么原因导致跳PANid的。
还有就是协调器掉电后，子设备发出特别多的network status。抓包中第40行开始。
network key：03:05:03:05:03:05:03:05:03:05:03:05:03:05:03:05
networkstatus1.zip
Kevin Qiu1：
回复 user5032796:
看下你的是不是这个问题：e2echina.ti.com/…/186019
user5032796：
回复 Kevin Qiu1:
还是有些区别的，预编译中路由设备我只打开了这些：
MT_TASKMT_SYS_FUNC
MT_ZDO_FUNC
NV_RESTORE
NV_INIT
ISR_KEYINTERRUPT
RXF2401_PA
MT_ZDO_MGMT
WDT_IN_PM1
HOLD_AUTO_START
并没有使能NWK_MANAGER。
协调器预编译了：
ZTOOL_P2
MT_TASK
MT_SYS_FUNC
MT_ZDO_FUNC
NV_RESTORE
HAL_UART=TRUE
ISR_KEYINTERRUPT
RXF2401_PA
WDT_IN_PM1
Kevin Qiu1：
回复 user5032796:
user5032796早上测试，协调器又跳了PANid，但这次下面的设备有跟着过来，也依然能控制。
一般周围设备有相同PANID时，协调器PANID才会改变。
升级到Z-Stack 3.0.2看下是否还会出现此问题
user5032796：
回复 Kevin Qiu1:
在协调器端，没有预编译NV_INIT。
在ZGlobals.c中{ZCD_NV_PANID, sizeof(zgConfigPANID), &zgConfigPANID},不知是否和这个有关系。
Kevin Qiu1：
回复 user5032796:
你用的是哪个例程，可以在预定义中加上NV_INIT试试
