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,

[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

[Marte Myrvold]

Hi Santiago,

I have forwarded this to our developers, and I will come back to you when I hear from them.

Best regards,

Marte

[Marte Myrvold]

Hi Santiago,

The assert is caused by an attempt to delete an entry with short_address for an address that has not been fully unlocked.

How difficult is this to reproduce? Can you reproduce it with an example without FreeRTOS and SoftDevice? 

Could you also provide or describe a scenario for which the device has failed? Please also provide a sniffer log of this happening.

Best regards,

Marte

[sjf]

Hi Marte,

We create some bindings from this device to coordinator at different clusters the first time. Once we remotely request to leave the network, this issue happens every time.

Our firmware is based on FreeRTOS and SoftDevice.

Regards

[Marte Myrvold]

Hi Santiago,

Could you try the workaround suggested in this comment?

Best regards,

Marte