How to form Zigbee 3.0 network with EmberZnet stack?

Background:

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

• On coordinator, if you want to form the network on the given channel, power and Pan Id, you can use below CLI command:

// 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

• On router or end device, if you want to join the network, you can use below CLI command.

// 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

Open network after the network formed. If you go through the detailed implementation of this CLI command, it sets the TC policy and opens the network, but additionally puts the well known key into the transient key table.

// open network
>> 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?

Background:

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.

Steps:

1. Please find the part number of your chip. For example, I build a Gecko Bootloader for EFR32MG1P232MG48.
2. Create a Gecko Bootloader sample for your chip.

   

3. Please decide which Gecko Bootloader you want to be built. Here are the different Bootloaders for different user cases. The a.i/a.ii are used for the external SPI flash (eg, MG1P/MG1B/MG1V). The a.iii/a.iv/a.v are used for internal main flash (eg, MG12/MG13). The b.i/b.ii are used for NCP.
   1. Application Bootloader(for SOC): 
      1. SPI Flash Storage Bootloaders(single image)
      2. SPI Flash Storage Bootloaders(multiple images)
      3. Internal Storage Bootloaders(single image on 1MB device)
      4. Internal Storage Bootloaders(single image on 512K device)
      5. Internal Storage Bootloaders(multiple images)
   2. NCP Bootloader(for NCP):
      1. UART XMODEM Bootloader
      2. EZSP SPI Bootloader
4. For example, I will build a SPI Flash Storage Bootloaders (single image) for EFR32MG1P232MG48.

   

5. Click “Next” and type the project name. Please note that I suppose there is no boards for this part number, so I only choose the right Part (EFR32MG1P232MG48) for the project.

   

6. Click “Finish”.
7. Generate the project.
8. Open the *.hwconf file. Double click the custom_efrmg1p232f256gm48.hwconf and broswer to “DefaultMode Peripherals”.

   

9. Configure the “CMU” module. If you don’t use the external 32.768k crystal on your board, please set the “False” for “LFXO present on board” under LFXO item. For HFXO, you can set the CTUNE value directly or through reading it from mfg token.

   

    
10. Configrure the “DCDC” module, you need enable this module if your board using the internal DCDC in EFR32 chip, otherwise disable it.

    

11. Configure the “SPI Flash” module. Set the “USART connected to SPI Flash” and GPIO for “Chip Select Pin”.

    

12. Configure the “USART1” module. Set the USART MOSI/MISO/CLK/CS pin for USART1.

    

13. Save the *.hwconfig file.
14. Build the project.
15. Download {ProjectName}-combined.s37 to your board.

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 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:

• If the size of a Basic or Counter token or per-element size of an Indexed token has changed, the token is assumed to be different/incompatible and will be re-initialized at startup to its compile-time default value.
• Regarding Indexed (array) tokens: If an array size is decreased, elements above the new array size will be flagged as out of range and ignored.  If an array size is increased, elements that are not found in flash will be loaded from default values.
• If the token type (Basic/Counter/Indexed) has changed, the token is considered different and will be reinitialized to its default value.

Also note that changes between SimEEPROM versions can impact the tokens:

• If the saved data is in SimEEPROM v1 format and the new firmware uses SimEEPROM v2 Library and does not include upgrade library code (sim-eeprom2-1to2upgrade-stub plugin used), the SimEEPROM code will fail to initialize and will reset with an assert() failure, leaving intact the existing tokens in flash.
• If the saved data is in SimEEPROM v1 format and the new firmware uses SimEEPROM v2 Library and does include upgrade library code (sim-eeprom2-1to2upgrade), the SimEEPROM code will attempt to preserve all tokens in the manner noted earlier in this article and convert them into SimEEPROM v2 format.
• If the saved data is in SimEEPROM v2 format and the new firmware uses SimEEPROM v1 Library and does not include the plugin option for "Destructive downgrade", the SimEEPROM code will fail to initialize and will reset with an assert() failure, leaving intact the existing tokens in flash.
• If the saved data is in SimEEPROM v2 format and the new firmware uses SimEEPROM v1 Library and does include the plugin option for "Destructive downgrade", the SimEEPROM code will remove/reinitialize all token data, setting them to their compile-time default values.