End Device reports bad behavior on low power device

[sjf]

Hi,

We have been working with an end device based on nRF52840 with nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b, Softdevice and FreeRTOS.

We built 2 configurations for this device: normal and low power. The last one contains some considerations like:

- At FreeRTOSConfig.h we set configUSE_TICKLESS_IDLE to 1

-We enabled SoftDevice Low power mode and enabled DCDC mode

-Also set SCB_SCR_SLEEPDEEP_Msk flag

Once joined to a Zigbee network, some cluster bindings are performed automatically to the coordinator and some reports are automatically being sent. The max time for each one is 60 seconds while the min timeout is 0.

On normal configuration, attribute reporting is accomplished without problem every 60 seconds. But in the low power configuration, times get longer and seem to increase with the time.

Is there any special consideration or appropiate setting for low power mode?

Regards,

Santiago

[Marte Myrvold]

Hi Santiago,

Is the problem that attribute reporting takes longer than 60 seconds when in low power mode? Is the time it takes the same every time or is it a random delay, so the time it takes changes every time?

How are you implementing the low power mode on the end-device?

Best regards,

Marte

[sjf]

Hi Marte,

The attribute reporting takes more than max time (60 seconds) and seems to increase on further reports (not random)

The low power mode is implemented with the changes detailed above. Also we are implementing this in the Zigbee Task (FreeRTOS):

zb_void_t zb_osif_go_idle(zb_void_t)
{
    /* Intentionally empty implementation */
#ifdef LOW_POWER
    nrf_802154_sleep_if_idle();
    /*do not set long timeout if joining*/
    if(ZIGBEE_STATE_JOINING != zigbee.state)
    {
      zigbee.cmd_queue_timeout = ZIGBEE_QUEUE_LONG_TIMEOUT;
    }
#endif
}

And also calling nrf_802154_sleep_if_idle() function on ZB_COMMON_SIGNAL_CAN_SLEEP signal handler.

Regards,

Santiago

  

[Marte Myrvold]

Hi Santiago,

I have asked our Zigbee team internally and will come back to you when I get a response from them.

Best regards,

Marte

[sjf]

Thanks Marte,

Is there any update on this?

Regards,

[Marte Myrvold]

Hi,

No, sorry, I'm still waiting for a response from the Zigbee team. They're quite busy right now, so it might take some time, but I've asked them if there are any updates dates on this case.

Best regards,

Marte

[Marte Myrvold]

Hi,

I got a reply from the Zigbee team now. They're not sure what the problem is, but they would start with these steps:

• Make sure that sleepy behavior is enabled for the end device
• Get rid of calls to nrf_802154 radio API - Sleepy End Device manages radio state and with sleepy behavior enabled, the radio is in standby when not used by the end device
• ZBOSS uses TIMER3 to keep time - make sure that its configuration is not changed

Some more information about the application would be helpful, as well as the traffic dump of the End Device reporting.

Best regards,

Marte

[sjf]

Hi Marte, thanks for your explanation.

I understand that if configUSE_TICKLESS_IDLE mode is set, then Timer3 will be stopped every time we get into deep sleep mode. 

I've checked that there is a non documented function called zb_zcl_adjust_reporting_timer(). Maybe it is related to this issue...

How can we avoid stopping Timer3 when going to sleep?

regards,

[sjf]

Hi Marte,

Is there any comment on this?

We need to get a response to get it work as soon as possible.

Regards,

[Marte Myrvold]

Hi Santiago,

I apologize for the late response.

The reason for the delay in attribute reporting might be caused by the fact that ZBOSS, or the Zigbee stack, is not aware of the fact that FreeRTOS sleeps, and as such, it will take longer time.

Please note that the examples with FreeRTOS in the Zigbee SDK are experimental, and are therefore not power optimized. However, I got some tips from the Zigbee team on how to implement low power with FreeRTOS and Zigbee:

In order to suspend the task, while the timer is disabled, you have to implement ZB_COMMON_SIGNAL_CAN_SLEEP ZBOSS signal handler. Otherwise, you are simply leveraging only the ZBOSS IDLE state, not the ZBOSS SLEEP state (more information about those states can be found here).

