[Zigbee] Sleepy end device get out of sleep in approx 10 mins

[Tu Hoang]

Hi everyone,

I have this question to ask. So I am trying do make an end device that run on low power. I can see that there is an example about the sleepy end device in the Zigbee and Thread SDK 4.1. So i try it and measure the current through the prolifier kit. Because i am running a NRF52833 on a custom board(just some with some io pins to use led and button), i run the code for PCA10100 on the light switch example. Then, I also modify some part of the code like delete the finding and binding part as well as pressing a button for the device to go sleepy but instead got sleepy automatically at startup. In addition, i also use the RTT log instead of the UART backend log.ut

When i first measure the power by the prolifier board version 1, it is get to 2.4uA on average, so good so far. But then, when i measure for a little longer like in 15 mins, the current start to go up to 80uA at 10-11mins i did not even start to commission the device to the coordinator. This is really weird since I keep like 90% of the code in the example. So, I have not modified any part of the code so that i can send it to you. Also, I try to not start the zigbee module and just run  __WFE() and __SEV() in the main while(1) loop and it working just fine. So i have a wild guess that there are some thing need to be done in the zigbee configuration that i miss.

Please help and reply soon, I attach the code i make with this.

Test_lowpower.zip

Best regards,

Hoang Ngoc Tu

[ovrebekk]

Hi 

Unfortunately most of my colleagues experienced with Zigbee are on holiday for this week and next, so it is a bit limited what Zigbee support we can provide until they are back. 

Have you done any testing with the debugger to try and figure out what might be happening when the current consumption increases?

Might there be any log output that could indicate something?

Would you say it happens consistently after a reset, at the same time?

Best regards
Torbjørn

[Tu Hoang]

Hi Ovrebekk,

Nice to meet you.

Yes, i have a JlinkV9 debugger and use RTTViewer to see the log. I also put the code below in the zigbee handler and it is showing the time it have before waking up. In the first 10 mins, it just showing occationally the sleep_tmo. and the number are changing correctly (from the maximum timeout to to 0) but after 10 mins or even less, the sleep_tmo is poping up repeatedly (like in milisec). Beside that, I do not have anything in the log since the code i modified from the example are at the bare minimum of the example. I guess this have something to do with the Zigbee since i am not starting anything else but a buttons and some leds.

This is always happen every time after i reset and start up the program.

        case ZB_COMMON_SIGNAL_CAN_SLEEP:
            {
                zb_zdo_signal_can_sleep_params_t *can_sleep_params = ZB_ZDO_SIGNAL_GET_PARAMS(p_sg_p, zb_zdo_signal_can_sleep_params_t);
                NRF_LOG_INFO("Can sleep for %ld ms", can_sleep_params->sleep_tmo);
                zb_sleep_now();
            }
        break;
        

Hope that help,

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

I am sorry for the delay.

I do not already know of any reason for the current consumption to suddenly go up after 10 minutes. I have tried to look into it to see if I could figure out why this is happening, but I have not been able to find an explanation as of yet. Are you able to turn on more logging? If you get logging from the zigbee_default_signal_handler() in zigbee_helpers.c, then you might see if the Zigbee stack generates any signal that is handled there when the current increase happens.

I have asked our developers if they know what might be the cause of this.

Best regards,

Marte

[Marte Myrvold]

Hi Tu,

This might be caused by the sleep period being longer than RTC overflow, as RTC overflow is 520 seconds, which is rather close to 10 minutes. Please try to make the following changes in external/zboss/osif/zb_nrf52_timer.c:

// In file: external/zboss/osif/zb_nrf52_timer.c
// make two changes
///////////////////////////////////////////
// Need this defines for later sleep period
// calculations.
// 
// Change this block:
#define ZB_NRF52_TIMER_VALUE    15360  /*microseconds in one beacon interval*/
// to this block:
#define ZB_NRF52_TIMER_VALUE      15360  /*microseconds in one beacon interval*/
#define MS_PER_S                  1000UL /* Miliseconds in one second. */
#define RADIO_DRIVER_RTC_OVRFLW_S 512UL  /* Time that has passed between overflow events. On full RTC speed, it occurs every 512 s. */
#define ZB_NRF52_MAX_SLEEP_PERIOD_MS  ((RADIO_DRIVER_RTC_OVRFLW_S - 1) * MS_PER_S) /* Zigbee max sleep period to prevent RTC timer overflow. */
///////////////////////////////////////////
///////////////////////////////////////////
// Workaround for long zigbee sleep period.
// Sleep period longer than RTC overflow,
// results in very short sleep scheduled,
// waking up the CPU frequently.
// 
// Change this block:
m_timer.dt        = 1000 * sleep_tmo;
// To this block:
/* Workaround for long zigbee sleep period.
 * Device wakes up on RTC event and scheduling sleep period
 * longer than RTC overflow (512 seconds) can result in very short sleep scheduled
 * whick wakes up CPU frequently and increases power consumptiom.
 */
m_timer.dt        = 1000 * ((sleep_tmo > (ZB_NRF52_MAX_SLEEP_PERIOD_MS)) ? (ZB_NRF52_MAX_SLEEP_PERIOD_MS) : (sleep_tmo));
///////////////////////////////////////////

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Thank you for the reply, so as i can see the value RADIO_DRIVER_RTC_OVRFLW_S the the amount of time in second that a device is allow to sleep.Anyway, I will try it and tell you the result.

Thank you for your help,

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

Have you been able to test the workaround? Did it work, or are you still experiencing this issue?

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Sorry for the late reply, I have tested the new setting for the SDK and let the board run for 12 hours straight to find out that the power consumption did not suffer from the waking problem like before. So I guess that your walkaround solve the problem.

Thank you very much, I could not do it without your support.

Best regards and have a nice day,

Tu