TI中文支持网使用的协议栈版本：2.5.1a
由于是在实际项目中遇到的，所以没有抓包的数据
设备入网之后如果同步信号丢失会重新寻找网络的部分被我屏蔽掉了，所以不存在父节点更之类的问题
现象：
从项目现场把设备拿回来之后用抓包工具查看发现设备的网络信号以及panid都是对的，只是短地址发生了改变。
希望大佬们给点建议,谢谢
Viki Shi：
比较奇怪，单个设备还是多个设备？
user4733766：
回复 Viki Shi:
目前只遇到一个设备。出现这样的情况
Susan Yang：
回复 user4733766:
有没有观察过地址会变的情况发生时，节点是通过什么方式入网的？ Rejoin,join,orphan?
Susan Yang：
回复 user4733766:
另外Router只有第一次入网的时候会选择父节点，之后如果开启了NV功能，即便是复位，或者远离父节点也不会去重新选择父节点了。因为已经存在于网络中了，后续的路由数据都是靠Link Status来更新Neighbor table，和route request来更新 Routing table了。
user4733766：
回复 Susan Yang:
设备第一次第一次加入网络之后除非手动删掉都不会再加入网络。入网的方式都是join
user4733766：
回复 Susan Yang:
你好，今天项目上又反应有一个面板无法控制。我去查看之后发现也是出现了短地址发生改变的情况。
请问什么特殊的场景会造成这种情况吗？
我的猜测：设备复位之后启动的网络恢复在读出网络信息的时候信道和panid都读取正确然后读取短地址的时候出现了问题所以就随机生成了一个短地址，并且写入了NV。请问有这种可能吗？
猜测的原因：我有这种猜测的原因是因为之前遇到过协调器的网络信息改变的情况。然后在公司做实验发现是因为电源的问题：设备启动的时候从NV中读取网络信息但是失败了所以就从新建立网络,所以出现了网络发生改变的情况。之后更换了电源就没有遇到过这个问题了。
希望帮忙解答一下
user4733766：
回复 Susan Yang:
你好,到现在这个问题我也没有找到.我的猜测是路由设备断电之后上电NLME_RestoreFromNV中读出的_NIB信息错误或者被修改.之后执行网络恢复在回调函数ZDO_JoinConfirmCB中会执行一次ZDApp_NVUpdate.这个错误的短地址就被写进了Nv.但是如果是这个原因的话每次都只有短地址出现问题也很奇怪.所以想问问有这种可能性吗？基于硬件电路不太稳定考虑的
Susan Yang：
回复 user4733766:
您的猜想是有可能的。若是有TI开发板的话，建议您将您的程序在TI开发板上试一下。有可能是在断电，电压不稳或者波动比较大的时候，进行了NV Flash的操作。
NLME_RestoreFromNV()的 返回值是多少？若是ZERO，则表明NV_RESTORE无法正常工作。鉴于您现在使用的是2.5.1a版本的协议栈，若是您不想升级协议栈版本的话，建议您替换ZDApp.c内ZDApp_NetworkStartEvt( void ) 的部分代码
if ( nwkStatus == ZSuccess ){// Successfully started a ZigBee networkif ( devState == DEV_COORD_STARTING ){devState = DEV_ZB_COORD;}
替换为
if ( nwkStatus == ZSuccess ){// Successfully started a ZigBee networkif ( devState == DEV_COORD_STARTING ){ZDApp_NwkWriteNVRequest();//save NIB to NV before child joins if NV_RESTORE is defineddevState = DEV_ZB_COORD;}
参考链接 e2e.ti.com/…/1432684
