Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Mon, 20 Nov 2023 15:34:12 GMT

Great!

As usual, please feel free to open new cases if new questions or issues comes up!

I will mark this case as closed/verified

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Mon, 20 Nov 2023 10:57:31 GMT

Yes, I think I have had my questions answered.

Thank you for your assistance!

Best regards,
Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Tue, 14 Nov 2023 14:42:10 GMT

[quote user="Kristoffer Sliwinski"]Then again, it can be dangerous to make assumptions [/quote]

I 100% agree with that!

So in that spirit I'm curious if this clarifies all your questions or if there are anything else that's currently unclear regarding this topic?

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Fri, 10 Nov 2023 10:11:52 GMT

Hi,

OK, thank you for the clarification about the memory footprint.

About the role, yes in v4.1.0 we were already defining ZB_COORDINATOR_ROLE. In v4.2.0 I had to add ZB_ROUTER_ROLE together with that to get the coordinator commissioning to work.

@@ -47,6 +47,7 @@
 
 DEFINES += ZB_COORDINATOR_ROLE
+DEFINES += ZB_ROUTER_ROLE

My assumption was that it would be enough to only define one role for one device, zb_config.h:552 indicates that it should be enough

In general, define ZB_COORDINATOR_ROLE to compile ZC-only build, ZB_ROUTER_ROLE to compile ZR+ZED build, ZB_ED_ROLE to compile ZED-only build.

Then again, it can be dangerous to make assumptions 😅

Best regards,

Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Wed, 08 Nov 2023 12:44:50 GMT

Hi again,

I managed to sneak in a quick chat with one of the Zigbee developers today

The increase in RAM/ROM is expected. They state that the ZBOSS stack used in nRF5 for T&Z v4.1.0 were quite old and with the v4.2.0 update the stack was also upgraded to a newer version that included more features, thus contributing to the increase in ROM/RAM.

In addition, v4.2.0 also introduced a new ZCL which further reinforces the additional ROM/RAM load.

Regarding the need to add the role, could you clarify if you already had Zigbee cord role + zigbee router role in your existing app, or was that something you needed to add when you migrated to v4.2?

The developer I talked to stated that it sounded like something to be expected since the coordinator basically is a Router device with additional features added on top

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Wed, 08 Nov 2023 08:42:32 GMT

Alright, thank you for the update!

Best regards,
Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Tue, 07 Nov 2023 14:38:54 GMT

Hi again,

There will unfortunately be a bit of waiting time for this issue due to the amount of items the Zigbee team has on their backlog. I will see if I can push for an ETA to get an answer for this inquiry ASAP

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Fri, 03 Nov 2023 14:53:01 GMT

Hi,

I've yet to have any input from the Zigbee team as there is unfortunately a backlog of things they need to get through. I will check in with the team on Monday and also ask them about the RAM and ROM increase

Apologies for the inconvinience

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Tue, 31 Oct 2023 13:46:12 GMT

Hello Andreas,

Did you learn anything more from the team about the coordinator?

About the sleep signal question, I managed to find [Update Zigbee SDK] Problem when update from zigbee and thread 4.1.0 to zigbee and thread 4.2.0 which clarified the question I had earlier.

If you wouldn't mind, I'd also like to ask about the expected increase in flash and RAM in this release, we can see it's increased quite a bit on our end device.

	Flash	RAM
v4.1.0	629640	91756
v4.2.0	683785	100108

We build for nRF52840 without any link time optimization.

Best regards,
Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Thu, 19 Oct 2023 10:43:05 GMT

Hi,

Great! Good to hear that you were able to locate the difference

[quote user="Kristoffer Sliwinski"]We can proceed with this, but I don't think the dependency is completely expected. I would expect to be able to build a coordinator without having to also set the router role. Maybe something for the team to look at?[/quote]

From external/zboss/include/zb_config.h is relevant: '- routing & parent srv (zc & zr) - ZB_ROUTER_ROLE (name is not perfect, but keep it to minimize code change)'

In other words it looks like ZB_ROUTER_ROLE has to be enabled even though ZB_COORDINATOR_ROLE is enabled. I agree that this looks strange, specially since we have the following in the code to the Light_coordinator:

I will reach out to the Zigbee team to see if this is expected

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Wed, 18 Oct 2023 12:39:39 GMT

Hi Andreas,

I realized something when looking at the new defines we introduced to the build system during the upgrade. ZB_JOIN_CLIENT had added been added to our coordinator build to resolve a link time issue in zdo_commissioning_bdb.c, but why would this define be needed for the coordinator? Looking at the comment in zb_config.h:528 this should only be for router and end device.

I compared the light_coordinator example to our application and I could see that ZB_JOIN_CLIENT is set for your light_coordinator. That in turn lead me to identify a clear difference, our application is only built with ZB_COORDINATOR_ROLE while your light_coordinator is built with both coordinator and router functionality because your example also sets ZB_ROUTER_ROLE together with the coordinator define in zb_config.h:559-560.

As an experiment I also added ZB_ROUTER_ROLE to our build and voilà, it's working! The coordinator will form a network and our end device will join.

We can proceed with this, but I don't think the dependency is completely expected. I would expect to be able to build a coordinator without having to also set the router role. Maybe something for the team to look at?

Kind regards,

Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Tue, 17 Oct 2023 11:00:19 GMT

Hi,

[quote user="Kristoffer Sliwinski"]Yes it is indeed an old product and, we have a parallel initiative for moving over to NCS. For now I'll have to stick with this SDK [/quote]

Noted! Thank you for clarifying :)

[quote user="Kristoffer Sliwinski"]I should mention that we run with the softdevice and with zigbee in a FreeRTOS task, where we iterate the ZBOSS stack as it's done in multi_sensor_freertos, [/quote]

