AN1089: Using Installation Codes with
Zigbee Devices
This application note provides an overview of using installation
codes with Zigbee devices. It also explains (with the help of examples) how to use Simplicity Commander to check, write, verify,
and erase installation codes on Silicon Labs Wireless Gecko
(EFR32™) devices. Finally, it provides a complete example of
how to join a Z3 network with an installation code-derived link
key.
Silicon Labs recommends that you be familiar with creating example applications and
using the Network Analyzer, as described in QSG106: Zigbee EmberZNet PRO Quick
Start Guide.
KEY POINTS
• Concepts of the Zigbee installation code
• Programming examples for installation
codes on EFR32 devices
• Checking, writing, verifying, and erasing
installation codes on target devices
• Joining a Z3 network with an installation
code-derived link key
silabs.com | Building a more connected world. Rev. 0.5
AN1089: Using Installation Codes with Zigbee Devices
Installation Code Overview
1. Installation Code Overview
1.1 What Is an Installation Code?
Zigbee installation codes, sometimes also referred to as “install codes,” are provided as a means for a device to join a Zigbee network
in a reasonably secure fashion. The installation code itself is a random value installed on the joining device at manufacturing time, and
is used to encrypt the initial network key transport from the Zigbee network’s centralized Trust Center device (the coordinator) to the
joining device. With the creation of the Zigbee 3.0 standard in late 2016, all Zigbee devices capable of joining networks (as opposed to
forming them) must support the use of installation codes during joining, as this is a requirement for Zigbee 3.0 compliance.
The installation code can be thought of as similar to the PIN code on Bluetooth devices when two devices are paired. The PIN code is
provided as an authorization code for the parent device so that the joining device knows it is receiving information securely, such as
when a hands-free headset is paired to a smartphone.
The installation code is typically printed on the case or packaging of the device, either as a hexadecimal string or in an encoded fashion
such as a barcode or QR code, and provided through an out-of-band mechanism to the Trust Center device or its associated web/cloud
interface, along with the 64-bit IEEE MAC address (“EUI64”) of the device. If this device-specific data is stored on a remote web server
or cloud-based system, that remote system then securely transports that information to the Trust Center to establish security credentials for the joining device in advance of the in-band joining process.
1.2 Caveats for Zigbee Smart Energy (ZSE) Devices
The Trust Center and the joining device use the installation code as a shared key to establish an initial bond of trust allowing the new
device to join the Zigbee network. Once the device has successfully joined the network for which it is authorized, Zigbee requires that
the node negotiate a new Trust Center link key for future secure exchanges with the Trust Center. In standard Zigbee 3.0 networks, this
occurs through a key request directly to the Trust Center. However, in Zigbee Smart Energy networks, which behave differently from
standard Zigbee 3.0 networks, the new Trust Center link key is derived through a special process known as Certificate-Based Key Establishment (CBKE). For more information about the CBKE process, refer to UG103.05: IoT Endpoint Security Fundamentals. Note that
the CBKE process requires installing CBKE data certificates signed by Certicom during the manufacturing process. Refer to AN708:
Setting Smart Energy Certificates for Zigbee Devices for details about how to set these certificate data. Also consult AN714: Smart
Energy ECC-Enabled Device Setup Process for more information about the requirements for preparing Zigbee smart energy (ZSE) de-
vices to be able to join a network and for troubleshooting this process.
This document outlines common practices relating to installation codes for either a standard Zigbee 3.0 device or a ZSE device.
silabs.com | Building a more connected world. Rev. 0.5 | 2
AN1089: Using Installation Codes with Zigbee Devices
Security Use
2. Security Use
An installation code is used to create a preconfigured, link key. The installation code is transformed into a link key by use on an AESMMO hash algorithm. For more information and sample code, consult the Install Codes section of the Security chapter of the Zigbee
Alliance’s Base Device Behavior Specification (Zigbee document #13-0402).
The installation code, while not exactly a secret, cannot be easily guessed by a malicious device that hears the initial exchange between the joining device and the Trust Center. Without knowledge of the installation code and thus the key, the malicious device cannot
decrypt the messages.
The derived Zigbee link key will be known only by the Trust Center and the joining device. The Trust Center uses that key to securely
transport the Zigbee network key to the device. Once the device has the network key, it can communicate at the network layer to the
Zigbee network. It has the ability to perform service discovery and begin the application’s initialization process. In Zigbee 3.0 (non-ZSE)
networks, having the network key is often enough for standard messaging across various clusters. However, ZSE networks have additional restrictions as discussed below. See 7. Example: Joining a Z3 Light to a Z3 Gateway Using an Installation Code-Derived Link Key
for a step-by-step procedure to use an installation code-generated link key for network joining.
The initial link key derived from the installation code does not have full access privileges on a ZSE network. Attempts to use it for Smart
Energy messaging are not allowed and will be ignored by other ZSE devices. Shortly after joining a network, a device must use the Key
Establishment cluster to establish a new link key with the Trust Center via the CBKE process. Only when key establishment completes
successfully will a device have full privileges on the network and be able send and receive certain ZSE messages.
silabs.com | Building a more connected world. Rev. 0.5 | 3
AN1089: Using Installation Codes with Zigbee Devices
Installation Code Format
3. Installation Code Format
While Zigbee smart energy networks allow the installation code to be comprised of either 6-, 8-, 12-, or 16-byte random, hexadecimal
number with a 2-byte CRC appended to the end, Zigbee 3.0 (Z3) networks specifically require 16-byte hexadecimal installation codes,
also accompanied by a 2-byte CRC. Note that the CRC16 should be delivered to the user in little endian byte order, as this is what is
expected when the code is entered into the device that performs the AES-MMO hash algorithm. As far as the user is concerned, the
CRC is part of the installation code and they do not need to know that it is there or why. Therefore, from the user’s point of view, the
length of the install code is 18 bytes (with potentially 8-, 10-, or 14-byte variants possible in ZSE devices).
Manufacturing and managing the list of installation codes will play a part in choosing the size, security, and user experience in installing
the device. A larger installation code size will mean less of a chance of an attacker “guessing” the installation code and eavesdropping
on the initial join. However, smaller installation code is much easier for a user to read off the device during installation.
Note: The Zigbee 3.0 Base Device Behavior Specification requires that you only use a 16-byte installation code. While this may be
more difficult to enter, it provides sufficient strength against an attacker from guessing the installation code and gaining unauthorized
access to network or device.
silabs.com | Building a more connected world. Rev. 0.5 | 4
AN1089: Using Installation Codes with Zigbee Devices
Installation Code CRC
4. Installation Code CRC
The installation code CRC is mechanism used to verify the integrity of an installation code when it is transmitted via an out-of-band
mechanism to the utility. This transport mechanism involves human interaction in some way. As a result, the CRC was designed as a
way to verify that an installation code is valid and was not mistakenly changed during transport.
The Zigbee installation model enables users to install a device themselves. Users simply read the installation code on the back of the
device and enter it into a webpage or provide it over the phone to a utility service. Because the number is a hexadecimal value, it is
easy to transpose digits or read the wrong value.
4.1 Validation
The Zigbee specification expects that the server processing the out-of-band installation code entry from the installer will perform basic
checking of the installation code for validity. The server then calculates the CRC over all bytes in the installation code except the final
two. It then compares the final two bytes of the installation code with the calculated CRC to see if they match. If they do not match, the
user entering the installation code can be informed immediately that it does not look valid. The user should then double-check the value.
Zigbee specifications do not require the Trust Center to validate the installation code directly. (Any validation can be done on a remote
web- or cloud-based server if the Trust Center doesn’t have this capability locally.) The Trust Center expects to receive a pre-configured link key along with the EUI64 of the new joining device. It does not need to have any knowledge about how that key was derived. It
is up to the particular utility how it wishes to manage and transport the link key to the Trust Center.
For details on how the CRC is calculated, including sample code, consult the Install Codes section of the Security Chapter of the Zigbee 3.0 Base Device Behavior Specification (Zigbee document #13-0402).
4.2 Generation
Silicon Labs recommends that the installation code be a random number. This reduces the chances of an attacker guessing the installation code and compromising the initial join procedure. The installation code should not be based on the manufacturing process, such
as tied to the EUI64 or sequential numbering based on the manufacturing lot. If that were the case, an attacker with knowledge about
the type of device being joined would have a known range of installation codes it could try to compromise the network and clone the
device’s identity. An installation code does not have to be unique across all Zigbee devices for all manufacturers.
4.3 Labels
The device’s installation code should be printed on a label on the outside of the device along with its EUI64. Both elements should be
identified with text indicating what they are. The installation code should not be printed on the outside of the box because that makes it
easier for an attacker to gain knowledge of the installation code and potentially compromise the device. It is recommended that the
installation code be printed in 2-byte blocks (for example, 83FE D340 7A93 9723 A5C6 39B2 6916 D505 C3B5).
Note: The CRC should be appended to the installation code in little endian format on the label.
4.4 Example
The following is an 18-byte installation code label (16-byte random code with a 2-byte CRC):
83FE D340 7A93 9723 A5C6 39B2 6916 D505 C3B5
The random number portion of the code is the first 16 sequential bytes. The calculated CRC value is 0xB5C3, but it is appended in littleendian format.
silabs.com | Building a more connected world. Rev. 0.5 | 5
AN1089: Using Installation Codes with Zigbee Devices
Programming the Installation Code on a Zigbee Device
5. Programming the Installation Code on a Zigbee Device
5.1 Format of the Installation Code File
To program the installation code, create a simple text file with the value of the installation code (without the CRC). In these instructions
the file is named install-code-file.txt. This file is subsequently passed to em3xx_load or Simplicity Commander.
The format of the file is as follows:
Install Code: <ascii-hex>
Here is a sample installation code file. The CRC for that code is 0xB5C3 and is not included in the file.
Install Code: 83FED3407A939723A5C639B26916D505
5.2 Checking the Installation Code on an EFR32 Device
To get started, it is best to verify there is connectivity with the device to be programmed, and what information is currently stored on the
node. To do this, execute the following command to print all manufacturing token data from an EFR32-based device. The tokendump
command prints manufacturing token data as key-value pairs. Simplicity Commander supports more than one group of tokens. In this
example, the token group named "znet" is used.
$ commander tokendump --tokengroup znet
You should see the following output, where the code in bold below reflects the significant fields related to the installation code:
#
# The token data can be in one of three main forms: byte-array, integer, or string.
# Byte-arrays are a series of hexadecimal numbers of the required length.
# Integers are BIG endian hexadecimal numbers.
# String data is a quoted set of ASCII characters.
#
# MFG_EMBER_EUI_64 : A8D417FEFF570B00
MFG_CUSTOM_VERSION : 0xFFFF
MFG_CUSTOM_EUI_64 : FFFFFFFFFFFFFFFF
MFG_STRING : ""
MFG_BOARD_NAME : ""
MFG_MANUF_ID : 0xFFFF
MFG_PHY_CONFIG : 0xFFFF
MFG_SYNTH_FREQ_OFFSET: 0xFFFF
MFG_CCA_THRESHOLD : 0xFFFF
MFG_EZSP_STORAGE : FFFFFFFFFFFFFFFF
MFG_CTUNE : 0xFFFF
MFG_XO_TUNE : 0xFFFF
MFG_LOCKBITS_PLW : 0x000000000000000000000000FFFFFFFF
MFG_LOCKBITS_CLW0 : 0xFFFFFFFF
MFG_LOCKBITS_MLW : 0xFFFFFFFF
MFG_LOCKBITS_ULW : 0xFFFFFFFF
MFG_LOCKBITS_DLW : 0xFFFFFFFF
MFG_BOOTLOAD_AES_KEY : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
MFG_SECURITY_CONFIG : 0xFFFF
silabs.com | Building a more connected world. Rev. 0.5 | 6
AN1089: Using Installation Codes with Zigbee Devices
Programming the Installation Code on a Zigbee Device
MFG_ASH_CONFIG[0] : 0xFFFF
MFG_ASH_CONFIG[1] : 0xFFFF
MFG_ASH_CONFIG[2] : 0xFFFF
MFG_ASH_CONFIG[3] : 0xFFFF
MFG_ASH_CONFIG[4] : 0xFFFF
MFG_ASH_CONFIG[5] : 0xFFFF
MFG_ASH_CONFIG[6] : 0xFFFF
MFG_ASH_CONFIG[7] : 0xFFFF
MFG_ASH_CONFIG[8] : 0xFFFF
MFG_ASH_CONFIG[9] : 0xFFFF
MFG_ASH_CONFIG[10] : 0xFFFF
MFG_ASH_CONFIG[11] : 0xFFFF
MFG_ASH_CONFIG[12] : 0xFFFF
MFG_ASH_CONFIG[13] : 0xFFFF
MFG_ASH_CONFIG[14] : 0xFFFF
MFG_ASH_CONFIG[15] : 0xFFFF
MFG_ASH_CONFIG[16] : 0xFFFF
MFG_ASH_CONFIG[17] : 0xFFFF
MFG_ASH_CONFIG[18] : 0xFFFF
MFG_ASH_CONFIG[19] : 0xFFFF
#'MFG_CBKE_DATA (Smart Energy CBKE)' token group
Device Implicit Cert :
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
CA Public Key : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Device Private Key : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
# CBKE Flags : 0xFF
#'MFG_INSTALLATION_CODE (Smart Energy Install Code)' token group
# Install Code Flags : 0xFFFF
Install Code : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
# CRC : 0xFFFF
#'MFG_SECURE_BOOTLOADER_KEY (Manufacture token space for storing secure bootloader key.)' token group
MFG_SECURE_BOOTLOADER_KEY : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
#'MFG_CBKE_283K1_DATA (Smart Energy 1.2 CBKE)' token group
Device Implicit Cert (283k1) :
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFpFFFFFFFFF
CA Public Key (283k1) :
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Device Private Key (283k1) :
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
# CBKE FLAGS (283k1) : 0xFF
#'MFG_SIGNED_BOOTLOADER_KEY_X (Manufacture token space for storing ECDSA signed bootloader key (X-point).)'
token group
MFG_SIGNED_BOOTLOADER_KEY_X : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
#'MFG_SIGNED_BOOTLOADER_KEY_Y (Manufacture token space for storing ECDSA signed bootloader key (Y-point).)'
token group
MFG_SIGNED_BOOTLOADER_KEY_Y : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
DONE
The pre-programmed EUI64 is read out by executing the following command:
commander tokendump --tokengroup znet --token MFG_EMBER_EUI_64
#
# The token data can be in one of three main forms: byte-array, integer, or string.
# Byte-arrays are a series of hexadecimal numbers of the required length.
# Integers are BIG endian hexadecimal numbers.
# String data is a quoted set of ASCII characters.
#
# MFG_EMBER_EUI_64: A8D417FEFF570B00
DONE
silabs.com | Building a more connected world. Rev. 0.5 | 7
AN1089: Using Installation Codes with Zigbee Devices
Programming the Installation Code on a Zigbee Device
5.3 Writing the Installation Code into the Manufacturing Area on an EFR32 Device
To write the installation code into the manufacturing area, execute the following command:
$ commander flash --tokengroup znet --tokenfile install-code-file.txt
You should see output similar to the following:
Writing 2048 bytes starting at address 0x0fe04000
Comparing range 0x0FE04000 - 0x0FE047FF (2 KB)
Programming range 0x0FE04270 - 0x0FE04283 (20 Bytes)
Verifying range 0x0FE04000 - 0x0FE047FF (2 KB)
DONE
5.4 Verifying the Stored Installation Code on an EFR32 Device
After writing the installation code, it is best to verify the information by executing the following command again:
$ commander tokendump --tokengroup znet
Output of this command should be similar to that shown in section 5.2 Checking the Installation Code on an EFR32 Device, but with the
MFG_INSTALLATION_CODE data now representing your chosen code and little endian CRC.
silabs.com | Building a more connected world. Rev. 0.5 | 8
AN1089: Using Installation Codes with Zigbee Devices
Erasing the Installation Code
6. Erasing the Installation Code
If you want to remove the install code from the device, simply create an installation code file with the contents as "!ERASE!" such as the
example below, and then program this file into the target per the instructions in section 5.3 Writing the Installation Code into the Manu-
facturing Area on an EFR32 Device.
Install Code: !ERASE!
Confirm the install code content using the procedure explained in section 5. Programming the Installation Code on a Zigbee Device.
Now your MFG_INSTALLATION_CODE token data should reflect all 0xFF bytes.
silabs.com | Building a more connected world. Rev. 0.5 | 9
AN1089: Using Installation Codes with Zigbee Devices
Example: Joining a Z3 Light to a Z3 Gateway Using an Installation Code-Derived Link Key
7. Example: Joining a Z3 Light to a Z3 Gateway Using an Installation Code-Derived Link Key
This example uses command line options to join a Z3 Light to a Z3 Gateway using an installation code-derived link key. The exercise
uses Z3 Light and Z3 Gateway sample applications included with the EmberZNet SDK version 6.3.1 or higher.
This exercise assumes you have already built an SoC-based Z3 Light application with default configurations and a Z3 Gateway application using an NCP+Host setup. For GSDK 2.6 or earlier, make sure the Link Key Table size is at least one entry because the following
commands populate the Link Key Table. The key table size can be configured under the NCP Configuration plugin on the host side. For
GSDK 2.7 or higher, the following commands populate the Transient Key Table which is already sized appropriately. If you are not familiar with building sample applications see QSG106: Zigbee EmberZNet PRO Quick Start Guide for instructions.
1. Make sure the Z3 Light is not on any network. If it is issue network leave.
2. Follow the instructions in section 5. Programming the Installation Code on a Zigbee Device to create an installation code text file,
and program the installation code onto the Z3 Light device.
3. On the Z3 Gateway, form a centralized network with Zigbee 3.0 security using this command in the Network Creator plugin's CLI:
plugin network-creator start 1
4. To derive a link key from the installation code and store that into the key table on the Z3 Gateway, which acts as the Trust Center
for the centralized network, enter:
option install-code <link key table index> {<Joining Node’s EUI64>} {<installation code + 2-byte CRC>}
For example:
option install-code 0 {00 0B 57 FF FE 07 A9 E3} {88 77 66 55 44 33 22 11 11 22 33 44 55 66 77 88 D4 90}
• Starting with GSDK 2.7, this command adds the key entry into the Transient Key Table which is necessary for Z3 joining. For
GSDK 2.6 or earlier, this command populates the Link Key Table. Step 7 shows how to move the key entry from the Link Key
Table to the Transient Key Table.
• For GSDK 2.7 or higher, this command populates the Link Key Table if the gateway is a Smart Energy device and the Transient
Key Table if the gateway is a Z3 device.
• The first argument is the Link Key Table index. This argument matters only when populating the Link Key Table, as is the case
with GSDK 2.6 or earlier. For GSDK 2.7 or higher, the argument has no effect.
• The next argument is the EUI64 of the joining node (in this example, Z3 Light).
Tip: You can find this information by running the CLI info command on the joining node. Look for a string similar to node
[>)000B57FFFE07A9E3].
You can also find the EUI64 from the output of the tokendump command, but note that it is printed in little endian format. You
will need to reverse the bytes to get the proper output.
• The last argument is the installation code with the 2-byte CRC appended at the end.
Tip: You can calculate the CRC yourself, or you can simply find out from running the Simplicity Commander tokendump command:
$ commander tokendump --tokengroup znet
The CRC is displayed just below the install code and is printed in little endian format. Reverse the bytes to big endian before
using as an argument with the option install-code CLI. Because the white spaces inside the curly brackets are not mandatory, you can do a straight copy/paste without the spaces. The spaces are included to help better view the data.
5. To see if the link key is added successfully, enter the keys print CLI on the Z3 Gateway to see it in the Link Key Table or Transi-
ent Key Table. This shows both the link key derived from the installation code, and the network key. Note: In GSDK 2.6 or earlier,
the fact that the option install-code CLI copies the link key to the Link Key Table may not be desirable in practice. To avoid
populating the permanent Link Key Table completely, instead of using the option install-code CLI call the API
emAfInstallCodeToKey() to calculate the joining link key from the install code and keep this link key value ready for steps 6 and 7
below. Alternatively, leave the entry in the Link Key Table and reuse it later in step 7, where the entry is moved to the Transient
Key Table.
6. (Optional but highly recommended, so that you see the joining device join the network as described in step 8.) At this point, you
have all the information the Network Analyzer needs to decrypt future transactions between the Z3 Gateway and Z3 Light. In File >
Preferences > Network Analyzer > Decoding > Security Keys, add both the network key and the link key to the list of security
key. See QSG106: Zigbee EmberZNet PRO Quick Start Guide for more information. Start a new network capture from the Z3 Light
and/or Z3 Gateway. Tip: If you are in a "noisy" environment, you may choose to only capture on the specific PAN.
silabs.com | Building a more connected world. Rev. 0.5 | 10
AN1089: Using Installation Codes with Zigbee Devices
Example: Joining a Z3 Light to a Z3 Gateway Using an Installation Code-Derived Link Key
7. Complete this step only for GSDK 2.6 or earlier: Set the transient link key (the same link key that you derived from the install code)
on the Trust Center and open the network for joining with the joining device’s EUI64:
plugin network-creator-security open-with-key {eui64} {linkkey}
For example:
plugin network-creator-security open-with-key {00 0B 57 FF FE 07 A9 E3} {FA 80 81 CA AA 41 D5 AD E9 B5 65
87 99 26 8B 88}
Once a transient link key exists for the device about to join, remove the unnecessary Link Key Table entry by issuing this command:
keys delete {index}
where {index} refers to the Link Key Table index as shown in the output to keys print.
8. Finally, on the joining device enter this CLI to use the Network Steering plugin to join the network:
plugin network-steering start 0
The joining device should join the network with the transient link key. If you have started a network capture in step 6, you should
see the full transactions live. The Z3 Light is initially allowed on the network using the transient link key. The trust center transports
the network key encrypted with the transient link key in a "Transport Key (NWK)" frame. Subsequently, the Z3 Light requests a new
link key, and the trust center transports that link key in a "Transport Key (Link)" frame.
7.1 Transferring Installation Codes to the Trust Center
In this example, the installation codes were entered manually, but in practice it may not be practical to connect to the Trust Center in
this way. Customers are responsible for implementing installation codes, and should consider a number of details:
• Will the commissioning be done all at the same time (perhaps for a large industrial lighting application), or piece-by-piece in a home
automation setting?
• Will there be an Internet-connected gateway?
• Can the installation codes be written during manufacturing for a pre-commissioned bundle?
• Will initial commissioning differ from later commissioning for added devices or in the case of leaving the network and then re-joining?
• How the network might accommodate a commissioner that would leave and return to a network in a switched multiprotocol scenario?
Here are some methods we envision being used:
• Bluetooth commissioning using our Dynamic Multiprotocol (DMP) feature and a Bluetooth phone app for commissioning. See
UG305: Dynamic Multiprotocol User’s Guide for more information.
• Pre-commissioning at the factory: install codes entered at manufacturing time for trust center and joining devices.
• Bluetooth-based commissioning with Switched Multiprotocol (SMP) on the trust center and a Bluetooth phone app for entering install
codes. See UG267: Switched Multiprotocol User's Guide for more information.
• Using QR codes on joining devices, and using an app to send the install code via WiFi to an internet-enabled NCP gateway.
• Barcode/QR code scanning capability on the trust center.
silabs.com | Building a more connected world. Rev. 0.5 | 11
Smart.
Connected.
Energy-Friendly.
Products
www.silabs.com/products
Disclaimer
Silicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or
intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical"
parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only . Silicon Labs reserves the right to make changes without
further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior
notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance
of the product. Silicon Labs shall have no liability for the consequences of use of the information supplied in this document. This document does not imply or expressly grant any license
to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is
required, or Life Support Systems without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health,
which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs
products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering
such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such
unauthorized applications.
Trademark Information
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, ClockBuilder®, CMEMS®, DSPLL®, EFM®, EFM32®,
EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®,
Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® , Zentri, the Zentri logo and Zentri DMS, ZWave®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a
registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.
Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701
USA
Quality
www.silabs.com/quality
Support and Community
community.silabs.com
http://www.silabs.com
Loading...