Configuring Zigbee in nRF Connect SDK

This page describes what is needed to start working with Zigbee in nRF Connect SDK.

Required libraries and drivers

Zigbee requires the following modules to properly operate in nRF Connect SDK:

  • ZBOSS Zigbee stack available in nrfxlib, with the OSIF subsystem acting as the linking layer between the ZBOSS stack and nRF Connect SDK. OSIF implements a series of functions used by ZBOSS and is included in the nRF Connect SDK’s Zigbee subsystem. The files that handle the OSIF integration are located in nrf/subsys/zigbee/osif.

  • IEEE 802.15.4 radio driver - This library is automatically enabled when working with Zigbee on Nordic Semiconductor’s development kits.

Mandatory configuration

To use the Zigbee protocol, set the CONFIG_ZIGBEE Kconfig option. Setting this option enables all the peripherals required for the correct operation of the Zigbee protocol and allows you to use them.

After that, you have to define the Zigbee device role for the Zigbee application or sample by setting one of the following Kconfig options:

Setting any of these options enables the respective ZBOSS role library. This is needed because End Devices use different libraries than Routers and Coordinators.

For instructions about how to set Kconfig options, see Configuring your application.

Sleepy End Device behavior

The Sleepy End Device (SED) behavior is a Zigbee stack feature that enables the sleepy behavior for the end device.

By default, the end device regularly polls its parent for data. When the SED behavior is enabled and no frames are available for reception after the last poll, the SED disables its radio until the next scheduled poll. The Zigbee stack’s own scheduler informs the application about periods of time when nothing is scheduled for any of the device roles. This allows the stack to enter the sleep state during these periods, which also powers off some peripherals for the SED.

When the Zigbee stack thread goes to sleep, the Zigbee thread can enter the suspend state for the same amount of time as the stack’s sleep. The thread will be automatically resumed after the sleep period is over or on an event.

In the Zigbee samples in nRF Connect SDK, the sleepy behavior can be triggered by pressing a predefined button when the device is booting. This action results in calling the ZBOSS API that activates this feature. See the light switch sample for a demonstration.

Note

This feature does not require enabling any additional options in Kconfig.

Power saving during sleep

With the sleepy behavior enabled, the unused part of RAM memory is powered off, which allows to lower the power consumption even more. The sleep current of MCU can be lowered to about 1.8 uA by completing the following steps:

  1. Turn off UART by setting CONFIG_SERIAL to n.

  2. For current measurements for nRF52840 DK board (PCA10056) or nRF52833 DK board (PCA10100), set SW6 to nRF ONLY position to get the desired results. See Working with nRF52 Series for more information about these kits.

Optional configuration

After enabling the Zigbee protocol and defining the Zigbee device role, you can enable additional options in Kconfig and modify ZBOSS stack start options.

Device operational channel

You can enable one of the following alternative options to select the channel on which the Zigbee device can operate:

IEEE 802.15.4 EUI-64 configuration

The Zigbee stack uses the EUI-64 address that is configured in the IEEE 802.15.4 shim layer. By default, it uses an address from Nordic Semiconductor’s pool.

If your devices should use different address, you can change the address according to your company’s addressing scheme.

An IEEE EUI-64 address consists of two parts:

  • Company ID - a 24-bit MA-L (MAC Address Block Large), formerly called OUI (Organizationally Unique Identifier)

  • Extension identifier - a 40-bit device unique identifier

You can configure the EUI-64 for a device in the following ways:

Use the default

By default, the company ID is set to Nordic Semiconductor’s MA-L (f4-ce-36). The extension identifier is set to the DEVICEID from the factory information configuration registers (FICR).

Replace the company ID

You can enable CONFIG_IEEE802154_VENDOR_OUI_ENABLE to replace Nordic Semiconductor’s company ID with your own company ID. Specify your company ID in CONFIG_IEEE802154_VENDOR_OUI.

The extension identifier is set to the default, namely the DEVICEID from FICR.

Replace the full EUI-64

You can provide the full EUI-64 value by programming certain user information configuration registers (UICR). For nRF52 Series devices, the CUSTOMER registers block is used. For nRF53 Series devices, the OTP registers block is used.

To use the EUI-64 value from the UICR, enable CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE and set CONFIG_IEEE802154_NRF5_UICR_EUI64_REG to the base of the two consecutive registers that contain your EUI-64 value.

The following example shows how to replace the full EUI-64 on an nRF52840 device:

  1. Enable CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE.

  2. Specify the offset for the UICR registers in CONFIG_IEEE802154_NRF5_UICR_EUI64_REG. This example uses UICR->CUSTOMER[0] and UICR->CUSTOMER[1], which means that you can keep the default value 0.

  3. Build and program your application erasing the whole memory (replace serial_number with the serial number of your debugger):

     west build -b nrf52840dk_nrf52840 -p always
     west flash --snr serial_number --erase
  4. Program the registers UICR->CUSTOMER[0] and UICR->CUSTOMER[1] with your EUI-64 value (replace serial_number with the serial number of your debugger):

     nrfjprog --snr serial_number --memwr 0x10001080 --val 0x11223344
     nrfjprog --snr serial_number --memwr 0x10001084 --val 0x55667788
     nrfjprog --snr serial_number --reset

    If you used a different value for CONFIG_IEEE802154_NRF5_UICR_EUI64_REG, you must use different register addresses.

At the end of the configuration process, you can check the EUI-64 value using Zigbee shell:

> zdo eui64
8877665544332211
Done

Note

Alternatively, you may use the Production Configuration feature to change the address. The Production Configuration takes precedence over the shim’s configuration.

ZBOSS stack start options

Zigbee is initialized after Zephyr’s kernel start. The ZBOSS stack can be started using one of the following options:

The dedicated thread can be configured using the following options:

Custom logging per module

Logging is handled with the CONFIG_LOG option. This option enables logging for both the stack and Zephyr’s Logging API.

Stack logs

The stack logs are independent from Zephyr’s Logging API. To customize them, use the following options:

The stack logs are provided in a binary (hex dump) format.

Zephyr’s logger options

Zephyr’s Logging starts with the default ERR logging level (only errors reported). This level is used by default by the application.

You can configure custom logger options for each Zigbee and ZBOSS module. To do this, configure the related Kconfig option for one or more modules that you want to customize the logging for:

For each of the modules, you can set the following logging options:

  • LOG_LEVEL_OFF - Turns off logging for this module.

  • LOG_LEVEL_ERR - Enables logging only for errors.

  • LOG_LEVEL_WRN - Enables logging for errors and warnings.

  • LOG_LEVEL_INF - Enables logging for informational messages, errors, and warnings.

  • LOG_LEVEL_DBG - Enables logging for debug messages, informational messages, errors, and warnings.

For example, setting CONFIG_ZBOSS_TRACE_LOG_LEVEL_INF will enable logging of informational messages, errors, and warnings for the ZBOSS Trace module.

Upgrading Zigbee application

When upgrading the Zigbee application, use the Static configuration of the Partition Manager to ensure that ZBOSS’ NVRAM is placed in the same area of flash. This is because enabling additional features (for example, Zephyr’s Non-Volatile Storage (NVS)) can change the placement of the partition in the flash and the ZBOSS settings can be lost, as the application is not able to find the partition.

The static configuration is required regardless of the application version and the upgrading method (Zigbee FOTA or Secure bootloader chain).