Coordinator ZBOSS stack hangs when router leaves network

[dimi]

Dear Nordic team,

in our multiprotocol (BLE, ZB) application (nRF5 SDK v4.1.0 )we are facing following severe issue relating to the ZBOSS stack: When a router leaves its ZB network using the workaround described in issue zigbee stack reset coordinator - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com), the ZBOSS stack sometimes hangs on the coordinator side (zb_assert, after executing either zb_address_unlock or zb_address_reset).

Here the call stack on the coordinator side, after trying to remove a router device from its network (in 2 different cases):

Result is, that the app scheduler we use, returns a NRF_ERROR_NO_MEM error, since its queue is not processed and the application fails. Could you please advise us on how to deal with these ZBOSS errors (via workaround or ZBOSS update)? The problem is really hard to track, since it doesn't occur systematically. 

Since we are already in production, we would appreciate a prompt response.

Many thanks in advance!

[Charlie]

Hi Dimitris,

Sorry for the late reply, I try to collect the current state on the "zigbee stack reset coordinator" issue.

This was fixed in the ZBOSS release 11/30/2020 ZOI-297, but that fix is only available in NCS so far. nRF5 SDK v4.1.0 uses an old version ZBOSS stack and there is no major update in a short time. Please consider switching to NCS for your next product. See nRF Connect SDK and nRF5 SDK statement to learn more.

For your current issue, I am not sure if the workaround introduced this new issue for your codes. We have another customer try this solution, but we did not get any feedback yet, either good or bad. It would be better if we can repeat this issue on the existing examples or sharing a minimal sample of your application codes that can recreate this issue. I need to request help from our development team for your case.

Best regards,

Charlie

[dimi]

Dear Charlie,

thank you for the reply.

Unfortunately we are still facing the same and further similar problems with the ZBOSS stack (nRF5 SDK v4.1.0). The stack hangs on various occasions on zb_asserts (e.g. after executing zb_buf_free_func or zb_address_unlock or zb_address_reset and so on...).

Since we are already in production and with a high chip order quantity (of ca.10K pieces), we would  be glad to receive some more dedicated support. To simply switch to the new NCS at this moment, is not realistic for us.

Could you please bring us in contact with a dedicated expert to find a solution?

Best regards,

Dimitris

[Charlie]

Hi Dimitris,

I have good news bring for you after checking with our Product Manager. We decided to update the ZBOSS stack on nRF5 SDK, even we have limited resources and a few customers still using nRF5 SDK v4.1 on their Zigbee development. Since this issue is related to the ZBOSS stack, this is the best solution we can provide now. 

The coming releases would be nRF5 SDK for Thread and Zigbee v4.2.This release will provide several ZBOSS bugfixes present in nRF Connect SDK today and will include ZCL 8 and BDB 3.0.1 which will be required to pass Zigbee product certification next year. The goal is to have exactly the same ZBOSS stack version in nRF Connect SDK 1.8 and nRF5 SDK for Thread and Zigbee v4.2. This release targets only Zigbee, there will not be any changes for the Thread part.

We are still in the planning stage and I will let you know if there are updates later. Please also keep a close connection with our local sales and support team to get the latest information about products update. 

Best regards,

Charlie

[dimi]

Hi Charlie,

thanks for the reply. Please let us know as soon as you conclude your nRF5 SDK for Thread and Zigbee v4.2 release planning.

In the meantime we would be thankful if you could bring us in contact with a ZBOSS expert, so we can discuss in detail best practices and workarounds to get the issues mentioned above under control (as much as possible). 

Best regards,

DImitris