Zigbee & Thread Knowledge Base

      • Make customized ZigBee xNCP images for EFR32MG parts

        RonB | 01/23/2018 | 05:58 PM

        Within our EmberZNet and Silicon Labs Thread stacks we provide a number of pre-built NCP images.  However, with the customability EFR32 Mighty Gecko, these NCP images don't always meet every application.  This guide, along with reading AN1010: Building a Customized NCP Application, should give you the tools to build your own xNCP image.


        1. Go to File -> New -> Project. This will bring up the New Project Wizard
        2. Select “Silicon Labs AppBuilder Project”. Click Next.
        3. Select “Customizable network coprocessor (NCP) application”. Click Next.
        4. Select the Stack you want to use. Click Next.
        5. Select xNCP LED. Click Next.
        6. Give your project a name, leave it in the default location. Click Next.
        7. On the Project Setup Window remove any boards that are selected in the top section.  In the bottom section select the chip you are using. Hit Finish.
        8. Download the board header below for your particular stack and copy it into your project (you can drag and drop it into your Project in Studio, when prompted, make sure to Copy the file into your project).
          EmberZNet 5.9.2 and prior: xNCP_board.h
          EmberZNet 5.10.0 and later: xNCP_board_5.10.x.h
        9. On the General Tab
          • Selected Architecture – verify the chip you selected is there
        10. On the HAL Tab
          • Change Board Header from Default to Use Custom Board Header
          • Point the Custom Board Header to file you downloaded in step 8 (it should be in your Studio v4 Workspace)
        11. On the Plugins Tab
          • In the Core section pick the Plug for either NCP-SPI or NCP-UART for the NCP version you are using
          • If you are building a Smart Energy NCP, you will need to enable the CBKE and ECC plugins required for your build.
        12. On the Other Tab
            • (EmberZNet 5.9.2 and prior only) In the Additional .c and .h files section Add the following directories:
        13. Open the board header file from step 8 and make these changes:
          • (EmberZNet 5.9.2 and prior)
            •  Find the #define statements for which build to use
              #define UART_XNCP_BUILD
              #define SPI_XNCP_BUILD
              Comment out the one you aren’t using and make sure the one you need is defined
            • Modify the section to match the interface you have selected.  For UART, setup the Tx, Rx, CTS and RTS pins.  For SPI, setup MOSI, MISO, CS and CLK as well as the nHOST, nWAKE and nSSEL (CS) pins.
              See below for where to find ROUTELOC definitions to match these pins.
          • (EmberZNet 5.10.x)
            • If you are building a UART NCP, edit the section titled /* USART0 */.  Setup Tx, Rx, CTS and RTS pins that you are using for your NCP.
              See below for where to find ROUTELOC definitions to match these pins.
            • If you are building a SPI NCP, edit the section titled /* USART1 */.  Setup the MOSI, MISO, CS and CLK pins.
              Additonally, edit the section titled /* SPINCP */.  You shouldn't have to change the USART port, but match the nHOST and nWAKE pins to your design.
              See below for where to find ROUTELOC definitions to match these pins.
          • You can get the ROUTELOC definitions from the Mighty Gecko datasheet corresponding to your model of Mighty Gecko (MG1, MG12 or MG13).  Links to the datasheets are below.
          • Once the modifications are made, save the file
        14. Generate the files for your project
        15. Build your project

         Use the following KBA for building a bootloader:

        Make customized ZigBee bootloader for the EFR32MG1 QFN32 parts

         Additional Information:

        AN1010: Building a Customized NCP Application

        EFR32MG1 Mighty Gecko ZigBee & Thread SoC Family Data Sheet (Section 6.4)

        EFR32MG12 Mighty Gecko Multi-Protocol Wireless SoC Family Data Sheet (Section 6.4)

        EFR32MG13 Mighty Gecko Multi-Protocol Wireless SoC Family Data Sheet (Section 6.6)

      • How to create custom CLI commands in EmberZNet?

        Lesun | 01/08/2018 | 02:49 AM

        In Zigbee project, you can find lots of prebuild CLI commands can be used for debugging. It is very convenient for every engineer to develop their product. If you type “help” on console, you can find the below CLI commands, it includes but not limited to:


        You can find the details/descriptions for every CLI command in the following documentation after you install the stack:


        But for some customers, they would like to customize their custom CLI commands to implement some special functions, such as control the peripheral or sending some special command to other devices. In this situation, how to create the custom CLI commands base on the current CLI architecture?

        The answer is easily. It is very easy to expand the custom CLI commands with the below steps:

        • Enable the  “Add Custom CLI Sub-menu” checkbox in “Printing and CLI” tab in your {project}.isc.

        • Then you should implement the emberAfCustomCommands[] in your {project}_callback.c file. There is a good example in the XncpLedHost_callback.c, please refer to the XncpLedHost sample. The key point is to implement the functions in emberAfCustomCommands[]. Here is the details as follows:
        EmberCommandEntry emberAfCustomCommands[] = {
                                  "Get the state of an LED on the NCP."),
                                  "Set the state of an LED on the NCP using a custom LED protocol command."),
                                  "Get the current frequency of the LED strobe on the NCP."),
                                  "Set the frequency of the LED strobe on the NCP."),
                                  "Display the XNCP information on the CLI."),
        • After doing that, compile the project and download the firmware to your hardware, launch the console and then you can see the “custom” CLI commands after you type the “help”. That is all steps to create the custom CLI command. Please feel free to contact us if you have further questions.
      • Enabling Read Protection or Write Protection for EM35x Chips

        yuxiao | 01/05/2018 | 02:57 PM

        When preparing EM35x devices for field deployments, it is often desirable to secure the flash contents of the EM35x chip to prevent accidental/unauthorized access or modification. This can be done using the chip’s memory protection (Read Protection and Write Protection) mechanism, described in the EM35x Datasheet in Sections 5.2.1 (Flash Memory) and 5.3 (Memory Protection Unit).

        Below are some of the common questions that customers ask when considering this kind of protection for their devices:

        Q: What kinds of protection are available and what is protected by them?

        A: The chip offers Read Protection and Write Protection.
        Read Protection, when enabled, disconnects all flash from everything else when the chip’s SerialWire/JTAG interface (SWJ) is connected to something. This effectively prevents reading of all flash memory on the device, including the full 128KB or 192KB of main flash block (which covers the bootloader area, application code & data areas, and SimEEPROM token area), plus the FIB (flash information block where Ember-programmed manufacturing tokens and low-level flash read/write routines are stored) and the CIB (customer information block where customer-programmable manufacturing tokens are stored). This also prevents the use of the SWJ bus for SerialWire and JTAG operations such as debugger access and flash programming. Since read protection can only be disabled by writing a specific, non-zero, non-0xFF value to a specific location, the act of erasing of the CIB memory page (where the read protection option byte is contained), whether intentional or accidental, will still leave the chip read-protected until the appropriate option byte is set to the appropriate value.

        Write Protection, when enabled, prevents writing or erasing of the main flash block [MFB], either by external means or through execution of code from flash or RAM. Unlike read protection, write protection is enabled on a per-region basis with each region being 4 pages of flash or 8KB.

        Q: What kind of protection does Ember recommend using for deployed devices into mass production?

        A: For devices that are deployed into the field in scenarios where no further debug or advanced testing is required, Ember recommends enabling Read Protection (which is chip-wide) as well as Write Protection of the first 8KB region, which is the section of the MFB where the bootloader firmware resides.

        Q: How do I enable these recommended protection settings using the ISA3 and ISA3 Utilities?

        A: Enabling these settings requires the use of the ISA3 Utilities from the command line; InSight Desktop does not currently provide an interface for passing these options to the loader through its GUI.

        Enabling Write Protection
        To enable write protection of the first region of main flash (where the bootloader resides), clear (write 0) only Bit 0 of the first option byte for write protection (Option Byte 4) and leave all other bits set (erased state of 1) for a final bitmask of 0xFFFFFE (0xFFFFFFFE for any chips with 512 KB of flash). This can be accomplished with the “—programwrprot” option in em3xx_load or em3xx_buildimage such as:

        em3xx_load.exe --programwrprot FFFFFE
        Note that current Ember implementations are such that write protection of this first region is currently done automatically whenever read protection is enabled. However, setting the write protection mask explicitly to include this first flash region is recommended to ensure consistent results should this automatic behavior change in future tool/silicon revisions.

        Enabling Read Protection
        NOTE: Enabling read protection should always be the last operation you perform on the device with em3xx_load or em3xx_buildimage since setting this option effectively inhibits any future changes to the chip/image state until read protection is disabled (which, in turn, causes the MFB and CIB to be erased).

        To enable read protection, Option Byte 0 of the CIB can be set to 0×00 (though any value other than the special value of 0xA5 will suffice). This can be done using the “—enablerdprot” flag in em3xx_load or em3xx_buildimage, such as:

        em3xx_buildimage.exe --em357 --chipimage myimage.hex serial-uart-bootloader.s37 sensor.ebl --enablerdprot
        This builds an EM357 chip image output file, myimage.hex, from the two input files, serial-uart-bootloader.s37 and sensor.ebl. At the same time, read protection is enabled in the CIB content of the HEX file by setting option byte 0 to the value 0×00. Programming this chip image (the HEX file) to a fresh device will ensure that it contains the necessary application code, bootloader code and read protection. Additional manufacturing token content in the CIB can be set using the “—cibtokenspatch” argument with a manufacturing tokens patch file (as explained by the “—cibtokenspatch-help” argument to em3xx_buildimage or em3xx_load).

        Q: If I enable write protection, how will that affect the bootloader?

        A: (Note that the following applies to all of the bootloader types offered by Ember.) By write-protecting the first 8KB portion of main flash, where the bootloader resides, you prevent accidental/unauthorized overwrites of the bootloader code and the chip’s reset vectors. However, if regions beyond this are write-protected, this will prevent the bootloader from writing the downloaded firmware image into the application area of the MFB, thus rendering it ineffective. This is why Ember recommends leaving write protection disabled for the remaining flash regions if a bootloader is used in the memory map.

        If, for some reason, you wish to deploy a device that doesn’t allow bootloading, you may protect additional regions of the MFB. However, take care not to enable write protection over the area used for Simulated EEPROM, usually the last 8KB region of the MFB (or the last 32KB in some EZSP network coprocessor designs), as this will prevent the stack from writing to the network and security-related tokens that it requires as part of normal operation.

        Q: What about the areas that aren't covered by the write protection settings? Aren't they vulnerable to writes from an external debugger/programmer then?

        A: Yes, areas that are not covered by write protection are potentially vulnerable to erasure and writing from an external debugger/programmer or from errant code executing flash-writing routines, even if read protection is enabled. Read protection will prevent reading of the flash, but the erasing and writing occurs through a flash interface controller, which is never disconnected and is capable of working without needing to read. (Note that Ember’s programming tools will prohibit writing/erasing of the flash when read protection is found to be active, which prevents accidental or malicious corruption of flash data when using Ember’s tools.) Therefore, the safest and most secure mode of operation is to write protect all sensitive areas of flash, except the Simulated EEPROM which must remain writable, and enable read protection. (As discussed above, write-protecting flash regions covered by application code will inhibit updating of the code via the bootloader.)

        Q: What happens if there is a failure, such as reset, while writing an option byte?

        A: If the option bytes themselves were to somehow become corrupted, the chip has a means to detect this state and will only boot into deep sleep mode until the failure is corrected through erasing/reprogramming of the CIB memory page. When corruption is detected, the option bytes are assumed to be the erased state, which will activate read protection. Ember’s em3xx_load tool can detect this failure/corruption, and using the “—fixobfail” argument with this tool will fix the issue.

        Q: What kinds of debugging mechanisms will still be available on a device that has read and write protection enabled in the recommended configuration?

        A: The DEI Port features (which are just TTL interfaces to the GPIOs) of the ISA3 and the PacketTrace Interface [PTI] features (which use alternate functions of the GPIOs for a digital, 2-wire protocol) of the ISA3 are still viable even when Read Protection is enabled. Additionally, normal digital I/O and serial controller usage remain possible when read protection and/or write protection are enabled.

        Q: What about the Virtual UART interface (Serial 0 in InSight Desktop Console)?

        A: Since the Virtual UART mechanism is implemented on top of the ARM Cortex’s SerialWire protocol, which uses the SerialWire/JTAG [SWJ] bus, it isn’t available when read protection is enabled. Read protection and SWJ bus access are mutually exclusive. However, you can still utilize the physical UART of the chip (TXD and RXD pins, PB1 and PB2) if the chip’s running firmware enables it. These TTL signals can be routed through the DEI interface of the ISA3 for access as “Serial 1” in the InSight Desktop Console as illustrated on the EM35x Breakout Board hardware.

        Q: If I enable read and write protection, can I disable them later?

        A: Yes, it’s possible to disable read protection and/or write protection using the ISA3 Utilities.

        Disabling read protection is accomplished through the use of the “—disablerdprot” command argument with em3xx_load or em3xx_buildimage, which causes Option Byte 0 to be set to the special value of 0xA5. Any other state for Option Byte 0 causes read protection to remain active. Note that disabling this feature on an actual chip (with em3xx_load) will cause its MFB and CIB (besides Option Byte 0) to be fully erased back to 0xFF bytes.

        Disabling write protection is accomplished using the “—programwrprot” command argument to set the write protection option bytes back to an all-0xFF state, such as “em3xx_load —programwrprot FFFFFF”. (Note that a “programmed” state of 0xFFFFFF is handled differently than an erased [unprogrammed] state, since checksum values for each option byte are also programmed by the ISA3 Utilities when an option bye is programmed. Once an option byte is programmed, the CIB must be erased before that option byte’s value can be changed.

        Q: After disabling read protection, is anything NOT erased?

        A: Yes, the FIB (where Ember-programmed manufacturing tokens are stored) is left intact after read protection has been disabled. The MFB and CIB are not preserved when read protection has been disabled. Although the chip’s automatic erasure during deactivation of read protection only affects the MFB (where stack and application tokens reside along with bootloader and stack/application firmware), the act of patching the option bytes in the CIB to deactivate read protection requires that the entire CIB page be erased and re-written (as erasures can only occur on a per-page basis), and since the existing CIB content is unreadable until the unprotected state (value 0xA5 for Option Byte 0) is written, the newly written CIB page resulting from the CIB patching process must consist of fully erased bytes (other than Option Byte 0), meaning that none of the original CIB content can be preserved.

      • Why is the CS controlled manually by software rather than being controlled directly by the USAR1 in SPI driver for Gecko Bootloader?

        Lesun | 01/03/2018 | 10:29 PM

        We usually choose an external SPI flash for devices to storage firmware during OTA. For EFR32MGXX device, we configure USART1 as SPI to connect with the external SPI flash. So you can find a SPI master driver (btl_driver_spi.c) for the external SPI flash in Gecko Bootloader.

        If you are interested in the SPI master driver source code, you will find the CS is controlled manually by software rather than being controlled directly by the USAR1.

        Let's go through the source code btl_driver_spi.c. Please look at the function spi_init(void) in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.1\platform\bootloader\driver\ btl_driver_spi.c

        void spi_init(void)
          CMU_ClockEnable(cmuClock_GPIO, true);
          CMU_ClockEnable(BTL_DRIVER_SPI_USART_CLOCK, true);
          // MOSI
          // MISO
          // CLK
          // CS#
          // Don't do USART_InitSync here since it pulls in ClockFreqGet which is a
          // terrifyingly large function
          // Make sure disabled first, before resetting other registers
                                      | USART_CMD_TXDIS
                                      | USART_CMD_MASTERDIS
                                      | USART_CMD_RXBLOCKDIS
                                      | USART_CMD_TXTRIDIS
                                      | USART_CMD_CLEARTX
                                      | USART_CMD_CLEARRX;
          // Set up for SPI
                                       | USART_CTRL_SYNC
                                       | USART_CTRL_CLKPOL_IDLELOW
                                       | USART_CTRL_CLKPHA_SAMPLELEADING
                                       | USART_CTRL_MSBF;
          // Configure databits, leave stopbits and parity at reset default (not used)
                                        | USART_FRAME_DATABITS_EIGHT;
          // Configure baudrate
          uint64_t clkdiv;
            clkdiv = (128ULL * BSP_CLK_HFXO_FREQ) / HAL_EXTFLASH_FREQUENCY - 256;
          } else {
            clkdiv = (128ULL * 19000000) / HAL_EXTFLASH_FREQUENCY - 256;
          clkdiv = (128ULL * 19000000) / HAL_EXTFLASH_FREQUENCY - 256;
          clkdiv = ((clkdiv + 128) / 256) << 8;
          clkdiv &= _USART_CLKDIV_DIV_MASK;
          BTL_DRIVER_SPI_USART->CLKDIV = clkdiv;
          // Finally enable (as specified)
                                           | USART_ROUTEPEN_RXPEN
                                           | USART_ROUTEPEN_CLKPEN;
                                            | BTL_DRIVER_SPI_USART_RXLOC
                                            | BTL_DRIVER_SPI_USART_CLKLOC;


        From above source code, you can find the function spi_init(void) in btl_driver_spi.c, which initial the SPI TX/RX/CLK. Both the registers ROUTEPEN and ROUTELOC0 are configured for these three pins. However, ROUTEPEN and ROUTELOC0 are not configured for CS. Instead, it is controlled manually by software.

        In C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.1\platform\bootloader\driver\ btl_driver_spi.c

        void spi_setCsActive(void)
        void spi_setCsInactive(void)

        In C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.1\platform\bootloader\plugin\storage\spiflash\btl_storage_spiflash.c

        static void writePage(uint32_t address, const uint8_t *data, uint32_t length)
          sendCommand(CMD_PAGE_PROG, address);
          while (length--) {


        So far, you may have a concern why is the CS controlled manually by software rather than being controlled directly by the USAR1. The answer is:

        The SPI master driver doesn’t use DMA. This means that if the AUTOCS functionality is used, CS will go high and low again between every single byte that is transmitted (because the hardware doesn’t know that there will be another byte, since software hasn’t put it in the FIFO). This doesn’t work with most SPI slaves/protocols, since they expect CS to go low at the start of a packet, and high at the end after multiple bytes. Therefore, CS is controlled by software.

      • Building a Thread Router Eligible End Device Application (with Silicon Labs Thread 2.5.0) Part 1.

        kpszupin | 12/365/2018 | 08:59 PM

        A step-by-step guide to creating, building, and running your own Router Eligible End Device (REED) application based on the Silicon Labs Thread stack. Before tackling this tutorial, please checkout "Building Thread Sample Applications" tutorial first.

        This KBA works with:

        • Simplicity Studio Platform v4.1.14
        • Wireless Tools v4.25
        • Silicon Labs Thread Stack 2.5.0
        • IAR Workbench 7.80
        • Wireless Starter Kit (WSTK)
        • EFR32 BRD4162A

        I. Launch Simplicity Studio and start a blank application
          1. Make sure at least two nodes are present with EFR32s under Devices.
          2. Go to File -> New -> Silicon Labs AppBuilder Project.
          3. Select Silicon Labs Thread 2.5.0.
          4. Check on "Start with a blank application". Click Next.
          5. Name your project. For example ThreadReed250BRD4162A.
          6. In next window (Project Setup), check if Simplicity Studio detected correct board, part, and toolchain. In this example we're using BRD4162A, EFR32MG12P332F1024GL125, and IAR ARM 7.80.

        II. Configuring REED
          1. Under the "General" tab:
              a. Update the "Device name" to project's name (ie ThreadReed250BRD4162A).
              b. Open "Device type" dialog:
                  i. Select EFR32 and add device to "Selected devices and plugins".
                  ii. Select SoC and add device to "Selected devices and plugins".
                  iii. Select Router and add device to "Selected devices and plugins".
                  iv. Close dialog by clicking OK.
          2. Under the "HAL" tab:
              a. Set Bootloader to Application type.
              b. Set to Use Hardware Configurator.
          3. Open Hardware Configurator
              a. Under DefaultMode Peripherals tab
                  i. Check on GPIO, set SWO pin to PF2
                  ii. Check on Serial, set Port to USART0
                  iii. Check on Virtual COM Port, set enable pin to PA5
          4. Under the "Printing" tab:
              a. Make sure "Enable debug printing" is checked.
              b. Make sure under functional area Core and Application are checked in both "Compiled in" and Enabled at startup".
          5. Under the "ZCL over IP" tab, we do not have anything to add.
          6. Under the "Plugins" tab:
              a. Add CoAP Debug under the Common section. This will give us CoAP debug output in the console.
              b. Add ICMP Debug under the Common section. This will give us ICMP debug output in the console.
              c. Add Serial Plugin (if not already added), and set port to USART0.
          7. Under the "Callbacks" tab:
              a. Select emberFormNetworkReturn - check "Is Used"; Stub should be check automatically.
              b. Select emberJoinNetworkReturn.
              c. Select emberResetNetworkReturn.
              d. Select emberResumeNetworkStateReturn.
          8. Under the "Other" tab, we do not have anything to add.
          9. Click "Generate". Notice project appeared in Project Explorer. Click OK.
          10. Save HWCONF file by going to File -> Save.
          11. Save ISC file.

        III. Add Code and Build Projects
          1. Go to Simplicity IDE perspective. In Project Explorer, expand your Reed project.
          2. Add the following ifdef to enable debug printing.

          #include EMBER_AF_API_DEBUG_PRINT

          3. Add the following code to thread-callbacks.c file. The functions should already be available after generating the project through AppBuilder. This will give us some useful output in the command line.

        void emberFormNetworkReturn(EmberStatus status) {
          boolean success = (status == EMBER_SUCCESS);
          emberAfAppPrintln("Form %s", success ? "complete" : "failed");
        void emberJoinNetworkReturn(EmberStatus status) {
          boolean success = (status == EMBER_SUCCESS);
          emberAfAppPrintln("Join %s", success ? "complete" : "failed");
        void emberResetNetworkStateReturn(EmberStatus status) {
          boolean success = (status == EMBER_SUCCESS);
          emberAfAppPrintln("Reset %s", success ? "success" : "failed");  
        void emberResumeNetworkReturn(EmberStatus status) {
          boolean success = (status == EMBER_SUCCESS);
          emberAfAppPrintln(Resume %s", success ? "success" : "failed");

          4. Compile your project by right-clicking on project name and using "Build project" option.
          5. Make sure your build is successful and the compiled binary is located in project directory tree under "IAR ARM - Default" folder.
        IV. Load Application and Bootloader to EFR32MG module on WSTK
          1. As described in "Building Thread Sample Applications" section 7. Load the Reed application and bootloader to two available devices.

          (To build a specific bootloader check out UG266 and AN1048.)
        V. Adding nodes to a network using pre-commissioning
          1. In Network Analyzer perspective, in the Devices view, right-click on a node and select "Connect" then right-click again and select "Launch Console".
              a. Navigate to "Serial 1" tab and press the return key a few times to get a prompt.
              b. Find out the state of your device using the "Info" command. The output should output network status of 0x00 (EMBER_NO_NETWORK).
              c. If your device has an ip address, reset the network parameters by issuing the command:

        network-management reset

          2. For the first device on the network we will need to form the network
              a. Set the master key issuing command:

        network-management set-master-key {BFBEBDBCBBBAB9B8B7B6B5B4B3B2B1B0}

              b. Set network parameters for the network.         

        network-management form <channel:1> <power:1> <node type:1> [<network id:0--16> [<ula prefix>]


        network-management form 25 3 2 "Honey Badger" "FD00:0DB8::/64"

              c. Check network status using the info command. Network status should be 0x03 (EMBER_JOINED_NETWORK_ATTACHED).

          3. For the second node (or any node after)
              a. In the "Serial 1" console make sure the node is not already in a network.
              b. Set Commissioning information for the device. Note the PAN ID, Extended PAN ID, and Network ID are set by the Leader (our first node on the network). Use the info command on the Leader node to get proper parameters for the network.         

        network-management commission <preferred channel:1> <fallback channel mask:4> <network id:0--16> <ula prefix> <extended pan id:8> <key:16> [<pan id:2> [<key sequence:4>]]


        network-management commission 12 0x0C00 "Honey Badger" "FD00:0DB8::/64" {535F0BBD0DC59B52} {BFBEBDBCBBBAB9B8B7B6B5B4B3B2B1B0} 0x6F29

          4. Join the pre-commissioned device to the network.
              a. Use the following command

        network-management join-commissioned <power:1> <node type:1> [<require connectivity:1>]


        network-management join-commissioned 1 2 0

          5. Check the status of the node by using the info command. Network status should be 0x03 (EMBER_JOINED_NETWORK_ATTACHED).

        VI. Sending Messages
          1. In the Console ping one of the devices in the network, for example ping the Leader's IP address using:    

        icmp ping <destination>


        icmp ping "fd00:db8::d9dd:b493:143b:9cbc"

          2. In the Console send a CoAP POST message     

        coap post <destination> <uri> <body>


        coap post "fd00:db8::d9dd:b493:143b:9cbc" "reed/notice" "1"


      • Communication with external EFR32 based device

        kpszupin | 12/365/2018 | 08:30 PM

        This KBA works with:

        Also checkout the following application note for more information:
        AN958: Debugging and Programming Interfaces for Custom Designs

        To use VCOM_RX and VCOM_TX through the 10-pin Mini Simplicity connector (section 4.1.1 of AN958), make the following edits in your project's ISC (App Builder) and HWCONF (Hardware Configurator):

        1. Switch WSTK to DBG OUT in "Device configuration..." (right-click on node in Devices.)
        2. Set Serial Plugin to USART0.
        3. Set hwConf USART0 to Asynchronous, 115200, No flow Control.
        4. Set hwConf Serial to USART0, set USART0 for serial to TRUE.
        5. Save the HWCONF file and generate the AppBuilder project.
        6. After compiling and flashing the firmware to the BRD4162A, do a hard reset of the WSTK by unplugging it and plugging it in again. This way the board controller is aware of the serial change. Open the Serial Console in Simplicity Studio and hit enter a few times under the Serial 1 tab.

        To use vUART skip steps 2 thru 4 and follow steps from "Setting up vUART with Hardware Configurator".

      • Zigbee 3.0 Prevention of Trust Center Rejoins best practices

        RonB | 12/365/2018 | 03:56 PM

        There is a vulnerability in legacy ZHA networks in which an attacker does a Trust Center Rejoin (one in which the rejoiner doesn’t try to reuse his old NWK key to rejoin and therefore has to get the current NWK key delivered by the Trust Center in order to re-enter), or provokes an existing device into doing this kind of rejoin, and gets the NWK key of the network sent to him encrypted with the well-known ZHA Trust Center Link Key, thus compromising the NWK key and/or allowing rogue devices onto the network.

        Zigbee 3.0 alleviates this problem in a few ways:

        1. All Zigbee 3.0-compliant devices, even those joining with the well-known ZHA key, are expected to request a new Trust Center Link Key upon joining.  
          • Good: This means even a Trust Center Rejoin at a later stage doesn’t compromise the NWK key by reusing some well-known link key.
          • Bad: This only protects your network if all your joining devices and your Trust Center use Zigbee 3.0.
        2. Zigbee 3.0-compliant joining devices are encouraged to use install codes to derive their link keys rather than utilizing a global Trust Center Link Key for obtaining the NWK key during joining.
          • Good: This means even the joining process won’t be using the well-known ZHA key.
          • Bad: Doesn’t solve the problem for legacy devices that didn’t support install codes.  Also, not all pre-Zigbee 3.0 Trust Centers support install codes.
        3. Zigbee 3.0-compliant Trust Centers typically only allow the use of the well-known ZHA link key as a “transient key” (a temporary one that expires after a timeout, is only used for joining [not rejoining], and potentially is limited for use by specific devices [by EUI64]).
          • Good: Unwanted devices can’t accidentally/maliciously join/rejoin with the well-known ZHA key unless the Z3.0 TC specifically opens up that vulnerability during specific points in time.
          • Bad: As long as you have legacy ZHA devices in your system, your TC has to provide some mechanism for joining with the well-known ZHA Key when it’s time to add those devices.  Ideally, the TC would limit this to specific EUIDs, but not all TCs have sophisticated commissioning interfaces capable of inputting the EUI64 for filtering.

        Aside from all this Zigbee 3.0 stuff, legacy Trust Centers (meaning most of the install base of ZHA gateways out there) can still prevent the vulnerability discussed at the beginning of this explanation if they apply a simple patch: Alter your TC rejoining policy so as not to accept TC rejoins that use the well-known link key (or, if you don’t expect/support device-specific link keys, just disable TC rejoins altogether). This is possible through a new Trust Center Policy setting in our stack/NCP firmware, introduced in EmberZNet 5.7.1 and described in the release notes for all 5.7 versions.  The release note refers users to the following KBA for more info:

        KBA: Preventing insecure Trust Center rejoin behavior with EmberZNet Home Automation devices

        On a related note, in EmberZNet 5.7.2 we updated our End Device Support plugin (which manages rejoins for end devices) so that it would no longer even attempt Trust Center rejoins when the TC link key was still the well-known ZHA one, unless users specifically opted in for this potentially vulnerable behavior.  For an end device manufacturer like Spectrum, using the EmberZNet 5.7.2 or later stack should provide the necessary benefits they are seeking.

      • Customizing WSTK settings using the Admin Console

        RonB | 12/365/2018 | 03:16 PM

        It helps to customize your WSTKs to make them easier to identify both on their displays and within Simplicity Studio.  In network environments where you don't want to utilize DHCP it can also help to confingure your WSTKs for static IP addresses.  This KBA will demonstrate the steps for configuring these settings.

        Finding the Admin Console

        The Admin Console can be located in one of two ways:

        1. Within Simplicity Studio you can right click on your WSTK adatper and selecting the Launch Console option from the menu.  Then pick the Admin tab within the console window.
        2. If your device is connected to the network, you can telnet to the IP address of your WSTK on port 4902.

        In both cases you can tell if you are properly connected if you see the WSTK> prompt.


        Setting a WSTK nickname

        When Simplicity Studio sees your WSTK over a network, it will identify your board as No Name. 

        This can be changed in the admin console with the command:

        WSTK> sys nickname WSTK_NAME

        This would change your WSTK to WSTK_NAME. You will need to reboot your WSTK for this to take effect and restart Simplicity Studio for this to be identified.

        Setting your WSTK IP address

        By default the WSTK is configured for DHCP.  Using the admin console, you can setup the WSTK to use a static IP address.  You will need the IP address you are going to assign, the netmask of your network (in most cases this will be 24), the gateway for your network and the address of a DNS server on your network.  With this information you can set the IP address of your WSTK as follows:



        Using these commands, here is an example:

        WSTK> sys nickname ronb-170-9EF
        WSTK> net ip

        This is the result in Simplicity Studio

        More information about the admin console can be found in the following users guide:

        UG151: EFR32MG1 2.4 GHz 19.5 dBm Radio Board User's Guide

      • Correcting an Incomplete Device Menu

        RonB | 12/365/2018 | 01:09 PM

        Occasionally when you are working in Simplicity Studio right clicking on one of your WSTKs will result in an incomplete menu, missing many of your device's normal options. Instead you will see a very small subset of options like so:

        This happens when Simplicity Studio doesn't properly detect the hardware on your WSTK, namely the chip mounted on your radio board. The problem is that Studio won't allow you to program your part or change any of your settings. But this is an easily remedied problem.  To do this first click on Device configuration..., the menu that will appear contains most of the configuration information for your device.  Click on the last tab Device Hardware, you will see this menu:

        In most cases your device hardware will be correctly identified in the top portion of this panel, but the lower portion will not be populated (as in this picture).  In the blank for Boards, enter the same devices as you see in the top portion, you can use the board part numbers for the quickest search (BRD4001A and BRD4151A).  This may populate your Target part as well, but if not you will need to enter the part number identified in the detected information as well. 

        Once you have populated these sections, hit OK and your full device options shoul appear again when you right click on your WSTK.

      • Setting up vUART with Hardware Configurator

        kpszupin | 12/363/2017 | 02:08 PM

        This KBA works with:

        • Simplicity Studio Platform v4.1.14
        • Wireless Tools v4.25
        • Silicon Labs Thread stack v2.5.0
        • EmberZNet stack v6.1.0
        • BRD4162A and the EFR32MG12

        Set Serial Plugin port to VUART.

        In Hardware Configurator check on GPIO and set Serial Wire Output pin to PF2.

        Check on Serial and Virtual UART. Under Serial, set port to VUART and under Virtual UART set the VUART type to SWO.

        Save the HWCONF file and open hal-config.h. The serial API requires a baudrate even though VUART does not, so we will put in a dummy value of 115200 for #define HAL_SERIAL_APP_BAUD_RATE. Then generate the AppBuilder project.

        After compiling and flashing the firmware to the BRD4162A, do a hard reset of the WSTK by unpluging it and pluging it in again. This way the board controller is aware of the serial change. Open the Serial Console in Simplicity Studio and hit enter a few times under the Serial 0 tab.