You mention the freertos multisensor sample, are you able to verify the differences between the SDK 4.1 sample and the SDK 4.2 sample? I assume you've already checked this, but asking just to be sure

[quote user="Kristoffer Sliwinski"]I'll dig more into the task handling, for example I can see that you do not create them dynamically. Though it's worth to mention that this worked for us previously.[/quote]

I will see if I can reach out to our FreeRTOS experts to see if they have any additional insight as well as the Zigbee team, but I'm not sure if they have anything more constructive than what we i.e they have already relied.

Let me know about your progress and I'll keep on supporting you to our best capacity

Kind regards,
Andreas

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

Kristoffer Sliwinski — Mon, 16 Oct 2023 16:43:41 GMT

Hi Andreas,

Sorry for the delayed response.

I'm assuming that this is an old product since you're using nRF5 SDK for Zigbee and Thread and that you expect to not see the need for any new features than what is in nRF5 SDK? If this is a new product that you will be starting on from scratch we recommend that you consider migrating to NCS

Yes it is indeed an old product and, we have a parallel initiative for moving over to NCS. For now I'll have to stick with this SDK 🙂

This may not be relevant, but one thing we see when comparing the light_coordinator in v4.1.0 with v4.2.0 is that v4.1.0 has nrfx_timer and timer enabled in addition to timer3, and it includes nrfx_timer.c in Makefile (or SES if that is what you're using). In v4.2.0 there are none of the timers enabled in sdk_Config.h, but it includes files that are not a part of v4.1.0, and among them there are some files in the timers.

I'm not sure I follow completely, but our includes for v4.2.0 looks like what you link here. I have not done any changes to sdk_config.h (yet).

Could you share some additional logs from the device starts up until you see the issues? It could help to investigate all the signals that are generated

I don't see much more than what I linked above, zboss_start_no_autostart is called earlier and returns RET_OK as expected. I see that the comment mentions calling bdb_start_top_level_commissioning(0) which is something we don't do.

I should mention that we run with the softdevice and with zigbee in a FreeRTOS task, where we iterate the ZBOSS stack as it's done in multi_sensor_freertos, albeit with another task delay. We create our task during runtime and put it in a suspended state until commissioning is triggered by a user, the task is then resumed. I could see that if I moved task creation to when commissioning is done the order of the signals change, (22 now comes after the other signals) but still no success in establishing a network.

#5     00000 00:00:09.587    Info zigbeeModuleStart Func: 'zboss_start_no_autostart', ret: 0
#6     00000 00:00:09.588    Info zigbeeModuleStart Commissioning status 1
#7     00000 00:00:09.588    Info zboss_signal_handler Signal handler called! Type  23
#8     00000 00:00:09.589    Info zboss_signal_handler Signal handler called! Type  1
#10    00000 00:00:09.639    Info zboss_signal_handler Signal handler called! Type  22
#11    00000 00:00:09.689    Info zboss_signal_handler Signal handler called! Type  22
#12    00000 00:00:09.739    Info zboss_signal_handler Signal handler called! Type  22
#13    00000 00:00:09.789    Info zboss_signal_handler Signal handler called! Type  22
#14    00000 00:00:09.839    Info zboss_signal_handler Signal handler called! Type  22
#15    00000 00:00:09.889    Info zboss_signal_handler Signal handler called! Type  22
#16    00000 00:00:09.939    Info zboss_signal_handler Signal handler called! Type  22
#17    00000 00:00:09.989    Info zboss_signal_handler Signal handler called! Type  22
#18    00000 00:00:10.039    Info zboss_signal_handler Signal handler called! Type  22
#19    00000 00:00:10.089    Info zboss_signal_handler Signal handler called! Type  22

I'll dig more into the task handling, for example I can see that you do not create them dynamically. Though it's worth to mention that this worked for us previously.

Other than that I don't have much more at the moment, sadly.

Kind regards,
Kristoffer

RE: Coordinator commissioning fails after upgrade of nRF5 SDK for Thread and Zigbee (v4.1.0 to v4.2.0)

AHaug — Thu, 12 Oct 2023 14:34:49 GMT

Hi,

I'm assuming that this is an old product since you're using nRF5 SDK for Zigbee and Thread and that you expect to not see the need for any new features than what is in nRF5 SDK? If this is a new product that you will be starting on from scratch we recommend that you consider migrating to NCS

Regardless of that here's a couple of thoughts and pointers from a colleague of mine

#ifndef ZB_USE_SLEEP
#define ZB_USE_SLEEP
#endif

Is a feature and not a bug to our understanding and the comment

/* Enable sleepy behaviour on all devices. The sleep signal will allow other, lower-priority task to take over. */

#ifdef ZB_ED_ROLE
#define ZB_USE_SLEEP
#endif

is defined in zb_config.h in v4.2.0 as well. The first snippet is just in zb_vendor.h

We don't think the problem is due to sleep since our coordinators are still working even though the sleep signal comes all the time. The signal does not actually put the device in sleep when it is a coordinator, it just lets it know that the device now can do other things that are not Zigbee.

This may not be relevant, but one thing we see when comparing the light_coordinator in v4.1.0 with v4.2.0 is that v4.1.0 has nrfx_timer and timer enabled in addition to timer3, and it includes nrfx_timer.c in Makefile (or SES if that is what you're using). In v4.2.0 there are none of the timers enabled in sdk_Config.h, but it includes files that are not a part of v4.1.0, and among them there are some files in the timers.

Could you share some additional logs from the device starts up until you see the issues? It could help to investigate all the signals that are generated

Kind regards,
Andreas