Zigbee power consumption with Thread and Zigbee SDK 4.2.0

[Cheb]

HI,

I recently migrated my nrf52840 based devices to Thread and Zigbee SDK 4.2.0

I used to have a good power consumption around 100-150uA with zigbee enabled.

Since SDK migration I'm seeing high power consumption when zigbee is active (device is paired). If my device isn't paired power consumption is very low. (< 100uA)

Are there any changes relative to low-power management with this new SDK that I should be aware off ?

If that can be of any help here is a screenshot of the power profiling.

Thanks,

Sebastien

[Cheb]

Hi,

It's a sleepy end device.

Previous SDK was Thread and zigbee 4.1.0

Here is what the current consumption used to look:

Cheers,

Sebastien

[Edvin]

Ok, that makes more sense. 

It looks like the device is not entering the low power mode correctly (the high "waves" looks like they are the radio). Is there some way for me to reproduce this on some DKs?

Best regards,

Edvin

[Cheb]

Unfortunately that would be too complicated to reproduce on ref designs.

But just to be sure, there are no SDK changes that could explain different behavior regarding low-power mode ?

[Edvin]

Well, According to the release notes, these are the updates (from v4.1.0):

****** Zigbee ******
This is a minor production-ready release of the Zigbee features available on the nRF52840 and nRF52833 devices.

*** New features
****************
- Added support for the ZCL specification ver. 8 (ZCL8).
  This version is backward-compatible with earlier versions of ZCL.
  The following cluster implementations were tested with ZUTH using SDK nRF5 SDK for Thread and Zigbee samples:
  
  - Basic
  - Identify
  - Level
  - On/Off
  - OTA
  - Groups

*** Changes
***********
- Added support for the BDB specification 3.0.1.
- Added sources of the ZCL and BDB ZBOSS stack layers (previously delivered as part of ZBOSS library).
- Updated the ZBOSS stack to v3.11.1.0 (v3.11.1.0).
- Updated the ZBOSS OSIF layer with SDK configuration options that allow to either reset or halt the device upon ZBOSS stack assert. Reset is enabled by default.
- Aligned the ZBOSS OSIF layer with the new ZBOSS, which is required to build applications with the new stack version.
- Changed the ZBOSS timer.
  ZBOSS now uses the 802.15.4 radio driver timer as time source, instead of using a dedicated peripheral.
- Removed support for IAR and Keil compilers for Zigbee. 

*** Bugfixes
************
- Included bug fixes for the following issues related to the ZBOSS stack:

  - [ZBS-130] ZR may send Link Status between Leave packets 
  - [ZBS-131] OTA Upgrade End callback to be called only on success upgrade 
  - [ZBS-163] APS max frag size fix 
  - [ZBS-172] OTA Upgrade Started callback is not called on delayed Image Block Response 
  - [ZBS-209] Incorrect parsing of LEAVE command in nwk_handle_zed_leave_confirm 
  - [ZOI-529] Unlocking Trust Center address which is not locked 
  - [ZOI-669] Missing Trust Center Rejoin 
  - [ZOI-698] Incorrect APS ACK handling if the ACK is received before the transmission is completed 
  - [ZOI-315] User's ZDO command complete callback can block NWK Input queue 
  - [ZOI-617] Clearing BRRT structure causes memory corruption 
  - [ZOI-81] ZBOSS secur stmt: PanID conflict resolution and NWK manager policy 
  - [ZOI-473] ZR kicks out child ZED if it doesn't set keep-alive timeout option 
  - [ZOI-515] Deadlocks in ZB_INTERRUPT_SAFE_BUFS and ZB_INTERRUPT_SAFE_ALARMS 
  - [ZOI-560] Malformed Route Records in case of enabled MTORR and inability to find the last element in Route Discovery Table 
  - [ZOI-586] APS User Payload feature is broken 
  - [ZOI-215] Access a buffer after freeing during indirect transmission 
  - [ZOI-380] Device asserts in case of absent APS ACK during fragmented transmission 
  - [ZOI-395] Buffer leak in the ZDO channel manager
  - [ZOI-427] Wrong check for valid ranges in osif_nvram_xxx 
  - [ZOI-322] Incorrect return value in zdo_mgmt_leave_cli() if 'cb' == NULL 
  - [ZOI-297] ZBOSS asserts after receiving the leave command 
  - [ZOI-172] APS update device memory leak 
  - [ZOI-217] Link Status is not sent when device type is unknown 
  - [ZOI-80] The value returned by zb_bdb_is_factory_new() is not updated 
  - [ZOI-93] ED Timeout keep-alive method disables polling for rx_off End Device 
  - [ZOI-94] No packet sending between two local EPs in one group 
  - [ZOI-102] The ZB_ZCL_DECLARE_POWER_CONFIG_ATTRIB_LIST() causes compilation errors 
  - [ZOI-137] Device gets kicked out of the network if it does not finish the first association 
  - [ZOI-145] Memory corruption in ZCL callback 
  - [ZOI-147] ZB_ZDO_SIGNAL_DEVICE_AUTHORIZED is not generated for legacy devices 
  - [ZOI-168] ZBOSS generates malformed packets if it receives a Route Request with an extended destination address 
  - [ZOI-170] Fix unknown device type for neighbor 
  - [ZOI-171] End Device generates invalid network address request if application tries to communicate with an unreachable device 
  - [ZOI-95] An issue with reporting between two local EPs 
  - [ZOI-104] Bug in zb_bdb_reset_via_local_action() function 
  - [ZOI-111] Using more than 10 entries of reporting configuration leads to NVRAM corruption 
  - [ZOI-113] Corrupted firmware pointer in OTA handler 
  - [ZOI-123] ZC can change its address during conflict resolution 
  - [ZOI-127] More ZED role runtime checks 
  - [ZOI-130] No APSDE-DATA.conf after sending APS packet to itself via binding 
  - [ZOI-133] Non-sleepy ZED drops Device Annce 
  - [ZOI-46] Frame counters are not reset after NWK key exchange 
  - [ZOI-63] Address unlock issue for ZDO MGMT Leave requirement
  - [ZOI-13] The usage of channel_mask inside production configuration
  - [ZOI-16] Periodic reporting attributes does not work if binding performed after reporting max interval 
  - [ZOI-35] Unable to configure reporting on multi-endpoint device 
  - [ZOI-60] Network permits new devices after device leave 
  - [ZOI-78] BDB status not cleaned by Leave or Factory Reset after F&B target starts

- Fixed the KRKNWK-5826 issue where multi-endpoint device would have reporting configured for only one of its endpoints.
- Fixed the KRKNWK-5702 issue where it would be impossible to initialize both Control4 cluster and Power Config Cluster.
- Fixed the KRKNWK-3255 issue where it would be impossible to cancel the OTA upgrade by sending Default Response with code ABORT in response to an OTA Upgrade End Request sent by the client.
- Fixed the KRKNWK-4666 where under high-load conditions, it would be possible that the Sleepy End Device would enter ZB_ABORT() after losing connectivity with its parent.
- Fixed an issue where an incorrect Read Attributes response would be returned when reading multiple attributes and the first one was unsupported.
  The supported attribute would then be contained twice in the response: as unsupported and supported in two consecutive records.
- Fixed an issue where the maximum size of a reportable character string attribute would be limited to 7 characters.

*** Limitations
***************
- Support for IAR and Keil compilers was removed for the v4.2.0 release.
- The ZBOSS stack may assert if the device is requested to leave the network. (KRKNWK-12500)
- If the coordinator node exceeds the maximum number of children, it will not allow for new devices, even if some of the existing children leave the network. (KRKNWK-11826)
- End Device does not recover after broken rejoin procedure. (KRKNWK-12345)
- Group List field in Get Group Membership Response command does not contain groups which destined endpoint is assigned to, but all groups from all endpoints from a requested device. (KRKNWK-12615)
- Zigbee coordinator asserts during simultaneous commissioning of multiple devices. (KRKNWK-12115)
- Public API zb_secur_ic_get_list_req() returns a response using the buffer which content cannot be read because non-public zb_aps_installcode_nvram_t structure is used to fill it. (KRKNWK-11840)
- Migration from the nRF5 SDK for Thread and Zigbee version earlier than v4.0.0 is not supported.
- Zigbee performance might be affected by heavy flash operations.
  Zigbee stack subsystem periodically runs the migration process.
  As the flash operations block the CPU, this may affect Zigbee time-critical processes (Association, Rejoin, Leave, GreenPower Commissioning, among others) if these operations occur at the same time with such processes.
  The likelihood of this happening is low, but this may occur if the Parent device is joining 20+ devices one-by-one without delays, or in other cases of mass NVRAM operations in intersection with the mass radio operations.
  This issue does not affect the steady state operation. (KRKNWK-3263)
- Binding table entry number with unique source address, endpoint, and cluster ID is limited to 32. (KRKNWK-3282)
- For Windows users, the path length limitation to 255 characters can create issues when unpacking the SDK files.
  Make sure the SDK files are unpacked close to the disk drive path, for example C:/sdk.
- In case of an MCU reset between the completion of the OTA image transfer and a postponed firmware upgrade, the upgrade will be applied immediately.

So it may be that some of these changes affects your application. 

Did you try to monitor the log from the application? Does it indicate that everything is going as expected, or does it say that something is not going as intended? 

When the pattern repeats every ~1 second, does the application reset, or is it running continuously?

Best regards,

Edvin

[Cheb]

Hi Edvin,

It seems the main differences are the calls to zb_osif_sleep(zb_uint32_t sleep_tmo) which I monitor.

With SDK 4.1.0 ZBOSS stack used to call it for 3 seconds periods and only wake-up briefly in between.

Now the the sleep duration is most of the time smaller < 1sec and there is a lot of activity before calling sleep again.

And my application doesn't reset btw.

Regards,

Sebastien

[Cheb]

Hi,

I finally found what was causing the issue.

My application main loop was calling nrf_pwr_mgmt_run(); without taking care of zboss stack.

That was fine on 4.1.0 but on 4.2.0 I had to implement a cleaner handling:

• get sleep notification from zboss stack and duration
• only call nrf_pwr_mgmt_run() during the provided duration

Thx for your support,

Sebastien