This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

zigbee stack reset coordinator

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. 

Parents
  • 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

Reply
  • 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

Children
  • 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,

    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

Related