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 ?

[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

[abe]

Hi Marte,
I will inform my customer for your answers.
Nordic help in migration to 4.1 would be very appreciated, I'll keep you updated in next weeks when I can start this work

Regards

Abele

PS the link you paste seems not working ...

[Marte Myrvold]

Hi Abele,

Thanks for letting me know. For some reason DevZone changed the link to try to link to something on DevZone instead. I have updated the link, but it is also here: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/zigbee_r22_migration.html.

Best regards,

Marte

[abe]

Hi Marte,
I'm evaluating to use Segger Embedded Studio to migrate my project to SDK 4.2.0.
It's very probably that I will need help for several things, here a starting list:
- adding BLE gatt/services and DFU bootloader integration
- Handler when NEW devices will accepted on network (we need to read from device some info and store on BLE GATT)
- Zboss method to handle end-node steering and net formation (user must manually activate devices network joining process)
- Computing of needed NVRAM for 100 Zigbee nodes, and how to handle it
- using and handle of FDS storage for store some data used by custom application (without issues with Zboss NVRAM)
This is main list, but I think that we could need other help during the development.
I will inform you that our product is a Zigbee Coordinator, and the previous development (from SDK3.2) was made integrating DFU bootloader and CLI agent configured as coordinator into Multiprotocol Ble-Zigbee template
Let me know for these helps.
Many thanks in advance.
Abele

[Marte Myrvold]

Hi Abele,

I am sorry for the delay.

abe said:

- adding BLE gatt/services and DFU bootloader integration

We do have some nRF5 SDK Bluetooth guides on Devzone here:  Bluetooth low energy , such as this guide for services:  Bluetooth low energy Services, a beginner's tutorial . As for DFU there is a guide for getting started with the secure DFU bootloader here:  Getting started with Nordic's Secure DFU bootloader, a step by step guide . You should also be able to find information in our documentation on infocenter. If you have more problems with this part, please create a new ticket.

abe said:

Handler when NEW devices will accepted on network (we need to read from device some info and store on BLE GATT)

You can use the ZB_ZDO_SIGNAL_DEVICE_ANNCE or ZB_ZDO_SIGNAL_DEVICE_UPDATE signals in zboss_signal_handler() to handle when a device is updated/joins the network. See components/zigbee/common/zigbee_helpers.c for how these signals are used there.

abe said:

- Zboss method to handle end-node steering and net formation (user must manually activate devices network joining process)

Do you mean that the user must be able to open the network on the coordinator? Because if so, then you can look at the light coordinator example. There the network is reopened if button 1 is pressed:

case BSP_EVENT_KEY_0:
    UNUSED_RETURN_VALUE(ZB_SCHEDULE_APP_ALARM_CANCEL(steering_finished, ZB_ALARM_ANY_PARAM));

    comm_status = bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING);

abe said:

Computing of needed NVRAM for 100 Zigbee nodes, and how to handle it

We have some information about NVRAM in our documentation here: https://infocenter.nordicsemi.com/topic/sdk_tz_v4.2.0/group__zboss__nvram.html

I hope this answers some of the questions. If you have specific questions about any of this, please create a new ticket for the questions, as they are no longer directly related to the original issue in this ticket. Thank you!

Best regards,

MArte

[abe]

Thanks for answers, Marte.
For BLE and DFU integration (that I have already done in actual release) I follow same steps I have already done on SDK 3.2.0, and so also for device annonce and update, and to start network formation.

The question about the needed amount of NVRAM for 100 end node, for the previous Zboss version iI received excel file whit compute of space. You can see on this thread what I means devzone.nordicsemi.com/.../zigbee-maximum-device-number

Last question, how can I contact you if I need help during the migration to new SDK 4.2.0?