ABOUT ZIGBEE OF NRF54L15

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Wed, 13 Aug 2025 13:41:05 GMT

Glad to hear that your problem is solved! 🙂

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Wed, 13 Aug 2025 01:01:23 GMT

Thank you very much—this code does indeed solve my problem.

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Tue, 12 Aug 2025 12:40:11 GMT

Then there is something else waking the system up. Try the attached project:

devzone.nordicsemi.com/.../system_5F00_off_5F00_mod.zip

This will also print the reset reason. I tried the application that you sent me, and it only woke up every 10 seconds, so perhaps you have connected something to the kit that keeps waking it up?

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Tue, 12 Aug 2025 01:34:35 GMT

This is the log. It is not waking up every 10 second as expected; instead, it keeps restarting continually.

This is my test project code.

devzone.nordicsemi.com/.../3124.system_5F00_off.zip

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Mon, 11 Aug 2025 11:50:30 GMT

Sorry that I didn't specify. CONFIG_GRTC_WAKEUP_ENABLE is specific for the sample NCS\zephyr\samples\boards\nordic\system_off.

You can test that sample and see if it wakes up. Add this in your main file to keep track of the uptime:

printk("Uptime: %d\n", k_uptime_get_32());

[quote user="sg3"]2、If I use the code below directly, it still won't wake up.[/quote]

Does it build? What does it print? "Entering system off..." or "Unable to prepare GRTC..."?

BR,
Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Mon, 11 Aug 2025 09:39:33 GMT

1、The compilation fails with the error "CONFIG_GRTC_WAKEUP_ENABLE is not defined."

2、If I use the code below directly, it still won't wake up.

	LOG_INF("Starting system...");
// #if defined(CONFIG_GRTC_WAKEUP_ENABLE)
#if 1
	int err = z_nrf_grtc_wakeup_prepare(10 * USEC_PER_SEC);

	if (err < 0) {
		printk("Unable to prepare GRTC as a wake up source (err = %d).\n", err);
	} else {
		printk("Entering system off; wait %u seconds to restart\n", 10);
	}
#endif
	k_msleep(5000);
	sys_poweroff();

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Mon, 11 Aug 2025 07:53:39 GMT

You can use the GRTC to wake up from system off, then keep trying for a while, then go back to system off. Please note that this is only possible on the nRF54L series, not the nRF52 series or the nRF53. When using these, you need to use system on (a lighter sleep).

But since you are using the nRF54L platform, you can enter System off, and use a timer to wake up. For this check out the NCS\zephyr\samples\boards\nordic\system_off sample, and add

CONFIG_GRTC_WAKEUP_ENABLE=y

to that application's prj.conf. Then you should see it waking up every 2 seconds.

What it does is enabling this snippet in main.c:

#if defined(CONFIG_GRTC_WAKEUP_ENABLE)
	int err = z_nrf_grtc_wakeup_prepare(DEEP_SLEEP_TIME_S * USEC_PER_SEC);

	if (err < 0) {
		printk("Unable to prepare GRTC as a wake up source (err = %d).\n", err);
	} else {
		printk("Entering system off; wait %u seconds to restart\n", DEEP_SLEEP_TIME_S);
	}
#endif

So in your application, include this file:

#include <zephyr/drivers/timer/nrf_grtc_timer.h>

and use z_nrf_grtc_wakeup_prepare() to set the amount of time you want it to be in system_off.

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Mon, 11 Aug 2025 00:58:37 GMT

Thank you very much—system off mode does indeed solve my problem. At the same time, could you please provide sample code that wakes up periodically from system off mode?

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Fri, 08 Aug 2025 11:48:59 GMT

If it is not called already, you should call stop_network_rejoin() after a given amount of time. That amount of time is something you decide in your application.

I thought this would be called automatically, after CONFIG_ZIGBEE_DEV_REJOIN_TIMEOUT_MS (default 200 seconds).

