Zigbee Task halts on Leave Request

[sjf]

Hi,

We have been working with an end device based on nRF52840 with nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b and FreeRtos

This device has some bindings already set to the coordinator.

When it receives a Leave Request from coordinator, the Zigbee Stack gets stucked on zb_address_reset() function. Because of that, the Zigbee task remains blocked for the rest of the time.

Which should be the reason to halt at this point and how this could be avoided?

Regards,

Santiago

[Marte Myrvold]

Hi Santiago,

I've started looking into your issue.

Is the project on the end-device based on one of the examples in our SDK? If so, which one? Is the leave request part of the program and thus on purpose? If that's the case, how are you doing the leave request?

Could you please perform a sniffer trace and upload the sniffer log here?

Best regards,

Marte

[sjf]

It was based on an end device example but it has many modifications form that template. 

Basically we create some cluster bindings from the end device to the coordinator automatically once connected for the first time.

When the coordinator wants to remove the child, it sends a leave request (zdo_mgmt_leave_req()) with the following data:

p_req->dst_addr = <end device short address>

p_req->device_address = <end device ieee address>

p_req->rejoin = false

I'll try to get Wireshark log for you today/tomorrow

Regards,

[Marte Myrvold]

Hi Santiago,

I just got a response from the Zigbee team. They were able to reproduce the problem, with both nRF5 SDK T&Z and with NCS, so it seems the problem is with the Zigbee stack (ZBOSS). The problem has been reported to DSR in ZBOSS Open Initiative (ZOI).

Best regards,

Marte

[sjf]

Hi Marte,

Thanks for your response. Is there any workaround?

Regards,

[Marte Myrvold]

Hi Santiago,

I don't know of any workaround yet, but our Zigbee team is looking into it to try and see if there's an obvious fix besides waiting for a response from DSR. However, I can't give an estimate on when this will be done, as it might take some time. I'll let you know as soon as I know more.

Best regards,

Marte

[Marte Myrvold]

Hi Santiago,

The Zigbee team is still waiting for a response from DSR, but they have proposed a workaround in the meantime:

Place the following lines inside the zboss_signal_handler switch-case structure:

       case ZB_ZDO_SIGNAL_SKIP_STARTUP:
               /* 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);
                       }
               }

The Zigbee team were able to do many leave requests and resets in a row without failure with this workaround.

Please let me know whether this workaround solves your issue or not. I'll let you know if we hear anything from DSR.

Best regards,

Marte

[sjf]

Hi Marte, we're still facing this issue even with the new code you provided.

Please find attached an image with the Call Stack content.

Device (router role ) was removed from the network.

When it starts, it automatically joins to the network and periodically prints:

app: Parent is unreachable
 app: UNKNOWN SIGNAL = 17

When we press a button to order it to leave network, it sends the leave request:

      /* Set dst_addr == local address for local leave */
      p_req_param->dst_addr = ZB_PIBCACHE_NETWORK_ADDRESS();
      p_req_param->rejoin   = ZB_FALSE;
      UNUSED_RETURN_VALUE(zdo_mgmt_leave_req(bufid, zbm_send_leave_nwk_cb));

And the callback is triggered successfully. But then the funcntion zb_nrf52_abort() is called due to an assert....

Regards,

 

[Marte Myrvold]

Hi Santiago,

I will ask our Zigbee team about this. Due to Easter we are short staffed, and I will not get a response from them until next week.

Best regards,

Marte

[sjf]

Hi, is there any update on this?

Regards

[Marte Myrvold]

Hi,

Unfortunately, I have not heard back from the Zigbee team yet. I will ping them to see if there are any updates.

Best regards,

Marte

[Marte Myrvold]

Hi,

The workaround provided was for end-devices. In order to prevent compiling-in the workaround for non-end-devices you can use something like this:

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 */

The Zigbee team wants to know if there are any other issues with the router device when the workaround is not compiled in?

Best regards,

Marte

[sjf]

Hi Marte, we are still facing this issue both on end devices and routers.

Please find attached an image about an assert error on zb_address_reset() function for end devices.

Regards,

network_leave_issue.zip