How to form Zigbee 3.0 network with EmberZnet stack?
As you know, currently the Zigbee Alliance only certificates the Zigbee 3.0 devices, some customers are familiar with HA1.2 network, but for Z3.0 network, there are many differences. This article is talking about how to form Z3.0 network with EmberZnet stack. Hope it is helpful for some junior Zigbee engineers who develop the Z3.0 devices.
Before we talk about the Z3.0 network, let's review the HA1.2 network quickly. It is easy to setup HA1.2 network, especially, Silicon labs provide lots of CLI commands which can be used conveniently. Here are the examples:
1. For HA1.2 network
// Form HA1.2 network on coordinator >> network form [channel:1] [power:1] [panId:2] eg: >> network form 12 3 0x1234
If you want to search for an unused Channel and Pan Id, and automatic form a network on the first unused Channel and Pan Id it finds, you can use below CLI command.
// Form HA1.2 network >> network find unused
Permit joining after the network is formed.
// Permit joining >> network pjoin [time:1] eg: >> network pjoin 200
// Joining a network >> network join [channel:1] [power:1] [panId:2] eg: >> network join 12 3 0x1234
2. For Z3.0 network
The Zigbee Alliance specifies the details of Z3.0 network in docs-13-0402-13-00zi-Base-Device-Behavior-Specification.pdf, any customers can download this file on Zigbee website if they are members of Zigbee Alliance.
First, you should know the difference between the Centralized and Distributed network in Z3.0 network.
Centralized security network:
A centralized security network is a ZigBee network formed by a ZigBee coordinator with the functionality of a Trust Center. Each node that joins such a network is authenticated with the Trust Center before it can operate on the network.
Distributed security network:
A distributed security network is a ZigBee network formed by a ZigBee router and which does not have a Trust Center. Each node that joins such a network is authenticated by its parent before it can operate on the network.
Then, let's use CLI commands to form the Z3.0 network. If you want to form Z3.0 network, you can use below CLI command:
// Form Z3.0 network. >> plugin network-creator form [centralized:1] [panId:1] [radioTxPower:1] [channel:1] //Form centralized network. >> plugin network-creator form 1 0x1234 3 12 //Form distributed network. >> plugin network-creator form 0 0x1234 3 12
If you want to search for an unused Channel and Pan Id, and automatic form a network on the best unused Channel and Pan Id it finds, you can use below CLI command.
// Form Z3.0 network. >>plugin network-creator start [useCentralizedSecurity:1] //Form centralized network. >> plugin network-creator start 1 //Form distributed network. >> plugin network-creator start 0
Permit joining after the network is formed.
// Permit joining >> plugin network-creator-security open-network
If you want to join the network for routers or end devices, you can use below CLI command:
//option = 0 means the device will update TCLK after joining centralized network succeed, //otherwise it won’t. >> plugin network-steering start [options:1] // Update TCLK after joining network succeed. >> plugin network-steering start 0
Please note that, for router devices, it will form distributed network once it fails to join centralized network.
In conclusion, you can use above CLI commands to setup Z3.0 network, meanwhile, we have Z3Gateway/Z3LightSoc/Z3SwitchSoc samples in stack, you can build these samples to do testing quickly. If you want to get more details about the implementation of the CLI commands, please refer to the source code in plugins (Network Creator/Network Creator Security/Network Steering/Update TC Link Key).
How to build the Gecko Bootloader for variant EFR32 chips?
From the v6.1 EmberZnet stack and later, Silicon Labs didn't provide pre-build bootloader for EFR32 chip in stack. All the customers should build the Gecko Bootloader by themselves. This article is a guidance about how to build the Gecko Bootloader for variant EFR32 chips.
If custom would like to build the Gecko Bootloader for radio boards (eg, brd4151a/brd4162a). It is easy to do that, since we have lots of Gecko Bootloader samples in stack. Meanwhile, custom can choose the Board and Part Number for the bootloader sample, then generate the project and build it directly. Usually, there is no error happened in this case.
If custom would like to build the Gecko Bootloader for variant EFR32 chips, because there is no board can be chose for this chip, custom may meet some compiler errors when they build the bootloader. This article is talking about this case and hope it can help custom to create the Gecko Bootloader quickly.
Here are the details about how to build the Gecko Bootloader for variant EFR32 chips step by step.
In conclusion, it is not difficult to build the Gecko Bootloader for variant EFR32 chips base on the bootloader sample in stack. Due to there is no board can be chose, the key point is to configure the .hwconfig file for your project. If you meet any compile errors, please check the related modules in .hwconfig file. We are also recommended custom to create a Gecko Bootloader sample with Radio Boards (eg, brd4151a/brd4162a) for reference.
If the isd file is too big, Simplicity Studio can't open the whole file directly. but you can use the below way to open the selected interval of the isd file.
1. open the isd file with Simplicity Studio, it shows as below.
2. disable the "Auto-zoom' option.
3.drag the mouse from start timestamp to the end timestamp to select the interval.
4. click Open interval button, the selected interval of the isd file will be opened.
The ISA3 Utilities are a set of software tools for the Silicon Labs Ember ISA3 Debug Adapter. With these tools you can manipulate adapter firmware as well as program chips in the EM35x and EM35xx family of parts. The latest downloads of these parts can be found here:
For assistance using these utilities, please refer to this user guide:
The Simulated EEPROM v1 and v2 libraries responsible for abstracting non-volatile data storage ("tokens") across the underlying flash wear-leveling medium are designed to accommodate changes in token definitions between the in-memory data on the chip and the compile-time parameters used by the currently running application. This is done at SimEEPROM initialization time by examining the token metadata at the top of each SimEEPROM virtual page (see AN703 for background), which records the size in bytes and creator ID (a unique 16-bit value defined in the token header) of each token, and comparing this with the running application's token definitions.
In general, the result of the token comparison will be as follows:
Also note that changes between SimEEPROM versions can impact the tokens: