The nRF5 Software Development Kit for Thread and Zigbee helps you when developing products for these protocols with Nordic Semiconductor's advanced nRF52 devices.
Both the Zigbee stack and the Thread stack and examples are production level.
Release Notes:
nRF5 SDK for Thread and Zigbee v4.2.0 ------------------------------------- Release Date: Week 14, 2022 This release is a minor production-ready release of the Zigbee features available on the nRF52840 and nRF52833 devices. The Zigbee stack is based on the ZBOSS stack v3.11 and conforms to Zigbee PRO R22 and Green Power Proxy Basic specifications. The Zigbee stack provided by the release is planned for certification by Connectivity Standards Alliance as a Zigbee Compliant Platform for nRF52840 and nRF52833. The certification status can be verified in the Zigbee CID compatibility matrix for nRF52840 (https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nrf52840_zigbee_cids.html) and nRF52833 (https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52833/COMP/nrf52833/nrf52833_zigbee_cids.html). The Nordic Zigbee software solution released as part of the nRF5 SDK for Thread and Zigbee incorporates the Base Device Behavior specification (ver. 3.0.1) and the ZCL specification (ver. 8). This enables to build, certify, and ship commercial Zigbee 3.0 Certified Products. Software components and application examples for MDK, peripherals, Bluetooth LE, and NFC have been inherited from the nRF5 SDK v16.0.0. No new changes to nRF5 SDK v16.0.0 have been made compared with the nRF5 SDK for Thread and Zigbee v4.0.0. This release includes the Thread feature implementation released in the nRF5 SDK for Thread and Zigbee v4.1.0. ****** SDK in maintenance mode ****** Since the release v4.1.0, the nRF5 SDK for Thread and Zigbee is in maintenance mode. This means that all new designs should be started using the nRF Connect SDK. More information: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/nrf-connect-sdk-and-nrf5-sdk-statement --------------------------------------- ****** Release highlights ****** - Zigbee: Updated the ZBOSS stack to a recent version and added support for the ZCL specification ver. 8. - Thread: No changes were made to Thread features in this release. ****** 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. ****** Multiprotocol limitations ****** - Interrupts with IRQ priority 2 and 3 must not be used for multiprotocol examples. - Because of limitations of simultaneous operation of the SoftDevice frontend and the 802.15.4 frontend: - Do not use the PPI channels reserved by the SoftDevice (17, 18, 19). - The SoftDevice and the 802.15.4 driver must use separate sets of PPI channels, for example (1, 2) and (3, 4). - The SoftDevice and the 802.15.4 driver must use separate sets of GPIOTE channels, for example 4 and (5, 6, 7). - Due to a limitation of the SoftDevice, depending on the configured timeslot timeout of the nRF IEEE 802.15.4 radio driver, Bluetooth LE activity may cause 100% CPU utilization or increase switching times. The details are presented in the official documentation in the Multiprotocol considerations section, available in Thread and Zigbee shared features > Multiprotocol support with BLE/Bluetooth > Dynamic multiprotocol. - Three-pin Front End Module is not supported due to SoftDevice limitations. *** Environment *************** The following toolchains and tools have been used for testing and verification of the examples: - GCC: GCC ARM Embedded 7.2018 q2 update - SES: SES 4.12 - nRF Command Line Tools: 10.14.0 - J-Link: 7.52d - nrfutil: 6.1.3 (available from https://github.com/NordicSemiconductor/pc-nrfutil) Supported SoftDevices for multiprotocol support: - S140 v7.0.1 Supported boards: - PCA10056 (from version 1.0.0) - PCA10059 - PCA10100 ****** Thread ****** This release includes the Thread feature implementation released in the nRF5 SDK for Thread and Zigbee v4.1.0. No changes were made to Thread for this release.