issue on reboot and rejoin in zigbee:
We are developing our product and using NRF52840 on both the zigbee ZED and ZC sides.
Now we met problems in the reboot and rejoin feature.
1) Although the zboss stack provides the nvram saving/erasing API, for example
"zb_void_t zb_set_nvram_erase_at_start(zb_bool_t erase)",
"void zb_nvram_clear(void)",
However, we found that if we do not clear/erase the nvram, and then the software
will crash/freeze inside the zboss stack, no matter it is at the ZED or ZC side.
The same phenomenon is described in another post here, by someone other developer
in another developer:
devzone.nordicsemi.com/.../nrf52840-pca10056dk-zigbee-examples-keep-rebooting-with-zboss-error
This crash happen almost everytime after reboot if we do not clear the nvram,
and we think it is because the zboss stack will then init with wrong/messy data in nvram.
2) Because of the above nvram problem, the ZED node cannot start with zigbee network knowledge
of the last time, in this case, the ZED after reboot will not initiate any 'Rejoin',
since it forgets the information of the previous connection.
Then this will make the ZED not able to automatically get the connection back after reboot,
for example when we change the battery of the ZED and thus reboot.
3) Again, because the above nvram problem, the ZC using NRF52840, if it reboot instead, it will
forget its previous PAN-ID, and then the ZED using NRF52840 will not do rejoin process,
this seems to be because the ZC's PAN-ID will change (even though the ext PAN-ID do not change.)
On the contrarary, 3rd party ZC after reboot will have the same PAN ID and ext PAN ID as previously,
and our ZED using NRF52840 will have no problem to automatically initiate Rejoin process and succeed.
All in all, it seems that because of the nvram problem, it cause lots of barrier for the Rejoin process.
Please let us know how to solve the NVRAM issue.
BR
