the original author is zigmaster.

Hashed Link Keys are a shortcut for unique link key storage on devices with constrained key table capacity.  They facilitate pseudo-random link keys by hashing the remote's EUI64 with a given Master Key (chosen by the centralized Trust Center and stored in the Global Link Key slot of TOKEN_STACK_TRUST_CENTER's data) using the AES HMAC algorithm.  Derivation of the key can then be done "just in time" for decryption or encryption as long as the Trust Center knows the remote node's EUI64.  Note that because there is no permanent storage of these hashed keys on the Trust Center, there is also no memory of incoming APS frame counters, so this method has a vulnerability of APS replay attacks.  Also note that the hashing only occurs on the Trust Center side, where many keys may be needed.  Other nodes receive this Trust Center Link Key upon request from the TC and treat it like any other "randomly" derived TCLK.

Hashed Link Keys are enabled on a centralized Trust Center node by setting the EMBER_TRUST_CENTER_USES_HASHED_LINK_KEY bit in the EmberInitialSecurityBitmask during emberSetInitialSecurityState() prior to forming the network.

If you know the Master Key, you can get Network Analyzer to give you the hashed link key for a given EUI64.... Just go into Network Analyzer's Security Key preferences (Window >> Preferences >> Network Analyzer >> Decoding >> Security Keys) and click the "Run HMAC" button.  Then input your Master Key and an EUI64 to get the HMAC hashed key.

By default our mesh stacks use the LFRCO. It was found that using the internal low frequency RC oscillator instead of an external crystal fit most use cases. However, for certain situations where timing is important the RC oscillator is not adequate. To improve timing accuracy a couple of things can be done:

1. Switch to a low frequency external oscillator (LFXO) which most of our BRDs (found in the dev kit) already have.
2. To further improve timing using an external oscillator, adjust the capacitor tuning value (CTUNE). The optimal value depends on parameters like board, layout, crystal, and temperature.

This KBA deals with locating and downloading the wireless mesh stacks. If you are looking for information on getting access to the stacks, go here.

Once you have registered and gotten access to our wireless mesh stacks, you can download the stacks in one of two places. First is Simplicity Studio v4 the second is the support portal.

Simplicity Studio

Simplicity Studio v4 allows for easy integration of the stacks within the development tools. Using the easy to use Package Manager, you can quickly download stacks and have them ready to use within just a few minutes.

To download the stacks, you first need to go to the Launcher perspective of Studio and click on the Update Software button which can be found in the tool bar.

The stacks appear in the SDK Tab of the package manager (you might need to click through the Installation Manager windows to get to this page).

Within this tab you can find all of the available stacks for you. They are sorted by categories. The view allows you to see all categories or just narrow down to a single category, like EmberZNet or Thread. You can also choose which versions you want, looking at just the latest, all available versions or the ones you have installed. You can also look at the versions which match a version of the Gecko Suite, so you will have the matched versions of different stacks.

If you have access to unreleased stack versions, certain beta stacks can be found within the Early Access tab.

Be mindful that not every stack is available through Simplicity Studio, only stacks from around mid-2016. Most components like ECC Libraries are also not found within Studio either. For these you will need to locate them within the support portal. 

Support Portal

If you want to install the stacks separately from Studio or are looking to locate for packages that are not available within Studio, you can locate them within the support portal.  This includes older software like the ISA3 Utilities and Ember Desktop.

To locate these, you will need to log into your portal account and click on the Software Releases tab within your account. From there you can use the pulldown menu to change display options, the All Software tab shows everything if you are looking for that.

Contact support with any questions or problems.

Background:

Currently in 6.2.3 stack release, the EFR32 sniffer function is still under developing. For customers, the sniffer function is unavailable for EFR32 device. However, some custom are developing the sub-GHz devices and have strong requirement to capture the sub-GHz network with sniffer. There are two ways to capture the sub-GHz network:

• Capture the sub-GHz device directly, which needs the device joined to the sub-GHz network.
• Set up a sniffer with Nodetest to capture the sub-GHz network.

This article is a guidance to describe the second method. Hope it can help custom to develop sub-GHz device quickly.   

Hardware for setup:

Three WSTK main boards, one BRD4155A radio board, two BRD4150C radio boards.

• 1 WSTK main board + BRD4155A radio board  -- Form subGHz network
• 1 WSTK main board + BRD4150C radio board -- Join subGHz network
• 1 WSTK main board + BRD4150C radio board – Nodetest to capture subGHz network

Set up steps:

