hi!
when resetting the coordinator (zb_bdb_reset_via_local_action(0)), an error occurs, the program hangs. It looks like the "zb_address_unlock" function. The same when using the command "bdb factory_reset" in the cli example. I use ver 4.1.0.

hi!
when resetting the coordinator (zb_bdb_reset_via_local_action(0)), an error occurs, the program hangs. It looks like the "zb_address_unlock" function. The same when using the command "bdb factory_reset" in the cli example. I use ver 4.1.0.

Hi,
This might be related to a bug in the ZBOSS stack where it asserts after receiving the leave command. I have reported this bug internally earlier and there was a fix for it in a later version of ZBOSS, but that version is only supported in nRF Connect SDK, as far as I know. I will check this internally, and see if there is a workaround for nRF5 SDK v4.1.0.
Could you please provide more information about the application running on your coordinator? Is it based on one of the examples in the SDK, and if so what example? Are you using FreeRTOS and/or Bluetooth Low Energy as well, or only Zigbee?
Best regards,
Marte
This error also appears in the cli example (pca10056). My project uses free rtos, the code is based on a free rtos temperature sensor.
Hi, I have the same issue on a custom project using ble/zigbee. I try with zb_bdb_reset_via_local_action and zdo_mgmt_leave_req but result is the same, program hangs after zb_address_unlock. Switching to nRF Connect SDK is not possible for now.
Hi,
Thank you for providing this information. Does this happen every time you issue the "bdb factory_reset" command, or only during certain conditions? If it only happens sometimes, can you please explain under what conditions, and the steps to reproduce this?
The workaround from previously is unfortunately only for end devices, as that is where we saw this issue. In that case, the workaround is to add the following inside the zboss_signal_handler switch-case:
case ZB_ZDO_SIGNAL_SKIP_STARTUP:
#ifdef ZB_ED_ROLE
/* WORKAROUND for the ZOI-297: unlock the device's address on ZEDs to fix assertion upon leave request. */
zb_address_ieee_ref_t addr_ref;
/* Unlock our address: it will be locked at rejoin confirm */
if (zb_address_by_short(ZB_PIBCACHE_NETWORK_ADDRESS(), ZB_FALSE, ZB_FALSE, &addr_ref) == RET_OK) {
zb_address_unlock(addr_ref);
}
#endif /* defined ZB_ED_ROLE */
I am still looking into this and trying to find if there is a workaround for router and coordinator devices as well.
Best regards,
Marte
Hi,
Thank you for reporting this. Is the device trying to leave the network an end device, or is it a router or coordinator? If it is an end device, please try the workaround I posted in my other reply in this ticket and see if that resolves it. I am still looking into a solution for routers and coordinators.
Best regards,
Marte