For some guidance and ideas how to implement this, it might be good to look at the OSIF implementation in NCS:

- CAN_SLEEP handler
- sleep routine (will be called by zb_sleep_now())
- Poll function

The signalling mechanism is used to wake up ZBOSS task by other tasks that wants to send something over Zigbee, as well as to wake up the ZBOSS task earlier than the sleep period, passed to the sleep function as an argument.

Best regards,

Marte

[sjf]

Hi Marte, 

I will try to do some measurements with Power Profiler as well as changing the source code with your recommendations.

. Just to be sure: Sleepy End Devices are set by just calling zb_set_rx_on_when_idle(ZB_FALSE).

. You suggest to implement ZB_COMMON_SIGNAL_CAN_SLEEP. I'm thinking on implement a modified version of zb_osif_sleep() on configPRE_SLEEP_PROCESSING and configPOST_SLEEP_PROCESSING.

Do you agree with this? Any other recommedation?

Regards

[Marjeris Romero]

Hi sjf,

sjf said:

Just to be sure: Sleepy End Devices are set by just calling zb_set_rx_on_when_idle(ZB_FALSE)

Yes, and you need to enable the End Device role in the application as well of course.

But sleep functionality is not implemented for OS-based applications applications in the nRF5 SDK for Thread & Zigbee. This is why the multisensor example with FreeRTOS is categorized as "experimental", and the CAN_SLEEP event are overwritten in main.c to being empty.
You may be better off migrating to NCS if you don't want to go through all the work on implementing sleepy functionality yourself for RTOS in nRF5 SDK.

The ZB_COMMON_SIGNAL_CAN_SLEEP signal will be sent to the application when RxOnOnWhenIdle is set to 'False' anytime the scheduler finds out that the application can go to sleep, read more about this in 'Power saving for ZED'. You need to handle this signal to suspend any tasks and then go to sleep. zb_sleep_now() must be called from the ZB_COMMON_SIGNAL_CAN_SLEEP signal.

Then you need to implement your own sleep routine, as the OSIF implementation in nRF5 SDK is not written for OS implementations.

If you call zb_sleep_now() the stack will call zb_nrf52_sleep(). See external/zboss/osif/zb_nrf52_common.c this function is implemented as a weak function, so you can implement it in your application without changing common components.

You also need to have some signaling structures to wake up the ZBOSS task whenever is needed (as is done in NCS with zigbee_event_poll()).

Comparing the implementation of zb_nrf52_sleep() on the nRF5 SDK to the zigbee sleep function on NCS zb_osif_sleep() we see some differences and similarities, but there are probably several things you will need to modify to make the sleep implementation in nRF5 SDK RTOS-friendly. Some points to consider:

• zb_nrf52_priph_disable() This function disables all Zigbee stack related peripherals (except the radio which is handle by the stack), but may not be correct when sharing resources with other components that may want to use these peripherals even if the radio is sleeping.
• zb_nrf52_sched_sleep(sleep_tmo):sets an alarm inside the radio driver so the MCU is woken up by the RTC clock after an specific timeout value. This not valid for RTOS solutions. You should lock the RTOS thread for a specific amount of time and give the context down to the idle task which implements sleep functionality.
• zb_osif_wait_for_event(): ZBOSS task should not be woken up upon every single event. Not needed if RTOS is in use.
• time_slept_ms = zb_nrf52_get_time_slept(): every implementation of zb_nrf52_sleep_has to return the actual time (in milliseconds), so the zboss timer may be fast-forward to the correct time value.
• zb_nrf52_priph_enable(): need to enable everything that was previously disabled.

Best regards,

Marjeris

EDIT: I edited my answer to be clear that you have to call zb_sleep_now() from the ZB_COMMON_SIGNAL_CAN_SLEEP signal. It's not allowed to call zboss API from other thread that the one running main loop iteration. The signal handler is the ZBOSS context (called from the main loop iteration).