If start_network_rejoin() is called, then it will start this timer. This iystem is a bit confusing, since it tries to send a beacon every 2^n seconds. So first after 1 second, 2 seconds, 4 seconds, 8 seconds, etc. and all of these will restart the timer.

But when this reaches 200 seconds, you will see in the log:

"TC Rejoin was not successful (status: -1)". You will see that line being printed in ncs-zigbee\subsys\lib\zigbee_app_utils\zigbee_app_utils.c, in the zigbee_default_signal_handler(), in the ZB_BDB_SIGNAL_TC_REJOIN_DONE event.

You can use this event to enter system off mode, if that is what you prefer. In this mode, it can be woken up by a button press.

You can use sys_poweroff() to enter system off mode, and you need to include:

#include <zephyr/sys/poweroff.h>

And CONFIG_POWEROFF=y

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Thu, 07 Aug 2025 09:35:24 GMT

We use Otii to measure the device’s power consumption.

Before disconnect, the device can enter low-power mode, consuming around 3-4uA. However, if the rejoin fails or the gateway is never powered on, the device will never enter low-power mode (I tested for about 30 minutes), and it will continuously consume 3.8mA.

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Thu, 07 Aug 2025 07:21:56 GMT

Your application also goes down after it rejoins the network:

You can see that I disconnected the coordinator in the middle, but then turned it back on. In the marked section (the greyed out) you can see that it goes back into low power mode, with an average of 392µA (I turned on UART logging, so it will be lower if this is disabled).

What are you using to measure the current consumption? And what does it look like before you disconnect it from the network? What is the current consumption then?

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Wed, 06 Aug 2025 13:57:06 GMT

This is what I see using the unmodified light_switch sample:

The chunk in the middle is when I removed the coordinator, and when I powered it back on, it went down to normal current consumption (which is a bit high in this case, but logging was turned on, keeping the HFCLK running at all times).

I will test your application tomorrow (I spent a bit too long getting the Zigbee addon up and running, so didn't have time for it today)

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Wed, 06 Aug 2025 01:26:13 GMT

Yes, only a few modifications were made to the light switch example.If possible, could you help test the power consumption using the official development board?devzone.nordicsemi.com/.../3487.light_5F00_switch.zip

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Tue, 05 Aug 2025 12:53:44 GMT

Hello,

Is this with one of our samples or your own application? If so, have you tried to measure on e.g. the light_switch sample? Is it similar?

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Mon, 04 Aug 2025 01:48:42 GMT

The phenomenon I observed is that the device did not enter a low-power state during the interval between two rejoins. Moreover, even after the rejoin process ended (approximately 15 minutes later), the device still did not enter a low-power state, and there was a continuous current of 3.8 mA.

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Fri, 01 Aug 2025 10:58:35 GMT

Yes. That is the expected behavior. After it either successfully joins a network, or the join attempt times out, the radio should be powered off, and it should enter a low power state. What is it that you are observing? Have you tried measuring the current consumption using a PPK2 board?

Best regards,

Edvin

RE: ABOUT ZIGBEE OF NRF54L15

sg3 — Fri, 01 Aug 2025 00:53:54 GMT

Hi, Edvin:

We hope that after the rejoin process is completed, even if it is not successful, the child device can still enter the low-power mode normally.

RE: ABOUT ZIGBEE OF NRF54L15

Edvin — Wed, 30 Jul 2025 08:27:06 GMT

Hello,

Sorry for the late reply, Jermi. We are a bit short staffed due to summer holidays here in Norway.

What you are seeing is probably that when the node is no longer part of the network, it tries to rejoin the network, and hence, the radio is being used a lot more than when it is in the low power state.

How do you want the device to behave? Do you want it to remain shut down the radio when it leaves? One possibility would be to start the rejoin process on a button press, perhaps? Or perhaps you can have it try to rejoin immediately, but only for a few minutes? I believe this is actually what it is doing, but I don't know how long you observed the device after it lost the network.

Best regards,

Edvin