1. Use the BRD4155A board to form the sub-GHz network. The BRD4155A works in NCP mode. Connect the BRD4155A to PC with USB cable.
   1. Flash the ncp-uart-use-with-serial-btl-ecc-6.2.0.s37 to BRD4155A board. Please note you should also flash the uart bootloader for it.
   2. Build the SeSampleCommsHubHost sample first in Cygwin, then Launch the SeSampleCommsHubHost.

>> ./build/exe/SeSampleCommsHubHost.exe -p com2

1. Form sub-GHz network with below CLI commands:

>> network form 11 3 0x1234
>> network multi-phy-start 28 15 0
>> network pjoin 200

1. Flash the Nodetest to BRD4150C board, and set the BRD4150C board works in the same sub-GHz channel and in Rx mode.
   1. Flash C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.2\protocol\zigbee\build\nodetest-cortexm3-iar-efr32mg1p133f256gm48-efr32gb-brd4150c\nodetest.s37 to BRD4150C board. Please note you should also flash the bootloader for it.

>> commander flash C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.2\protocol\zigbee\build\nodetest-cortexm3-iar-efr32mg1p133f256gm48-efr32gb-brd4150c\nodetest.s37

1. Launch the console in Simplicity Studio, and you can see feedback if you enter any character. Please make sure the Nodetest works well.
2. Set sub-GHz channel for this BRD4150C board, it should the same as the previous formed sub-GHz network.

    >> setChannel 0x8F

1. Set this board in Rx mode

         >> rx

1. Start capture by right click the adapter in Simplicity Studio.

1. Use another BRD4150C board to join the sub-GHz network.
   1. Build a sub-GHz SOC project with BRD4150C board.
   2. Flash the firmware and bootloader to BRD4150C board.
   3. Launch the console in Simplicity Studio and join the sub-GHz network.

>> network join 0x8F 3 0x1234

Then you can see the package is captured by network analyzer in Simplicity Studio. See below picture for your reference.

Please note, you should make sure the sub-GHz device can join the sub-GHz network successful.

Under most circumstances you will want to build a Z3 Coordinator with our Z3Gateway sample application. However, this requires building an NCP and a host app and utilizing a PC or Raspberry Pi. However, you can also build a much simpler Coordinator with our Z3Light sample application. It requires a few changes to the Z3 Light application.

1. On the ZNet stack tab of the application, Change device type to Coordinator or Router
2. On the Plugins Tab:
   1. Include Network Creator plugin
   2. Include Network Creator Security plugin
   3. Within the Network Creator Security plugin you will also need to enable Trust Center Support

Once this is done, you can then generate your application and build it.

Once you have built and loaded your application from the CLI you can start a centralized network with the following command:

plugin network-creator start 1

EmberZNet Stack has Event control mechanism that basically allows application to run a piece of code at desired time interval, Typical examples of usage of events would be. 

1. To generate a periodic delay with only few lines of code. 

2. To run a piece of code which can be activated from an ISR but run outside of ISR at desired interval.

First step is to add a new custom event to the events list inside Simplicity Studio.

Following is a code snippet that can generate a periodic delay of approximately 3 seconds with only a few lines of code in your callbacks file.

#define MY_DELAY_IN_MS 1000

EmberEventControl myDelay;

void emberAfMainInitCallback(void)
{
  emberEventControlSetDelayMS(myDelay, 3 * MY_DELAY_IN_MS);  //Set delay for 3 seconds
}

void myDelayHandler(void)
{
  // First thing to do inside a delay event is to disable the event till next usage
  emberEventControlSetInactive(myDelay);
  
  //Do something
  emberAfCorePrintln("----Inside my delay handler----");

  //Reschedule the event after a delay of 3 seconds
  emberEventControlSetDelayMS(myDelay, 3 * MY_DELAY_IN_MS);  
}

Note: For more accurate timing requirements in time critical systems, usage of hardware timer is recommended instead of event control mechanism because the timing of event controls is based on system tick which depends on the platform. For example, 

* ::MILLISECOND_TICKS_PER_SECOND on the EM357 SoC is 1024, so each tick is therefore 1000 / 1024 = ~0.98 milliseconds.  Calling emberEventControlSetDelayMS(someEvent, 100) on the EM357 SoC will schedule the event for 100 ticks * (1000 milliseconds / 1024 ticks) = ~97.7 milliseconds.

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

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?

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

ISA3 Utilities

For assistance using these utilities, please refer to this user guide:

UG107: ISA3 Utilites