Background

Zigbee® Green Power (ZGP) is included in the Zigbee 3.0 specification (Z3) (Zigbee Alliance, Zigbee 3.0 specification, https://www.zigbee.org/zigbee-for-developers/greenpower/). It is an end-to-end open standard that allows ultra-low power devices called Green Power Devices (GPDs) to operate on Zigbee networks. The technology requires ultra-low power RF silicon that uses many orders of magnitude less power than required for a Zigbee sleepy or fully-networked wireless connection.

The EFR32xG22 EM2 and EM4 power modes along with the back-up RAM feature make it suitable to implement a periodic or event-based GPD sensor with bidirectional commissioning and secured key exchange.

Description

This KBA demonstrates how to create a Green Power device using an EFR32MG22 and how it interacts with a Z3Light Green Power combo device using the sample applications provided in the EmberZNet SDK. Additionally, we demonstrate a way to disable CLI on both devices and still provision them so that they can work with each other.

Setup

You will need

1. Hardware

   • 2 WSTK main board (BRD4001A)

   • 1 MG22 radio board (BRD4182/83A or another EFR32xG22 board) acts as a Green Power device.

   • 1 MG12 radio board (BRD4161A or any EFR32xG12/13 radio board) acts as a Z3 light and Green Power Combo device.

2. Simplicity studio IDE v4 with the following installed:

   1. Wireless and RF Device Support

   2. EmberZNet SDK version 6.7.1.0 or higher.

 

Usage

1. Generate, build and flash Green Power device project for EFR32MG22.

   1. Launch Simplicity Studio v4 if you haven’t already and go to the Launcher view to start from the home screen.

   2. Click File > New > Project This will launch the New Project Wizard.

   3. Select Silicon Labs AppBuilder Project and press Next >

   4. While this is part of the EmberZNet stack, this is a different application framework. Locate the Green Power Device Framework and select it, click Next >

   5. Select EmberZNet 6.7.2.0 GA Green Power device Framework 6.7.2.0

   6. Select Green Power Device and click Next >

   7. The Project Configuration page will come up, give your project a name. Leave the location as default. Click Next >

   8. Finally, you will arrive at the Project Setup screen. Here we will select the parts and compiler we are using for this project. They are as follows:

      1. Select Board: EFR32MG22 2.4 Ghz Radio Board (BRD4183A or BRD4182A Rev A01) and the part number will be selected automatically

      2. Compiler: You can use gcc or IAR ARM to compile this project, for this exercise we used gcc: GNU Arm v7.2.1.

   9. Click the Finish button and wait for your project to be generated.

   10. At this point you will be at the General tab of your Green Power Device.The device is ready to go by default, so you can click the Generate button to generate all of the files for your application.

   11. Once generated, you will see a Generation validation dialog box. Make sure that you don't overwrite gpd-callbacks.c file as shown in this image. Click OK.

       

   12. A Generation successful message should appear next. Click OK.

   13. Click on your GPD project and build using the hammer icon in the toolbar.

   14. Once built successfully, select and flash the .s37 binary file from your on your EFR32MG22 board by right clicking on the file and selecting Flash to device.

    

2. Generate, build and flash Z3LightGPComboSoc project for EFR32MG12 or other board.

   1. Launch Simplicity Studio v4 if you haven’t already and go to the Launcher view to start from the home screen.

   2. Click File > New > Project This will launch the New Project Wizard.

   3. Select Silicon Labs AppBuilder Project and press Next >

   4. Locate the Silicon Labs Zigbee and select it, click Next >

   5. Select EmberZNet 6.7.2.0 GA SoC or the SoC project of your EmberZNet stack and click Next >

   6. Select Z3LightGPCombo project and click Next.

   7. The Project Configuration page will come up, give your project a name. Leave the location as default. Click Next >

   8. Finally, you will arrive at the Project Setup screen. Here we will select the parts and compiler we are using for this project. They are as follows:

      1. Board: EFR32MG12 2.4 Ghz Radio Board (BRD4161A Rev A02) or your EFR32MG board.

      2. Compiler: You can use gcc or IAR ARM to compile this project, for this exercise we used gcc: GNU Arm v7.2.1.

   9. Click the Finish button and wait for your project to be generated.

   10. At this point you will be at the General tab of your Z3LightGPCombo isc file. Click Generate on the top right corner.

   11. Once generated, you will see a Generation validation dialog box. Click OK.

        

       

        

   12. A Generation successful message should appear next. Click OK.

   13. Click on your GPD project and build using the hammer icon in the toolbar.

   14. Once built successfully, select and flash the .s37 binary file from your on your EFR32MG22 board by right clicking on the file and selecting Flash to device.

3. At this point there are two variation to the pairing process which depend on whether CLI is enabled or disabled on the Zigbee Combo device.

    

CLI enabled on Green Power device and Zigbee Combo device

1. Modifications

   In the green power device software example, CLI is enabled by default. To make it work right, you must increase receive window. You can use CLI for accessing plugins and sending toggle commands. Toggle functionality is enabled by default on the PB1 button in the GP software example. Since CLI and printing is enabled on the Z3Lights by default, we need to account for this when we leave bi-directional communications on the GPD. This is handled via a simple change in the GUI of AppBuilder.

   1. Open the ISC file of your Green Power project.

   2. Click on plugins.

   3. In the top section of the Plugs find GPD App Configuration, you can use the search bar too if you would like. Select it.

   4. You should now see the GPD App Configuration options on the right side of your screen. Look down the list, the 11th item down the list is GPD BiDirectional Rx Window. The value 10 is good for production devices, but too small when you enable CLI/Printing on your light. Increase this value to 100 to allow for proper pairing.

   

   5. If this is the only modification you are looking to make, click on Generate on the top right corner, acknowledge any follow-up boxes. Once generated, compile and flash the .s37 file to your device.

2. Commissioning and Testing

   1. Right click on the board under Debug Adapters and select Launch Console.

   2. This should bring up a new view on the main window that says Serial 0 | Serial 1 | Admin | Debug. Click the spot where it says Serial 1. At this terminal window hit enter a few times, you should be presented 1 or more of such prompts:

      LabZ3Light4166> If you get this, your board is programed successfully with CLI enabled. At this point you must ensure that a network is formed. In the CLI window of Z3Combo device, type info and check the output for such a statement. You can see that the network is up if the nodeID is assigned.

      panID [0x7B8A] nodeID [0xD994] xpan [0x(>)FB780DB2E8C5E776]

      If a network isn't created, form a network using the command in the CLI

      plugin network-creator start 0

   3. On the CLI of the Z3LightCombo enter the following command: plugin green-power-server commission 9 0 0 1 This will open the Light for joining with your GPD. The parameters are:

      • Mode Mask 0x0 Leave, 0x1 Commission, 0x8 Proxies, tells the light to enter commissioning mode by itself and also to Broadcast to all devices telling them to be ready to open and find a GP device.

      • Green Power Manager (GPM) address for security

      • Green Power Manager (GPM) address for pairing

      • Sink endpoint

   4. On the Green Power Device you now will want to find button PB0, it is the button under the screen on the right. You will press this button 4 times, waiting 1+ second between each press, for example:

      1. Press once … wait 1+ second

      2. Press twice … wait 1+ second

      3. Press a third time … wait 1+ second

      4. Press a fourth time … done

         Each of these button presses are the following steps: Press 1 – Channel request: To find the channel of the Zigbee network and use use that for commissioning requests Press 2 – Commissioning command: Commissioning request Press 3 – Commissioning command: To collect the commissioning reply Press 4 – Commissioning command: To indicate the successful commissioning

   5. On the CLI of Zigbee Combo device, look for an output that looks like the following:

      GP CN : Saving the GPD Calling Adding TT and Sink gpdCommandClusterEpMap[0].gpdCommand = 32 gpdCommandClusterEpMap[0].endpoints[0] = 1 gpdCommandClusterEpMap[1].gpdCommand = 33 gpdCommandClusterEpMap[1].endpoints[0] = 1 gpdCommandClusterEpMap[2].gpdCommand = 34 gpdCommandClusterEpMap[2].endpoints[0] = 1 SinkCommissioningModeCallback(Exit) send returned 0

      .

      .

      .

      Device Announce: 0x5678

      What you really want to see is the device announce. This output means that your GPD has paired and your Light has made entries for it in its tables. You can test this by pressing PB1, it should make your light toggle on and off. If you do not see this or PB1 does not flash your lights, try pressing the reset button on the Zigbee combo device. If you still don't get it, re-run the steps in this section and try again.

CLI disabled on Green Power device and Zigbee Combo device

1. Modifications

   1. Go to CLI tab in the ISC file of both the Green power and Zigbee combo device project and uncheck the "Enable command line interface" option.

   2. If this is the only modification you are looking to make, click on Generate on the top right corner, acknowledge any follow-up boxes. Once generated, compile and flash the .s37 file to your device.

2. Commissioning and Testing

   1. Without the CLI, the commissioning process needs to be started through callbacks in the Zigbee Combo device project once the network is up. The callbacks are located in <Your Project name>_callbacks.c file for example Z3LightGPComboSoc_callbacks.c.

   2. The function you are looking for is called void emberAfPluginNetworkSteeringCompleteCallback. Insert the following line in the end of the function. This function call does the same thing as executing the command plugin green-power-server commission 9 0 0 1 from CLI.

      emberAfPluginGreenPowerServerCommissioningMode(9,0,0,1); where the parameters are

      • <uint8_t> Mode Mask 0x0 Leave, 0x1 Commission, 0x8 Proxies tells the light to enter commissioning mode by itself and also to Broadcast to all devices telling them to be ready to open and find a GP device.

      • <uint16_t> Green Power Manager (GPM) address for security

      • <uint16_t> Green Power Manager (GPM) address for pairing

      • <uint8_t> Sink endpoint

   void emberAfPluginNetworkSteeringCompleteCallback(EmberStatus status,
                                                       uint8_t totalBeacons,
                                                       uint8_t joinAttempts,
                                                       uint8_t finalState)
     {
       emberAfCorePrintln("%p network %p: 0x%X", "Join", "complete", status);
     
       if (status != EMBER_SUCCESS) {
         // Initialize our ZLL security now so that we are ready to be a touchlink
         // target at any point.
         status = emberAfZllSetInitialSecurityState();
         if (status != EMBER_SUCCESS) {
           emberAfCorePrintln("Error: cannot initialize ZLL security: 0x%X", status);
         }
     
         status = emberAfPluginNetworkCreatorStart(false); // distributed
         emberAfCorePrintln("%p network %p: 0x%X", "Form", "start", status);
         emberAfPluginGreenPowerServerCommissioningMode(9,0,0,1);
       }
     }

   3. Compile and flash to your board. Upon start, the Zigbee Combo device will form a network and open the Light device for joining with your GPD.

   4. On the Green Power Device you now will want to find button PB0, it is the button under the screen on the right. You will press this button 4 times, waiting 1+ second between each press, for example:

      1. Press once … wait 1+ second

      2. Press twice … wait 1+ second

      3. Press a third time … wait 1+ second

      4. Press a fourth time … done

         Each of these button presses are the following steps: Press 1 – Channel request: To find the channel of the Zigbee network and use use that for commissioning requests Press 2 – Commissioning command: Commissioning request Press 3 – Commissioning command: To collect the commissioning reply Press 4 – Commissioning command: To indicate the successful commissioning

   5. Since we don't have CLI, the only way to find out if this process is successful is by pressing PB1 on the GP device to see if the light on the Combo device toggles.

Question

Why does xIDE claim it can't find my license file?

Answer

If xIDE refuses to start the IDE and instead reports an error dialog explaining that it was unable to locate your license file, this is usually a sign that either your license is not in the correct folder or has expired. As far as troubleshooting the first of these two causes:

• The expected location for the license file is in the 'licence' (note the British spelling) subdirectory of the folder where 'xIDE for EM250' was installed. By default, this installation is rooted at Program Files/Ember/xIDE_EM250, but you may have changed it to a custom location during installation.
   
• Note that the license filename must retain its *.LIC extension. (Do not rename as TXT file for example.)
   
• If you have installed multiple xIDE versions (for maintenance on multiple code branches), it may not be obvious where to place the license. In this case, xIDE will examine each of the paths in the semicolon-separated list described by the value for CAMCON_LICENSE_FILE within the Windows Registry Key called 'HKEY_LOCAL_MACHINE/SOFTWARE/FLEXlm License Manager'. If any of these paths contain a valid license, the first one detected will be used. Use the regedit.exe utility to open and edit the Windows Registry as needed to confirm/modify this value.

In regards to license expiration:

• Ember’s sublicensing agreement from OEM Cambridge Consultants Ltd (CCL) for xIDE For EM250 only permits a maximum duration of 12 months per license. However, Ember customers can continue their development after the first year by requesting license renewals through Ember Support. These renewals are offered free of charge, provided the customer is still in good standing as an active developer/maintainer of EM2xx-based products.
   
• Your xIDE installation will begin alerting you about license expiration when the current date is within 3-4 weeks of the expiration date. To avoid any potential delays in receiving an updated license from Ember Support, please try to arrange license renewal requests a few days in advance and remember to include your xIDE Host ID in the renewal request.

Note that license renewal requests should come through a support ticket at https://www.silabs.com/support.

If you are still well within the above guidelines and your license still is not detected properly by xIDE, the cause is likely to be one of the following:

• Your Host ID may have changed (ie. the network adapter to which the license is locked is no longer available, in which case you'd need to provide the host ID displayed in the resulting dialogs when you choose 'No, I need a license' from the xIDE error dialogs that come up when it fails to find the license).
   
• You're trying to access the target machine via Windows Remote Desktop (Microsoft Terminal Services Client), which is not allowed by the licensing module used in xIDE. If this is your problem, you'll need to find another way to access the machine, either through some kind of remote login / telnet program by which you could execute the xipbuild.exe program to kick off a build from the command line, or via another remote GUI connection method like VNC (see realvnc.com).

If you’re still uncertain about why the license may not be working after applying the advice in this article, you can add a Windows User Environment Variable (in Control Panel… System… Advanced… Environment Variables) called 'FLEXLM_DIAGNOSTICS' and set its value to 3. If you do this and run xIDE for EM250 again, several warning/error dialogs will be displayed by the licensing module, allowing you to obtain diagnostic information about why the IDE is failing to launch. Ember Support can then assist you with follow-up actions.

If your Host ID starts with 00 FF then there is a good chance you are running VPN software on your host. This will cause your MAC address to change every time you reboot. In order to get the correct Host ID for your computer to use is to disable the VPN software.

Zigbee® Green Power (ZGP) is included in the Zigbee 3.0 specification (Z3) (Zigbee Alliance, Zigbee 3.0 specification, https://www.zigbee.org/zigbee-for-developers/greenpower/). It is an end-to-end open standard that allows ultra-low power devices called Green Power Devices (GPDs) to operate on Zigbee networks. The technology requires ultra-low power RF silicon that uses many orders of magnitude less power than required for a Zigbee sleepy or fully-networked wireless connection.

The EFR32xG22 EM2 and EM4 power modes along with the back-up RAM feature make it suitable to implement a periodic or event-based GPD sensor with bidirectional commissioning and secured key exchange.

GPD Communication

There are two types of communication modes based on energy budget:

- Unidirectional: the device only transmits information to the Zigbee network

- Bidirectional: the device transmits and then receives information back, such as security material.

The bidirectional mode implementation uses EM2 power mode and the low energy sleep timer as a wake-up source between transmit and receive.

Commissioning and Security

The hardware acceleration in EFR32xG22 makes it possible to implement a GPD with the highest level of security (encryption and message integrity with application key exchange) during bidirectional commissioning.

Storage of Security Material

In a battery-backed GPD implementation, the back-up RAM can hold the security material during EM4 sleep.

More Information

The user guides on Green Power fundamentals and information about using the Silicon Labs Green Power framework can be found here:

https://www.silabs.com/documents/public/user-guides/ug103-15-green-power-fundamentals.pdf

https://www.silabs.com/documents/public/user-guides/ug392-using-sl-green-power-with-ezp.pdf

Silicon Labs took the decision to deprecate its proprietary implementation of Thread and instead be a major contributor to the more popular OpenThread implementation.

 

The announcement was made as part of the release notes for Silicon Labs Thread (SL-Thread) SDK  v2.10.1.0 which can be found here:
https://www.silabs.com/documents/public/release-notes/thread-release-notes-2.10.1.pdf

 

The notice indicates that the inclusion of the SL-Thread implementation will be removed from the Simplicity Studio release scheduled in December 2019.

 

The notice re-iterates that Silicon Labs has a continued focus on its Thread strategy and is committed to continuing as a leading-edge Thread supplier. Support for Thread will continue within the Silicon Labs software and hardware tools but the stack availability itself will be distributed through the commonly accessible OpenThread GitHub repository.

 

More information on the OpenThread implementation can be found at: https://openthread.io/platforms/efr32

 

 

In EmberZNet version 6.6, Silicon Labs has made changes to the underlying framework so that it uses the same user interface and metadata used by all of Silicon Labs’ other stacks including the xNCP, Silicon Labs Thread, and Flex. This change results in a slightly different user interface for the EmberZNet 6.6 stack in Simplicity Studio. The most noticeable change is that projects are no longer generated into the <stack>/app/builder directory. Instead projects are generated by default into the user’s workspace directory. What follows is a comprehensive guide to both the UI changes for the EmberZNet 6.6 stack in Simplicity Studio as well as a migration guide for moving a pre-6.6 project using Application Framework V2 to one using the Zigbee Application Framework in EmberZNet 6.6.

 

Creating an Application from Scratch

The first thing you will notice when creating an application in SDK version 6.6 is that the application framework is no longer called “ZCL Application Framework V2”, but rather “Silicon Labs Zigbee”.

Other than this minor change to the location of projects and naming of the application framework, the creation of an application is unchanged.

 

User Interface Changes

The AppBuilder interface is still broken up into Tabs, however the contents and names of some of the tabs have changed slightly. The ZCl global tab has been removed and its contents moved to the ZCL Clusters tabs or removed. All changes are detailed below.

Pre EmberZNet 6.6 Stack Tabs

Post EmberZNet 6.6 Stack Tabs

The General Tab

1. The generation directory has moved out of the stack and away from the “app/builder” directory and into the user’s workspace by default:

2. There is no longer an option to “Automatically generate when file is saved”.

3. Multi-network configuration widget has moved to the Zigbee stack tab.

ZCL Global Tab

1. The ZCL Global tab has been removed.

2. The Manufacturer Code and Default Response Policy options have moved into the ZCL Clusters tab.

3. Specification versions pulldowns that were related to previous ZCL “Profiles” have been removed. Applications are always built against the latest Zigbee 3 ZCL cluster definition located in the stack’s app/zcl directory.

ZCL Clusters Tab

1. Includes the Manufacturer Code and Default Response Policy from the ZCL Global Tab.

ZNet Stack Tab

1. The ZNet Stack tab has been renamed to the Zigbee Stack Tab.

2. Multi-network configuration has moved into the Zigbee Stack Tab from the General Tab.

3. “Interpan settings” has been removed.

4. The “Custom ZCL Additions” widget has been added. Custom ZCL .xml files used to be loaded into Simplicity Studio preferences and were applied to all projects. We have moved the interface into the project itself so that custom ZCL .xml files and additions are added on a project by project basis.

 

Prior to EmberZNet 6.6, ZCL .xml additions were added into the Simplicity Studio Preferences and thus affected all projects created for a given stack version as shown below. This is no longer an option for EmberZNet 6.6 and higher.

 

Printing and CLI Tab

1. The Debug printing checkbox has moved into the “Debug Configuration” widget.

2. “Cluster debugging” has been renamed to the more generic “Application Specific debug printing”. All of the clusters are still listed in this section.

3. Individual plugin debug printing has been added.

4. The “CLI Options” widget has been renamed to “CLI”.

Hal Configuration Tab

1. This tab has been renamed to “HAL”.

2. The “IO Configuration” widget has been renamed to “Serial Configuration”. The Command Line Interface pulldown has been moved to an App Framework Core plugin option.

3. The “Board Header” widget has been renamed to “Board Header Configuration”.

4. The “Manage integration…” widget has been renamed to ”Hardware Configurator Interface”.

5. The “Multi Protocol Stack Interface” widget has been renamed to “MPSI Configuration” with the acronym spelled out below.

Plugins Tab

The ability to expand the table, collapse the table, and show only selected plugins does not exist yet in the EmberZNet 6.6 interface.

Callbacks Tab

This tab is unchanged.

Includes Tab

The “Custom Events” widget is now renamed to “Event Configuration”.

Other Options Tab

This tab is unchanged.

Bluetooth GATT Tab

This tab is unchanged.

 

ISC File Changes

1. Many of the key value pairs located in the pre-EmberZNet 6.6 stacks have been moved into “setup” configurations in the new .isc file format.

2. Pre-EmberZNet 6.6 .isc files are automatically upgraded to the new Zigbee Application Framework format when they are opened against an EmberZNet 6.6 stack.

 

Migrating a Pre-EmberZNet 6.6 Application Over to EmberZNet 6.6.

Applications created with earlier versions of EmberZNet can be moved into the user’s workspace directory and migrated over to EmberZNet 6.6. The following is a step by step instruction on the migration process, starting with the creation of a pre-EmberZNet 6.6 application and resulting in an upgraded application. This process works for both SoC and Host applications.

1. In the SDK preferences navigate to and open your Pre-EmberZNet 6.6 stack. In this example I will use the EmberZNet 6.5 stack, part of Gecko SDK Suite 2.5.3.

2. Right click and close all open projects in the workspace. Now, create a new project using the earlier stack. In this case I’ll create an EmberZNet 6.5 Z3LightSoc.

3. Generate and compile the project. This will generate code into your <GSDK>/app/builder directory.

4. Right click and close all open projects in the workspace. Not doing so will re-enable the older stack versions upon restarting studio. In the Simplicity Studio V4 preferences disable earlier stack and enable EmberZNet 6.6.

5. Since you have generated and compiled against an earlier stack you should close Simplicity Studio in order to clear out any Hardware Configurator cached data. Hardware configurator data is cached in Simplicity Studio by default in order to speed up generation. Alternatively caching can be turned off in Simplicity Studio preferences.

6. In your user workspace directory create a directory called “<project name>_temp”. This is a temporary directory that you can copy your important project files into before they are imported into Simplicity Studio. For example, my user workspace is located at “/Users/<username>/SimplicityStudio/v4_workspace/.” My project is called Z3LightSoc so I created a directory at “/Users/<username>/SimplicityStudio/v4_workspace/Z3LightSoc_temp”

7. Copy your project’s .isc, .hwconf and callbacks.c files from the <GSDK>/app/builder/<projectname> directory into this temporary directory inside your workspace.

8. Start Simplicity Studio V4.

9. In Simplicity Studio V4 go to File > Import… and browse to the temporary directory that you have created containing your copied files.

• You should have the option of importing the project as an “External Project Type”.

10. Import the project. Be sure to set the stack to your EmberZNet 6.6 stack. The project name should default to the original name of the project, in my case Z3LightSoc.

11. You should see the project inside the Simplicity Studio IDE.

12. Double click on the .isc file in the Simplicity Studio to open the project in AppBuilder.

13. Change the generation directory from the old <GSDK>/app/builder directory to your project directory inside your workspace. In my case this is /Users/<username>/SimplicityStudio/v4_workspace/Z3LightSoc

14. Be sure to change the path to any “Included” files in your project by modifying the “Other Options Tab” as necessary.

15. Generate your application.

16. As a final step you should copy the files out of your <projectname>_temp directory into your actual project directory by right-clicking on the files in Simplicity Studio and choosing “Copy Linked Files into Project”.

17. Compile your application.

This is a guide is for creating, building, and running a Dotdot OTA Server and Client using available sample applications. The OTA Server will be on a Host application on the Raspberry Pi that has an NCP connected. This KBA assumes that the user has reviewed UG116 and is familiar with running a Raspberry Pi Host with NCP. (Please note, it is not a requirement for the OTA Server to also be a Border Router).

This KBA was written with the following software tools:

• Simplicity Studio
• Gecko SDK version 2.5
• IAR Workbench 7.80.4
• GCC 6.3.0

With the following recommended hardware:

• Raspberry Pi 2 Model B
• Two BRD4164s or equivalent EFR32MG12 reference boards with WSTKs

 

Sample Applications

Create projects for the following sample applications found in Gecko SDK version 2.5 through the Application Wizard. These can be found through the File menu going to File -> New -> Project -> Silicon Labs AppBuilder Project.

• OTA Server (Host)
• Light (Soc)
• NCP UART HW (Hardware Flow Control)
• SPI Flash Storage Bootloader (single image)

The Light and OTA Server are pre-commissioned and will be in the same network at startup,  unless the devices were already in a previous network. Resetting the network parameters will coax the devices to enter the networking state-machine. The reset command is as follows:

ota-server> network-management reset

 

OTA Server Configuration

The OTA Server (Host) Sample application has all the plugins required to be an OTA Server. Most notable are the following:

• OTA Bootload Core
• OTA Bootload Server
• OTA Bootload Server Policy
• OTA Bootload Storage CLI
• OTA Bootload Storage Core
• OTA Bootload Storage UNIX

In OTA Server Sample app we recommend making the following changes for testing: 

• Under the Printing tab enable the following debug output
  • ICMP CLI
  • OTA Bootload Core
  • OTA Bootload Server
  • OTA Bootload Storage UNIX
  • OTA Bootload Storage Core
  • OTA Bootload Server Policy
• In OTA Bootload Server Plugin
  • Change the Image Notify Period to 1 minute

Generate, transfer to Raspberry Pi, Compile the OTA server application. Also, compile ip-driver-app found under v2.x/protocol/thread/ with the following command:

$> make -f app/ip-ncp/ip-driver-app.mak

 

Light OTA Client Configuration

The OTA Client is based on the Light sample app. The following plugins are used to enable the OTA functionality. Here we assume the device you are using has external EEPROM:

•  OTA Bootload Client
•  OTA Bootload Client Policy
•  OTA Bootload Core
•  OTA Bootload Storage CLI
•  OTA Bootload Storage Core
•  OTA Bootload Storage EEPROM

In the OTA Bootload Client options set the following to maximize the recurrence of OTA Client/Server communication:

• Discover Server Period to 1 minute
• Query Next Image Period to 1 minute 

In the OTA Bootload Client Policy options note the following and/or set them to something unique. These will be used for creating the OTA image:

• Current Image Manufacturer Code
• Current Image Type
• Current Image Version 

In the OTA Bootload Storage EEPROM plugin make sure the value of EEPROM OTA Storage End Address is one less than the value found in SPI Flash Storage Bootloader Slot 0 size (under the Storage tab). If the size does not match the download will fail.  

We also recommend enabling the following plugins for testing:

• ICMP CLI
• COAP CLI
• UDP CLI

As well as the following for debug output under the Printing tab:

• EEPROM
• OTA Bootload Storage EEPROM
• OTA Bootload Client Policy
• OTA Bootload Core
• NVM3 Library
• ZCL Core
• OTA Bootload Client

Generate, Build, and Flash the Light application and bootloader to the EFR32. 

 

Building OTA Image

Recall the values in OTA Bootload Client Policy plugin for the Light. In order for the Light application to flash an image it must verify if the image has met the criteria of the OTA policy. The Manufacturer ID, Image Type ID need to be the same, and the Firmware Version must be a higher value. We will need to create a second image with a higher version number. For example, the first image will be version 0x00000001 and the new image will have version 0x00000002. Go back to AppBuilder and update the project to have a higher version number by changing the setting, generating, and compiling. (Note: this will overwrite your old image. If it needs to be available store it in a different place or rename the GBL file.)

The Image Builder tool will wrap the GBL file in an OTA file. The tool can be found under the SDK directory tree ../gecko_sdk_suite/v2.5/protocol/thread/tool/image-builder/. The following command can be called in a terminal:

$> ./image-builder-linux -c 1234-5678-00000002-light.ota -m 0x1234 -i 0x5678 -v 0x00000002 -s 4 -t 0  --security-credentials=3 -f "light292BRD4163A_02.gbl"

• -c : The OTA file to create
• -m : Manufacturer ID found in OTA Bootload Client Policy
• -i : Image type ID found in OTA Bootload Client Policy
• -v : Firmware version found in OTA Bootload Client Policy
• -s : ZCL Stack version
• -t : Tag Identifier
• --security-credentials : The security credentials required for this upgrade.
• -f : The file to be included in the OTA

More information can be found in  AN716: Instructions for Using Image-Builder

 

Kicking off OTA upgrade

Copy the OTA image to the same directory where the Server Host application is called. Start the ip-driver-app followed by the ota-server.

$> sudo ./ip-driver-app -u /dev/ACM1 -t tun0 -m 4901 &
$> sudo ./ota-server -m 4901

In ota-server call the following command to see if it has found the OTA image.

ota-server> ota-bootload-storage info

The output should be similar to the lines below:

ota-server: 
1234-5678-00000002-light.ota: m=0x4X t=0x4X v=0x8X
ota-server.nvm: 
Load files found 1 files
OTA Bootload Storage Info: maximumFileSize = 1000000, fileCount = 1
File 0: m=0x1234 t=0x5678 v=0x00000002 size = 311919

On the Light side open the console and check the network parameters using the info command and make sure it is on the same network as the OTA Server. The results should be similar to the lines below:

light_01> info
network status: 0x03
eui64: >000B57FFFE25FAFC
macExtendedId: >776A3C93A3776E86
network id: precommissioned
node type: 0x02
extended pan id: >4F8EC75FB4E1EFC6
pan id: 0x1075
channel: 19
radio tx power: 3 dBm
ula prefix: fd01::/64
mesh-local: fd01::1f0e:750c:b36:7ce5
link-local: fe80::756a:3c93:a377:6e86

To kickoff the search for an OTA Server use the following command:

light_01> ota-bootload-client update

The following lines should output to console:

Sent discovery command: .well-known/core?rt=urn:zcl:c.2000.s&
get 0x00
Using upgrade server discovery
Discovered server: fd01::63e6:a84:377c:3305->5683

If the server is discovered then the OTA transfer will start in ~1 minute (as we configured in OTA Bootload Client plugin).

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

The latest installations of Simplicity Studio should also include the latest ISA3 Utilities in the subfolder:
 ~/developer/adapter_packs/em3xx/utils

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

UG107: ISA3 Utilites

Additional resources for the ISA3 as well as the EM35x dev kits are:

TS6: EM35xx Breakout Board Technical Specification

TS7: ISA3 Technical Specifications

UG110:  EM35x Development Kit User Guide (this guide has some example ISA3 setup routines in section 6 and 7)

AN717: Programming Options for the EMber EM35x Platform

If you are having the issue mentioned in the title after an update to EmberZnet 6.5.0.0 please consider updating to the Gecko Bootloader. If it is not an option for you the following is an explanation on why this problem occurs followed by a proposed solution. 

Although support of Ember Standalone Bootloader for EFR32 based products has ended in 2017. There could still be some devices in the field that were initially manufactured with the Ember Standalone Bootloader and are now unable to upgrade to the Gecko Bootloader. 

Since the 2.5 GSDK release modules are regarded as first class citizens and while the Gecko bootloader has been upgraded to facilitate this update the Ember Bootloader was not because it is no longer being developed. 

This update causes the AAT header in .ebl files built during the post-build process in Simplicity Studio to be interpreted as corrupt by the Ember Standalone Bootloader.

The problem is that the value of byte 0x78 used to be 0x10 for EFR32MG1P or 0x11 EFR32MG1B and after the update it is set to 0x01 for MGM111. 

If this is the issue the advised solution is to convert the created .s37 file to .ebl using the 'em3xx_convert' tool.
This should be located at "(StudioFolder)\developer\adapter_packs\em3xx\utils"

Open any command line tool at this location and you can convert a .s37 to .ebl with the correct AAT header using the following command. 

 "em3xx_convert.exe --chip EFR32 (path)/(filename).s37 (path)/(filename).ebl"

 

 

If your existing Host-NCP solution is lacking Green Power proxy support and you want to add it to the design these steps will walk you through the process of adding it.

Adding host support

First, go to the ZCL Clusters tab and find the Multiple endpoint configuration section at the top. Click the New button to add an endpoint to your device, this will create a second endpoint on the device with identifier 2. Now we need to convert this to a green power endpoint.

In the Configuration column, click the Primary name, which will bring up a button with 3 dots

Click the box to bring up the Endpoint type window

Select the option Create new endpoint type and name your new endpoint Green Power. Click OK.

Keeping the endpoint selected, go to the pull-down menu for ZCL Device Type and change the device to GP Proxy Basic (under GP devices). When this is selected, this will make the endpoint change to number 242. This should also enable Cluster 0x0021, the Green Power cluster, on the device.

Now go to the Plugins tab and on the search bar, enter Green – this will find 4 plugins in the Green Power section:

Check the box next to the Green Power Client and Green Power Common plugins, this will enable them. There isn't any need to change any of the default settings within the plugins, so you can leave those alone. 

At this point you should be able to generate and build your host application with no issue and Green Power will be supported. However support for green power needs to be enabled within the NCP.

Adding NCP support

As you are configuring your  NCP application, go to the plugins tab and enable the Green Power Stack Library plugin. Make sure the Green Power Stack Stub Library is disabled:

Since this is just a proxy, you can leave the settings as defaulted, proxy table size of 5 and sink table size of 0. However you will need to consider your potential network when configuring your table sizes. A larger proxy table might be needed for supporting all devices on the network.

This is all you need for NCP support. You can generate and build your NCP and combined with your new host code, green power proxy support should be ready to go.

What is the maximum allowed power for ZigBee applications under ETSI EN 300 328?

Although ETSI EN 300 328 allows 20dBm RF output power, there is a limitation for PSD (Power Spectral Density) for wide band modulations other than FHSS. This PSD limit restricts the maximum allowed power for ZigBee applications.

Section 5.4.3.2 in EN 300 328 V2.1.1 details the test method for PSD. The ZigBee modulated signal measured according to Option 2, Step 3 (with sweep time set to 10s):

CW signal with the same power level and spectrum analyzer settings:

The peak power difference between the ZigBee and CW signal measured with RMS detector is ~2.3dB. In order to meet the PSD limit of 10dBm per MHz, the maximum allowed power is 12.3dBm (EIRP).

Note: The 12.3dBm power limit is radiated (EIRP), which means that in case of an antenna with 0dBi, the maximum conducted power allowed is 12.3dBm. For antennas with lower gain than 0dBi, conducted power can be increased, while for antennas with higher gain than 0dBi, conducted power should be reduced.

Measurements were performed on an EFR32MG13 based reference board (BRD4158A Rev A01).