Unwanted "Leave" command from coordinator

[abe]

Hello, I developed for my customer, a ZigBee coordinator in last 2019, using nRF5 SDK for Thread and Zigbee v3.2.0.
Now my customer has this issue:
- End Node connected via router, if router deads, the coordinator rejoin it but after few time send "leave" command to end node
Here attached WireShark log file of ZigBee radio communication
Some details:
- end node has NW address E3DF
- router has NW address D01B
- at line 14631 and following, the router deads
- at line 14680 starting end node routing search
- at line 14747 and followings rejon procedure
- at line 14850 Coordinator sends LEAVE command to end node E3DF

What is happened? Why Coordinator sends "Leave" command?
How can we avoid this unwanted behaviour?

Many thanks for your help!

Abele

[Kenneth]

Hi,

nRF5 SDK for Thread and Zigbee v3.2.0 is quite old one. Can you verify it with latest nRF5 SDK for Thread and Zigbee v4.2?

Kenneth

[abe]

Hi Kenneth
this for me is very hard, the new 4.2 SDK (for what I know) seems not compatible with old one!
And the coordinator FW now in production is a result of over two years of developing ...
Could you help on SDK I have used ?

[abe]

Hi Marte
here attached zip file with Zboss log and related WireShark files for two cases of "Unwanted Leave"
Inside the Zboss log you can find also some "app" info: the message "<info> app: Device IEE UUID address 5C0272FFFEE7B24F leave network" is coming from Zboss callback function zboss_signal_handler(zb_uint8_t param) on main.c, processing switch case ZB_ZDO_SIGNAL_LEAVE_INDICATION.

Please help me as soon, let me know your comments to the logs
Many thanks!

Abele

Unwanted_Leave_ZbossLogs.zip

[Marte Myrvold]

Hi Abele,

Thank you for uploading the logs. I have forwarded it to the development team for decoding.

abe said:

Have you still tried to reproduce the issue? (using my suggests...)
Have further news?

I have not heard back from the development team yet, so I do not know if they have been able to reproduce the issue or not. Due to summer vacation response times might be slower than usual, so I apologize for that. Hopefully I will get a response as soon as possible, and I will update you when I hear something.

Best regards,

Marte

[abe]

many thanks Marte!
Then the format of log output is as expected, right?
Keep me updated. My customer is worried ... it ask me often if we have identified the issue.

Abele

[Marte Myrvold]

Hi Abele,

Yes, the format is as expected of ZBOSS trace logs.

Unfortunately we are short on staff due to summer vacations, so you must expect some wait time before the development team are done decoding and looking through the logs. I apologize for the inconvenience.

Best regards,

Marte

[abe]

Hi Marte,

have any news?
Keep me updated, we nee to solve the issue
Many thanks

Abele

[Marte Myrvold]

Hi Abele,

I do not have any news yet, but I have asked the development team for an update.

Best regards,

Marte

[abe]

Ok, thanks
Please, follow any update and let me know as soon any further news

Abele

[Marte Myrvold]

Hi Abele,

I got a response from the development team today. They are not able to prioritize resources for debugging logs from a product based on an old stack. The nRF5 SDK for Thread and Zigbee v3.2 has a Zigbee stack supporting specification version R21 – which is not certifiable anymore by CSA. To officially introduce new product into the field (including firmware update), after even minimal change in firmware, it must go throughout product certification. Thus switching to newer platform using R22 is essential.

Additionally, there is a good chance that this bug is fixed in newer versions of the stack and that the issue will resolve itself when migrating to the latest SDK.

Best regards,

Marte

[abe]

I'm very disappointed for this answer, when I developed the application the SDK 3.x was the new available, and now after few year Nordic don't support it anymore.
I hoped a best help to issues, expecially when the alternative solution porposed has high impact on already developed project: migrating to the latest SDK practically forces to redo the project, with all difficulty related.
In addition, the new SDK don't support IAR EWARM (the 3.2 yes, I have developed my project with IAR EWARM)
Last, peraphs you can ask to development team if there is a possibility to "disable" the leave command on ZigBee SDK 3.2 ?
This could be a "patch" that has minor impact the project.
Please, let me know as soon

Best regards,
Abele

[Marte Myrvold]

Hi Abele,

As stated in my previous reply, you will not be able to certify Zigbee products that are using R21 of the Zigbee specification anymore. This is not a limitation on our side, but by CSA. Even if the leave problem is fixed you will not be able to certify a new product developed in v3.2 of the SDK.

Support for R22 of the specification was added in v4.0.0 and has been supported in our SDKs for more than 2,5 years already. I would really recommend migrating to v4.2 if possible, as this version supports ZCL8 as well and there was a lot of fixes between this version and the previous one, but if that is absolutely not possible then you should at least migrate to v4.1. There are still a lot of changes between v3.2 and v4.1, but it will not be as many as with v4.2, and there is still support for IAR. As mentioned by Kenneth previously we have a migration guide available in our documentation: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_r22_migration.html.

If you experience any issues with v4.1 I will try to help, but if these are bugs that have been fixed in later versions of the stack I unfortunately cannot help. 

Best regards,

Marte