Developer Documentation

Develop and prototype smarter. Get to market faster.

Filter

Application Examples

Version 1.0.0

Bluetooth

Version 5.0

Bluetooth Xpress

Version 1.0

Connect

Version 3.5

Gecko Bootloader

Version 2.1

Gecko Platform

Version 4.2

Machine Learning

Version 1.2

Matter

Version 1.0.5

Micrium

Version 5.11.0

RAIL

Version 2.14

Simplicity Studio

Version 5.6.3

Thread

Version 2.2

USB

Version 1.0

Wi-Fi

Version 1.0

Wi-Fi Xpress

Version 1.0

Wi-SUN

Version 1.5

Z-Wave

Version 1.0.1

Zigbee

Version 7.2.2

Resources

Technical LibraryTechnical Resource Search

TrainingInformation, tutorials, and training

CommunityA universe of solutions to explore

SupportPowerful suite of testing tools


You are viewing documentation for version: 5.0 | This version works with Simplicity Studio 5 only. If you have Simplicity Studio 4, switch to 2.13. | For additional versions, see Version History.

General Overview

Silicon Labs Bluetooth LE Documentation | Release Notes | Downloads

About the Bluetooth Stack

The v4.x Silicon Labs Bluetooth stack is an advanced Bluetooth 5-compliant protocol stack implementing the Bluetooth low energy standard. It supports multiple connections, concurrent central, peripheral, broadcaster, and observer roles. The v3.x Silicon Labs Bluetooth stack is meant for Silicon Labs EFR32 SoCs and modules.

The Silicon Labs Bluetooth stack provides multiple APIs for the developer to access the Bluetooth functionality. Three modes are supported:

Standalone mode, where both the Bluetooth stack and the application run in an EFR32SoC or module. The application can be developed with C programming language.

Standlone Mode

Network Co-Processor (NCP) mode, where the Bluetooth stack runs in an EFR32 and the application runs on a separate host MCU. For this use case, the Bluetooth stack can be configured into NCP mode where the API is exposed over a serial inter- face such as UART.

NCP Mode

Radio Co-Processor (RCP) mode, where only the Link Layer of the Bluetooth stack runs on the EFR32, and the Host Layer of the stack, as well as the application, runs on a separate host MCU or PC. In this use case, the Host Layer is developed by a third party, since Silicon Labs’ Bluetooth stack is only built for EFR32 SoCs / modules. The Link Layer and the host layer communicate via HCI (Host-Controller Interface), which is a standard interface between the two layers. The HCI can be accessed via UART following the Bluetooth SIG's UART (H4) transport protocol.RCP Mode

Bluetooth Stack Features


Bluetooth Stack Features

The features of the Silicon Labs Bluetooth stack are listed in the following table.

Stack Features

Bluetooth Qualification

All products deploying Bluetooth technology must go through the Bluetooth SIG's Qualification Process. Online resources will help you learn more about the  Bluetooth Qualification , process, and tutorials on the  Launch Studio , which is the online tool used to complete the Bluetooth Qualification Process. For assistance to qualify your device, consider reaching out to your nearest  Bluetooth Qualification Consultant .

When qualifying your end-product based on Silicon Labs’ Bluetooth stack, integrate the pre-qualified components. To learn more and see the list of pre-qualified components, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

The Bluetooth Stack APIs

This section briefly describes the different software APIs.

The Bluetooth API

The Bluetooth API provided by the Silicon Labs Bluetooth stack is the primary API to communicate with the stack. It provides access to all the Bluetooth functionality implemented by the Bluetooth stack, such as the Generic Access Profile (GAP), connection manager, the security manager (SM), GATT client and server.

In addition to the Bluetooth features, the Bluetooth API also provides access to a few other functions such as the Direct Test Mode (DTM) API for RF testing purposes, the Persistent Store (PS) API for reading and writing keys to and from the devices flash memory, the DFU (Device Firmware Update) API for field firmware updates, and the System API for various system level functions.

The BGAPI Serial Protocol and the Bluetooth Host API

When configured in NCP (network co-processor) mode, the Bluetooth stack can be controlled using the BGAPI serial protocol. This allows the Bluetooth stack to be controlled over a serial interface such as UART from a separate host, such as EFM32 microcontroller. The BGAPI serial protocol provides exactly the same Bluetooth APIs over UART as the BGAPI API when used in a standalone mode.


The BGAPI serial protocol is a lightweight, binary protocol that carries the BGAPI commands from the host to the Bluetooth stack, and carries responses and events from the Bluetooth stack back to the host.

The Bluetooth SDK delivers a ready-made BGAPI serial protocol parser implementation both for the NCP target (EFR) and for the NCP host. It implements the serial protocol parser for all APIs provided by the Bluetooth stack. The host code developed on top of host API can be written to be identical to the code for the EFR, which allows easy porting of the application code from the EFR to a separate host or vice versa.

BGAPI

The BGAPI serial protocol packet structure is described below. For more information, see the BGAPI Headers.

BGAPI Table

The Bluetooth Profile Toolkit GATT Builder

The Bluetooth Profile Toolkit is an XML-based API and description language used to describe the GATT-based service and characteristic easily without writing code. The XML files can be easily written by hand based on the information contained in UG118: Blue Gecko Bluetooth® Profile Toolkit Developer Guide. Use the Profile Toolkit GATT Builder if you are developing outside of Simplicity Studio.

Within Simplicity Studio, the GATT Configurator allows building the GATT in a visual way without hand editing the XML file. See UG438: GATT Configurator User’s Guide for Bluetooth SDK v3.x for details. Open the GATT Configurator in Simplicity Studio through the Project Configurator, Software Components tab, under Advanced Configurators. Click Open and the GATT Configurator tool opens the file gatt_configuration.btconf in a new tab.

Opening Bluetooth GATT Configurator


Opening Bluetooth GATT Configurator

gatt_configuration.btconf provides the trunk of the GATT database. It is located inside the config > btconfig directory of your project. You can add additional XML files in the same directory and extend the GATT database. The contents of the additional XML files will appear as Contributed Items in the GATT Configurator UI. For examples, see the ota-dfu.xml file provided with most sample applications.

The GATT database developed with the Profile Toolkit is converted to a .c file and a .h file and included in the application project as a pre-build step when the firmware is compiled. Then, the GATT can be accessed with the Bluetooth stack GATT APIs or by a remote Bluetooth device.

GATT XML

CMSIS and EMLIB

The Cortex Microcontroller Software Interface Standard (CMSIS) is a common coding standard for all ARM Cortex devices. The CMSIS library provided by Silicon Labs contains header files, defines (for peripherals, registers and bitfields), and startup files for all devices. In addition, CMSIS includes functions that are common to all Cortex devices, such as interrupt handling, intrinsic functions, and so on. Although you can write to registers using hard-coded address and data values, it is recommended to use the defines to ensure portability and readability of the code.

To simplify programming Wireless Geckos, Silicon Labs develops and maintains a complete C function library called EMLIB that provides efficient, clear, and robust access to and control of all peripherals and core functions in the device. This library is within the em_xxx.c (for example, em_dac.c) and em_xxx.h files in the SDK. The EMLIB documentation is available in the Gecko Platform documentation.

About the Bluetooth SDK


About the Bluetooth SDK

The Bluetooth SDK is a full software development kit that enables you to develop applications on top of the Bluetooth stack using C programming language. The SDK also supports making standalone applications, where the Bluetooth stack and the application both run in the Wireless Gecko, or the network co-processor (NCP) architecture, where the application runs on an external host and the Bluetooth stack runs in the Wireless Gecko. SDK contents and folder structure are described in QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

About Demos and Examples

Starting application development from scratch can be difficult. For that reason, the Bluetooth SDK comes with a number of built-in demos and examples covering the most frequent use cases, as shown in the following figure. Demos are pre-built application images that you can run immediately. Software examples can be modified before building the application image. Demos with the same name as software examples are built from their respective example.

Note: The demos and examples you see are determined by the part selected. If you are using a custom solution with more than one part, click on the part you are working with to see only the items applicable to that part.

Demos and Software Example are in the Example Projects & Demos tab in the launcher view of Simplicity Studio.

To download and run a demo on your device, click RUN on the right demo you want to run on your target.

To import software example code into your workspace as a new project using default project configurations, click CREATE on the name of the desired example project and a New Project Wizard window will open. Click FINISH and your project will open in Simplicity IDE mode where you can customize it.


If an example project closely matches your needs, extend the code with your application code and rewrite the custom sections. Otherwise, start with the SoC-Empty application. Note that the SoC-Empty application is not blank, but rather provides a minimal project that only starts advertising.

Studio Launcher

Demo/Example Descriptions

The following examples are provided. Examples with (*) in their names have a matching pre-built demo.

Silicon Labs Gecko Bootloader examples (see UG266: Silicon Labs Gecko Bootloader User Guide and AN1086: Using the Gecko Bootloader with Silicon Labs Bluetooth Applications)

Demo/Example Descriptions

The following examples are provided. Examples with (*) in their names have a matching pre-built demo.

Silicon Labs Gecko Bootloader examples (see UG266: Silicon Labs Gecko Bootloader User Guide and AN1086: Using the Gecko Bootloader with Silicon Labs Bluetooth Applications)


Bluetooth Examples


Bluetooth – RCP: Radio Co-Processor (RCP) target application. Runs the Bluetooth Controller (i.e. the Link Layer only) and provides access to it using the standard HCI (Host-Controller Interface) over a UART connection.Bluetooth – NCP(*): Network Co-Processor (NCP) target application. Runs the full Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using the Dynamic GATT API.Bluetooth – NCP Empty(*): Network Co-Processor (NCP) target application. Runs the full Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use the Dynamic GATT API.Bluetooth – NCP Host: Reference implementation of an NCP (Network Co-Processor)


Host: Reference implementation of an NCP (Network Co-Processor) host, which typically runs on a central MCU without radio. It can connect to an NCP target via UART to access the Bluetooth stack of the target and to control it using BGAPI. This example uses the Dynamic GATT feature.Bluetooth – NCP AoA Locator(*): Network Co-Processor (NCP) target application extended with CTE Receiver support. It enables Angle of Arrival (AoA) calculation. Use this application with Direction Finding host examples.Bluetooth – SoC AoA Asset Tag(*): Demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a Direction Finding setup estimating Angle of Arrival (AoA).Bluetooth – SoC Blinky(*): The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, pressing or releasing PB0 on the mainboard notifies the app. This is a demonstration of a simple two-way data exchange over GATT.Bluetooth – SoC DTM: This example implements


GATT.Bluetooth – SoC DTM: This example implements the direct test mode (DTM) application for radio testing. DTM commands can be called via UART. See AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x for more information.Bluetooth – SoC Empty: A minimal project structure that serves as a starting point for custom Bluetooth applications. It contains a minimal GATT database that can be expanded to fit your application requirements. The application starts advertising after boot and restarts advertising after a connection is closed. It also supports Over-the-Air Device Firmware Upgrade (OTA DFU)Bluetooth – SoC Interoperability Test (*): A test procedure containing several test cases for Bluetooth Low Energy communication. This demo is meant to be used with the EFR Connect mobile app, through the "Interoperability Test" tile on the Develop view of the app.Bluetooth – SoC Thermometer(*): Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and


is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard.Bluetooth – SoC Thermometer Client: Implements a GATT Client that discovers and connects with up to four Bluetooth LE devices advertising themselves as Thermometer Servers. It displays the discovery process and the temperature values received via UART.


Note: Some radio boards will exhibit random pixels in the display when this example is running because they have a shared pin for sensor- and display-enabled signals.
Bluetooth – SoC Thermometer FreeRTOS: Demonstrates the integration of FreeRTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app.Bluetooth – SoC Thermometer Micrium OS: Demonstrates the integration of Micrium RTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app.Bluetooth – SoC Throughput(*): Tests the throughput capabilities of the device and can be used to measure throughput between two EFR32 devices, as well as between a device and a smartphone using the EFR Connect mobile app, through the Throughput demo tile.Bluetooth – SoC Voice(*): Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 and Thunderboard EFR32BG22 boards and demonstrates how to send voice data over GATT, which is acquired from the on-board microphones.Bluetooth – SoC iBeacon(*): An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app.Bluetooth – SoC Thunderboard Sense 2(  ), and Thunderboard EFR32BG22(  ): Demonstrate the features of the Thunderboard Kit. These can be tested with the Thunderboard mobile app.


Dynamic Multiprotocol Examples (see AN1134: Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols on
RAIL for more information)


Bluetooth – SoC Empty RAIL DMP FreeRTOS: A minimal project structure, used as a starting point for custom Bluetooth + Proprietary DMP (Dynamic Multiprotocol) applications. It runs on top of FreeRTOS and multiprotocol RAIL.Bluetooth – SoC Empty RAIL DMP Micrium OS: A minimal project structure, used as a starting point for custom Bluetooth + Proprietary DMP (Dynamic Multiprotocol) applications. It runs on top of Micrium OS and multiprotocol RAIL.Bluetooth – SoC Empty Standard DMP FreeRTOS: A minimal project structure, used as a starting point for custom Bluetooth + Standard DMP (Dynamic Multiprotocol) applications. It runs on top of FreeRTOS and multiprotocol RAIL utilizing IEE802.15.4 standard protocol.Bluetooth – SoC Empty Standard DMP Micrium OS: A minimal project structure, used as a starting point for custom Bluetooth + Standard DMP (Dynamic Multiprotocol) applications. It runs on top of Micrium OS and multiprotocol RAIL, utilizing IEE802.15.4 standard protocol.Bluetooth – SoC Light RAIL DMP FreeRTOS(*): A Dynamic


SoC Light RAIL DMP FreeRTOS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via Proprietary protocol use the Flex (RAIL) - Switch sample app.Bluetooth – SoC Light RAIL DMP Micrium OS: A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via Proprietary protocol use the Flex (RAIL) - Switch sample app.Bluetooth – SoC Light Standard DMP FreeRTOS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a standard protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via standard protocol use the "Flex (RAIL) - Switch Standards" sample app.Bluetooth – SoC Light Standard DMP


sample app.Bluetooth – SoC Light Standard DMP Micrium OS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a standard protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via standard protocol use the "Flex (RAIL) - Switch Standards" sample app.


NCP Host Examples (located in C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\\app\bluetooth\examples_host)


empty: Minimal host-side project structure, used as a starting point for NCP host applications. Use it with the Bluetooth – NCP target application flashed to the radio board.ota-dfu: Demonstrates how to perform an OTA DFU on a Silicon Labs Bluetooth Device. It requires a WSTK with a radio board flashed with NCP firmware to be used as the GATT client that performs the OTA.uart-dfu: Demonstrates how to perform a UART DFU on a Silicon Labs Bluetooth Device running NCP firmwarevoice: On a WSTK programmed with NCP firmware, it to connects to the Bluetooth – SoC Voice example, sets the correct configuration on it, receives audio via Bluetooth, and stores audio data into a file.aoa_locator: A locator host sample app that works together with a Bluetooth – NCP AoA Locator target app. It receives IQ samples from the target and estimates the Angle of Arrival (AoA). For more information see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_multilocator: Connects to multiple


RTL Library.aoa_multilocator: Connects to multiple aoa_locator sample apps (via MQTT) and estimates a position from Angles of Arrival (AoA). For more information, see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_multilocator_gui: Connects to the aoa_multilocator sample app (via MQTT), reads out the position estimations and displays the tags and locators on a 3D GUI. This sample app is python based. For more information, see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_compass: Demo application with GUI showcasing the angle estimation capabilities of the RTL library. This is now replaced with the AoA Analyzer tool as described in QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide.throughput: Tests the throughput capabilities of the device in NCP mode and can be used to measure throughput between two devices as well as between a device and a smartphone


Python-Based NCP Host Examples
Python-based NCP host examples can be accesssed at https://github.com/SiliconLabs/pybgapi-examples. These examples are meant to be used with PyBGAPI (https://pypi.org/project/pybgapi/).

Silicon Labs Bluetooth LE Documentation

A graphic representation of the documentation set is at the end of this list.

Getting Started

Getting Started with Simplicity Studio 5 and the Gecko SDK -
Describes downloading development tools and the Gecko SDK, which includes the Silicon Labs Bluetooth SDK. Introduces the Simplicity Studio 5 interface.

UG103.14: Bluetooth LE Fundamentals -
Offers an overview for those new to the Bluetooth low energy technology.

QSG169: Bluetooth SDK v3.x Quick Start Guide -
Describes using the Simplicity Studio 5 IDE and tools for application development with Bluetooth SDK v3.x.

AN1255: Transitioning from the v2.x to the v3.x Bluetooth SDK -
Describes the differences between using Bluetooth SDK v2.x in Simplicity Studio 4 and usingBluetooth SDK v3.x in Simplicity Studio 5. Outlines the steps needed to migrate a v2.x project to v3.x.

Developing with Bluetooth LE

UG434: Silicon Labs Bluetooth C Application Developer's Guide for SDK v3.x -
Covers the Bluetooth stack v3.x architecture, application development flow, using the MCU core and peripherals, stack configuration options, and stack resource usage.

UG438: GATT Configurator User's Guide for Bluetooth SDK v3.x and Higher -
Describes how to use the Simplicity Studio 5 GATT Configurator, an intuitive interface providing access to all the Profiles, Services, Characteristics, and Descriptors as defined in the Bluetooth specification.


UG118: Blue Gecko Bluetooth Profile Toolkit Developer's Guide -
Reviews using this XML-based mark-up language to describe the Bluetooth GATT database,configure access and security properties, and include the GATT database as part of the firmware.

AN1259: Using the v3.x Silicon Labs Bluetooth Stack in Network Co-Processor Mode -
Describes how to configure the NCP target and how to program the NCP host when using the Bluetooth Stack in Network Co-Processor mode

AN1328: Enabling a Radio Co-Processor using the Bluetooth Controller and HCI Functions -
Gives a short overview of the standard Host Controller Interface (HCI) and how to use it with a Silicon Labs Bluetooth LE controller.

AN1260: Integrating v3.x Silicon Labs Bluetooth Applications with Real-Time Operating Systems -
Describes how to integrate a v3.x Silicon Labs Bluetooth application with an RTOS, and demonstrate how a time- and event-driven application can be run in parallel with the Bluetooth stack.

AN1362: Amazon FreeRTOS Architecture and Sample Applications -
Summarizes Amazon FreeRTOS components and sample applications, and explains how to use the examples to communicate with the Amazon Web Services (AWS) cloud with a smart phone app.

AN1366: Bluetooth LE Use Case-Based Low Power Optimization -
Describes how to exploit the different features of Bluetooth technology to achieve the minimum possible energy consumption for a given use case.

UG162: Simplicity Commander Reference Guide -
Describes how and when to use Simplicity Commander's Command-Line Interface.

Direction Finding

UG103.18: Bluetooth Direction Finding Fundamentals -
Explains the basics of Bluetooth Angle of Arrival (AoA) and Angle of Departure (AoD) direction finding technologies and provides the theory behind estimating angle of arrival.


QSG175: Silicon Labs' Direction Finding Solution Quick-Start Guide -
Describes the software components provided by Silicon Labs to support Direction Finding (DF) and provides instructions on how to start developing your own application.

AN1296: Application Development with Silicon Labs' RTL Library -
Describes the sample applications provided to demonstrate the directing finding capabilities of Bluetooth 5.1. Angle of Arrival (AoA) estimation is demonstrated with the use of Silicon Labs' Real Time Locating (RTL) library.These techniques are applicable to the EFR32MGx and EFR32BGx series.

AN1297: Custom Direction-Finding Solutions using Silicon Labs' Bluetooth Stack -
Bluetooth 5.1 makes it possible to send Constant Tone Extensions (CTEs) in Bluetooth packets on which phase measurements can be done. This guide is for those implementing custom applications that take advantage of phase measurement and antenna switching capabilites.

UG514: Using the Bluetooth Direction Finding Tool Suite -
The Bluetooth Direction Finding Tool Suite is meant to ease development with the Silicon Labs' RTL library. It provides multiple tools to configure the system, and also helps the development with analyzer tools that calculate many output parameters from the observed IQ samples.

Multiprotocol

UG103.16: Multiprotocol Fundamentals -
Describes the four multiprotocol modes, discusses considerations when selecting protocols for multiprotocol implementations, and reviews the Radio Scheduler, a required component of a dynamic multiprotocol solution.

UG305: Dynamic Multiprotocol User's Guide -
Describes how to implement a dynamic multiprotocol solution.

AN1269: Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols on RAIL in GSDK v3.x -
Provides details on how to develop a dynamic multiprotocol application running Bluetooth and aproprietary protocol on RAIL in GSDK v3.x.


AN1333: Running Zigbee, OpenThread, and Bluetooth Concurrently on a Linux Host with a Multiprotocol Co-Processor -
Describes how to run any combination of Zigbee EmberZNet, OpenThread, and Bluetooth networking stacks on a Linux host processor, interfacing with a single EFR32 Radio Co-processor (RCP) with multiprotocol and multi-PAN support, as well as how to run the Zigbee stack on the EFR32 as a network co-processor (NCP) alongside the OpenThread RCP.

Coexistence

UG103.17: Wi-Fi Coexistence Fundamentals -
Introduces methods to improve the coexistence of 2.4 GHz IEEE 802.11b/g/n Wi-Fi and other 2.4 GHz radios such as Bluetooth, Bluetooth Mesh, Bluetooth Low Energy, and IEEE 802.15.4-based radios such as Zigbee and OpenThread.

AN1128: Bluetooth Coexistence with Wi-Fi -
Describes the Wi-Fi impact on Bluetooth and methods to improve Bluetooth coexistence with Wi-Fi.Explains design considerations to improve coexistence without direct interaction between Bluetooth and Wi-Fi radios.These techniques are applicable to the EFR32MGx and EFR32BGx series. Discusses the Silicon Labs Packet Traffic Arbitration (PTA) support to coordinate 2.4GHz RF traffic for co-located Bluetooth and Wi-Fi radios.

Security

UG103.05: IoT Endpoint Security Fundamentals -
Introduces the security concepts that must be considered when implementing an Internet of Things (IoT) system. Using the ioXt Alliance's eight security principles as a structure, it clearly delineates the solutions Silicon Labs provides to support endpoint security and what you must do outside of the Silicon Labs framework.


AN1302: Bluetooth Low Energy Application Security Design Considerations in SDK v3.x and Higher -
Provides details on designing Bluetooth Low Energy applications with security and privacy in mind.

AN1190: Series 2 Secure Debug -
Describes how to lock and unlock the debug access of EFR32 Gecko Series 2 devices. Many aspects of the debug access, including the secure debug unlock are described. The Debug Challenge Interface (DCI) and Secure Engine (SE) Mailbox Interface for locking and unlocking debug access are also included.

AN1222: Production Programming of Series 2 Devices -
Provides details on programming, provisioning, and configuring Series 2 devices in production environments. Covers Secure Engine Subsystem of Series 2 devices, which runs easily upgradeable Secure Engine (SE) or Virtual Secure Engine (VSE) firmware.

AN1247: Anti-Tamper Protection Configuration and Use -
Shows how to program, provision, and configure the anti-tamper module on EFR32 Series 2 devices with Secure Vault.

AN1268: Authenticating Silicon Labs Devices using Device Certificates -
How to authenticate an EFR32 Series 2 device with Secure Vault, using secure device certificates and signatures.

AN1271: Secure Key Storage -
Explains how to securely "wrap" keys in EFR32 Series 2 devices with Secure Vault, so they can be stored in non-volatile storage.

AN1303: Programming Series 2 Devices Using the Debug Challenge Interface (DCI) and Serial Wire Debug (SWD) -
 Describes how to provision and configure Series 2 devices through the DCI and SWD.

AN1311: Integrating Crypto Functionality Using PSA Crypto Compared to Mbed TLS -
Describes how to integrate crypto functionality into applications using PSA Crypto compared to Mbed TLS.

Bootloading


Bootloading

UG103.06: Bootloader Fundamentals -
Introduces bootloading for Silicon Labs networking devices. Discusses the Gecko Bootloader as well as legacy Ember and Bluetooth bootloaders, and describes the file formats used by each.

UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher -
Describes the high-level implementation of the Silicon Labs Gecko Bootloader for EFR32 SoCs and NCPs, and provides information on how to get started using the Gecko Bootloader with Silicon Labs wireless protocol stacks in GSDK 4.0 and higher.

AN1086: Using the Gecko Bootloader with Silicon Labs Bluetooth Applications -
Includes detailed information on using the Gecko Bootloader with Silicon Labs Bluetooth applications. It supplements the general Gecko Bootloader implementation information provided in UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

AN1326: Transitioning to the Updated Gecko Bootloader in GSDK 4.0 and Higher -
Gecko Bootloader v2.x, introduced in GSDK 4.0, contains a number of changes compared to Gecko Bootloader v1.x. This document describes the differences between the versions, including how to configure the new Gecko Bootloader in Simplicity Studio 5.

AN1218: Series 2 Secure Boot with RTSL -
Contains detailed information on configuring and using the Secure Boot with hardware Root of Trust and Secure Loader on Series 2 devices, including how to provision the signing key. This is a companion document to UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Non-Volatile Data Storage


Non-Volatile Data Storage

UG103.07: Non-Volatile Data Storage Fundamentals -
Introduces non-volatile data storage using flash and the three different storage implementations offered for Silicon Labs microcontrollers and SoCs: Simulated EEPROM, PS Store, and NVM3.

AN1135: Using Third Generation Non-Volatile Memory (NVM3) Data Storage -
Explains how NVM3 can be used as non-volatile data storage in various protocol implementations.

Testing

AN1246: EFR32BG SoC Bluetooth Smart Device Power Consumption Measurements -
Describes how to measure the power consumption of EFR32BG devices running the Bluetooth i-Beacon example.For general instructions, see AN969: Measuring Power Consumption in Wireless Gecko Devices.

AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth SDK v3.x and Higher -
Reviews performing radio frequency physical layer evaluation with EFR32BG SoCs and BGM modules using the Direct Test Mode protocol in Bluetooth SDK v3.x.

AN1317: Using Network Analyzer with Bluetooth Low Energy and Mesh -
Describes using Simplicity Studio 5's Network Analyzer to debug Bluetooth Mesh and Low Energy applications. It can be read jointly with AN958: Debugging and Programming Interfaces for Customer Designs for more information on using Packet Trace Interface with custom hardware.

AN1309: Bluetooth Low Energy Interoperability Testing Report -
Includes the results of the interoperability testing of Silicon Labs' ICs and Bluetooth Low Energy stack with Android and iOS smart phones.

Documentation Flow

Bluetooth LE documentation flow


You are viewing documentation for version: 5.0 | This version works with Simplicity Studio 5 only. If you have Simplicity Studio 4, switch to 2.13. | For additional versions, see Version History.

General Overview

Release Notes | Downloads

About the Bluetooth Stack

The v3.x Silicon Labs Bluetooth stack is an advanced Bluetooth 5-compliant protocol stack implementing the Bluetooth low energy standard. It supports multiple connections, concurrent central, peripheral, broadcaster, and observer roles. The v3.x Silicon Labs Bluetooth stack is meant for Silicon Labs EFR32 SoCs and modules.

The Silicon Labs Bluetooth stack provides multiple APIs for the developer to access the Bluetooth functionality. Three modes are supported:

Standalone mode, where both the Bluetooth stack and the application run in an EFR32SoC or module. The application can be developed with C programming language.

Standlone Mode

Network Co-Processor (NCP) mode, where the Bluetooth stack runs in an EFR32 and the application runs on a separate host MCU. For this use case, the Bluetooth stack can be configured into NCP mode where the API is exposed over a serial inter- face such as UART.

NCP Mode

Radio Co-Processor (RCP) mode, where only the Link Layer of the Bluetooth stack runs on the EFR32, and the Host Layer of the stack, as well as the application, runs on a separate host MCU or PC. In this use case, the Host Layer is developed by a third party, since Silicon Labs’ Bluetooth stack is only built for EFR32 SoCs / modules. The Link Layer and the host layer communicate via HCI (Host-Controller Interface), which is a standard interface between the two layers. The HCI can be accessed via UART following the Bluetooth SIG's UART (H4) transport protocol.RCP Mode

Bluetooth Stack Features


Bluetooth Stack Features

The features of the Silicon Labs Bluetooth stack are listed in the following table.

Stack Features

Bluetooth Qualification

All products deploying Bluetooth technology must go through the Bluetooth SIG's Qualification Process. Online resources will help you learn more about the  Bluetooth Qualification , process, and tutorials on the  Launch Studio , which is the online tool used to complete the Bluetooth Qualification Process. For assistance to qualify your device, consider reaching out to your nearest  Bluetooth Qualification Consultant .

When qualifying your end-product based on Silicon Labs’ Bluetooth stack, integrate the pre-qualified components. To learn more and see the list of pre-qualified components, see QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

The Bluetooth Stack APIs

This section briefly describes the different software APIs.

The Bluetooth API

The Bluetooth API provided by the Silicon Labs Bluetooth stack is the primary API to communicate with the stack. It provides access to all the Bluetooth functionality implemented by the Bluetooth stack, such as the Generic Access Profile (GAP), connection manager, the security manager (SM), GATT client and server.

In addition to the Bluetooth features, the Bluetooth API also provides access to a few other functions such as the Direct Test Mode (DTM) API for RF testing purposes, the Persistent Store (PS) API for reading and writing keys to and from the devices flash memory, the DFU (Device Firmware Update) API for field firmware updates, and the System API for various system level functions.

The BGAPI Serial Protocol and the Bluetooth Host API

When configured in NCP (network co-processor) mode, the Bluetooth stack can be controlled using the BGAPI serial protocol. This allows the Bluetooth stack to be controlled over a serial interface such as UART from a separate host, such as EFM32 microcontroller. The BGAPI serial protocol provides exactly the same Bluetooth APIs over UART as the BGAPI API when used in a standalone mode.


The BGAPI serial protocol is a lightweight, binary protocol that carries the BGAPI commands from the host to the Bluetooth stack, and carries responses and events from the Bluetooth stack back to the host.

The Bluetooth SDK delivers a ready-made BGAPI serial protocol parser implementation both for the NCP target (EFR) and for the NCP host. It implements the serial protocol parser for all APIs provided by the Bluetooth stack. The host code developed on top of host API can be written to be identical to the code for the EFR, which allows easy porting of the application code from the EFR to a separate host or vice versa.

BGAPI

The BGAPI serial protocol packet structure is described below. For more information, see the BGAPI Headers.

BGAPI Table

The Bluetooth Profile Toolkit GATT Builder

The Bluetooth Profile Toolkit is an XML-based API and description language used to describe the GATT-based service and characteristic easily without writing code. The XML files can be easily written by hand based on the information contained in UG118: Blue Gecko Bluetooth® Profile Toolkit Developer Guide. Use the Profile Toolkit GATT Builder if you are developing outside of Simplicity Studio.

Within Simplicity Studio, the GATT Configurator allows building the GATT in a visual way without hand editing the XML file. See UG438: GATT Configurator User’s Guide for Bluetooth SDK v3.x for details. Open the GATT Configurator in Simplicity Studio through the Project Configurator, Software Components tab, under Advanced Configurators. Click Open and the GATT Configurator tool opens the file gatt_configuration.btconf in a new tab.

Opening Bluetooth GATT Configurator


Opening Bluetooth GATT Configurator

gatt_configuration.btconf provides the trunk of the GATT database. It is located inside the config > btconfig directory of your project. You can add additional XML files in the same directory and extend the GATT database. The contents of the additional XML files will appear as Contributed Items in the GATT Configurator UI. For examples, see the ota-dfu.xml file provided with most sample applications.

The GATT database developed with the Profile Toolkit is converted to a .c file and a .h file and included in the application project as a pre-build step when the firmware is compiled. Then, the GATT can be accessed with the Bluetooth stack GATT APIs or by a remote Bluetooth device.

GATT XML

CMSIS and EMLIB

The Cortex Microcontroller Software Interface Standard (CMSIS) is a common coding standard for all ARM Cortex devices. The CMSIS library provided by Silicon Labs contains header files, defines (for peripherals, registers and bitfields), and startup files for all devices. In addition, CMSIS includes functions that are common to all Cortex devices, such as interrupt handling, intrinsic functions, and so on. Although you can write to registers using hard-coded address and data values, it is recommended to use the defines to ensure portability and readability of the code.

To simplify programming Wireless Geckos, Silicon Labs develops and maintains a complete C function library called EMLIB that provides efficient, clear, and robust access to and control of all peripherals and core functions in the device. This library is within the em_xxx.c (for example, em_dac.c) and em_xxx.h files in the SDK. The EMLIB documentation is available in the Gecko Platform documentation.

About the Bluetooth SDK


About the Bluetooth SDK

The Bluetooth SDK is a full software development kit that enables you to develop applications on top of the Bluetooth stack using C programming language. The SDK also supports making standalone applications, where the Bluetooth stack and the application both run in the Wireless Gecko, or the network co-processor (NCP) architecture, where the application runs on an external host and the Bluetooth stack runs in the Wireless Gecko. SDK contents and folder structure are described in QSG169: Bluetooth® SDK v3.x Quick-Start Guide.

About Demos and Examples

Starting application development from scratch can be difficult. For that reason, the Bluetooth SDK comes with a number of built-in demos and examples covering the most frequent use cases, as shown in the following figure. Demos are pre-built application images that you can run immediately. Software examples can be modified before building the application image. Demos with the same name as software examples are built from their respective example.

Note: The demos and examples you see are determined by the part selected. If you are using a custom solution with more than one part, click on the part you are working with to see only the items applicable to that part.

Demos and Software Example are in the Example Projects & Demos tab in the launcher view of Simplicity Studio.

To download and run a demo on your device, click RUN on the right demo you want to run on your target.

To import software example code into your workspace as a new project using default project configurations, click CREATE on the name of the desired example project and a New Project Wizard window will open. Click FINISH and your project will open in Simplicity IDE mode where you can customize it.


If an example project closely matches your needs, extend the code with your application code and rewrite the custom sections. Otherwise, start with the SoC-Empty application. Note that the SoC-Empty application is not blank, but rather provides a minimal project that only starts advertising.

Studio Launcher

Demo/Example Descriptions

The following examples are provided. Examples with (*) in their names have a matching pre-built demo.

Silicon Labs Gecko Bootloader examples (see UG266: Silicon Labs Gecko Bootloader User Guide and AN1086: Using the Gecko Bootloader with Silicon Labs Bluetooth Applications)


Bluetooth Examples
Bluetooth Examples


Bluetooth – RCP: Radio Co-Processor (RCP) target application. Runs the Bluetooth Controller (i.e. the Link Layer only) and provides access to it using the standard HCI (Host-Controller Interface) over a UART connection.Bluetooth – NCP(*): Network Co-Processor (NCP) target application. Runs the full Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example does not have a GATT database, but makes it possible to build one from the application using the Dynamic GATT API.Bluetooth – NCP Empty(*): Network Co-Processor (NCP) target application. Runs the full Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. NCP mode makes it possible to run your application on a host controller or PC. This example contains a minimal GATT database, and cannot be used with host applications that use the Dynamic GATT API.Bluetooth – NCP Host: Reference implementation of an NCP (Network Co-Processor)


Host: Reference implementation of an NCP (Network Co-Processor) host, which typically runs on a central MCU without radio. It can connect to an NCP target via UART to access the Bluetooth stack of the target and to control it using BGAPI. This example uses the Dynamic GATT feature.Bluetooth – NCP AoA Locator(*): Network Co-Processor (NCP) target application extended with CTE Receiver support. It enables Angle of Arrival (AoA) calculation. Use this application with Direction Finding host examples.Bluetooth – SoC AoA Asset Tag(*): Demonstrates a CTE (Constant Tone Extension) transmitter that can be used as an asset tag in a Direction Finding setup estimating Angle of Arrival (AoA).Bluetooth – SoC Blinky(*): The classic blinky example using Bluetooth communication. From the EFR Connect mobile app, the LED controller button toggles LED0 on the board. In addition, pressing or releasing PB0 on the mainboard notifies the app. This is a demonstration of a simple two-way data exchange over GATT.Bluetooth – SoC DTM: This example implements


GATT.Bluetooth – SoC DTM: This example implements the direct test mode (DTM) application for radio testing. DTM commands can be called via UART. See AN1267: Radio Frequency Physical Layer Evaluation in Bluetooth® SDK v3.x for more information.


Bluetooth – SoC Empty: A minimal project structure that serves as a starting point for custom Bluetooth applications. It contains a minimal GATT database that can be expanded to fit your application requirements. The application starts advertising after boot and restarts advertising after a connection is closed. It also supports Over-the-Air Device Firmware Upgrade (OTA DFU)Bluetooth – SoC Interoperability Test (*): A test procedure containing several test cases for Bluetooth Low Energy communication. This demo is meant to be used with the EFR Connect mobile app, through the "Interoperability Test" tile on the Develop view of the app.Bluetooth – SoC Thermometer(*): Implements a GATT Server with the Health Thermometer Profile, which enables a Client device to connect and get temperature data. Temperature is read from the Si7021 digital relative humidity and temperature sensor of the WSTK or of the Thunderboard.Bluetooth – SoC Thermometer Client: Implements a GATT Client that discovers and connects with up to four Bluetooth LE devices advertising themselves as Thermometer Servers. It displays the discovery process and the temperature values received via UART.
Note: Some radio boards will exhibit random pixels in the display when this example is running because they have a shared pin for sensor- and display-enabled signals.


Bluetooth – SoC Thermometer FreeRTOS: Demonstrates the integration of FreeRTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app.Bluetooth – SoC Thermometer Micrium OS: Demonstrates the integration of Micrium RTOS into Bluetooth applications. RTOS is added to the Bluetooth - SoC Thermometer sample app.Bluetooth – SoC Throughput(*): Tests the throughput capabilities of the device and can be used to measure throughput between two EFR32 devices, as well as between a device and a smartphone using the EFR Connect mobile app, through the Throughput demo tile.Bluetooth – SoC Voice(*): Voice over Bluetooth Low Energy sample application. It is supported by Thunderboard Sense 2 and Thunderboard EFR32BG22 boards and demonstrates how to send voice data over GATT, which is acquired from the on-board microphones.Bluetooth – SoC iBeacon(*): An iBeacon device implementation that sends non-connectable advertisements in iBeacon format. The iBeacon Service gives Bluetooth accessories a simple and convenient way to send iBeacons to smartphones. This example can be tested together with the EFR Connect mobile app.Bluetooth – SoC Thunderboard Sense 2(  ), and Thunderboard EFR32BG22(  ): Demonstrate the features of the Thunderboard Kit. These can be tested with the Thunderboard mobile app.


Dynamic Multiprotocol Examples (see AN1134: Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols on
RAIL for more information)


Bluetooth – SoC Empty RAIL DMP FreeRTOS: A minimal project structure, used as a starting point for custom Bluetooth + Proprietary DMP (Dynamic Multiprotocol) applications. It runs on top of FreeRTOS and multiprotocol RAIL. Bluetooth – SoC Empty RAIL DMP Micrium OS: A minimal project structure, used as a starting point for custom Bluetooth + Proprietary DMP (Dynamic Multiprotocol) applications. It runs on top of Micrium OS and multiprotocol RAIL. Bluetooth – SoC Empty Standard DMP FreeRTOS: A minimal project structure, used as a starting point for custom Bluetooth + Standard DMP (Dynamic Multiprotocol) applications. It runs on top of FreeRTOS and multiprotocol RAIL utilizing IEE802.15.4 standard protocol. Bluetooth – SoC Empty Standard DMP Micrium OS: A minimal project structure, used as a starting point for custom Bluetooth + Standard DMP (Dynamic Multiprotocol) applications. It runs on top of Micrium OS and multiprotocol RAIL, utilizing IEE802.15.4 standard protocol.Bluetooth – SoC Light RAIL DMP FreeRTOS(*):


– SoC Light RAIL DMP FreeRTOS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via Proprietary protocol use the Flex (RAIL) - Switch sample app.Bluetooth – SoC Light RAIL DMP Micrium OS: A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a Proprietary protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via Proprietary protocol use the Flex (RAIL) - Switch sample app. Bluetooth – SoC Light Standard DMP FreeRTOS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a standard protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via standard protocol use the "Flex (RAIL) - Switch Standards" sample app. Bluetooth – SoC Light


Switch Standards" sample app. Bluetooth – SoC Light Standard DMP Micrium OS(*): A Dynamic Multiprotocol reference application demonstrating a light bulb that can be switched both via Bluetooth and via a standard protocol. To switch it via Bluetooth use the Wireless Gecko smartphone app. To switch it via standard protocol use the "Flex (RAIL) - Switch Standards" sample app.


NCP Host Examples (located in C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\\app\bluetooth\examples_host)


empty: Minimal host-side project structure, used as a starting point for NCP host applications. Use it with the Bluetooth – NCP target application flashed to the radio board.ota-dfu: Demonstrates how to perform an OTA DFU on a Silicon Labs Bluetooth Device. It requires a WSTK with a radio board flashed with NCP firmware to be used as the GATT client that performs the OTA.uart-dfu: Demonstrates how to perform a UART DFU on a Silicon Labs Bluetooth Device running NCP firmwarevoice: On a WSTK programmed with NCP firmware, it to connects to the Bluetooth – SoC Voice example, sets the correct configuration on it, receives audio via Bluetooth, and stores audio data into a file.aoa_locator: A locator host sample app that works together with a Bluetooth – NCP AoA Locator target app. It receives IQ samples from the target and estimates the Angle of Arrival (AoA). For more information see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_multilocator: Connects to multiple


RTL Library.aoa_multilocator: Connects to multiple aoa_locator sample apps (via MQTT) and estimates a position from Angles of Arrival (AoA). For more information, see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_multilocator_gui: Connects to the aoa_multilocator sample app (via MQTT), reads out the position estimations and displays the tags and locators on a 3D GUI. This sample app is python based. For more information, see AN1296: Application Development with Silicon Labs’ RTL Library.aoa_compass: Demo application with GUI showcasing the angle estimation capabilities of the RTL library. This is now replaced with the AoA Analyzer tool as described in QSG175: Silicon Labs Direction Finding Solution Quick-Start Guide.throughput: Tests the throughput capabilities of the device in NCP mode and can be used to measure throughput between two devices as well as between a device and a smartphone


Python-Based NCP Host Examples
Python-based NCP host examples can be accesssed at https://github.com/SiliconLabs/pybgapi-examples. These examples are meant to be used with PyBGAPI (https://pypi.org/project/pybgapi/).


CMSIS Version 5

The branch master of this GitHub repository contains the CMSIS Version 5.3.0.  The documentation is available under http://arm-software.github.io/CMSIS_5/General/html/index.html

Use Issues to provide feedback and report problems for CMSIS Version 5.

Note: The branch develop of this GitHub repository reflects our current state of development and is constantly updated. It gives our users and partners contiguous access to the CMSIS development. It allows you to review the work and provide feedback or create pull requests for contributions.

A pre-built documentation is updated from time to time, but may be also generated using the instructions under Generate CMSIS Pack for Release.

What's Hot

CMSIS-RTOS2: RTX 5 is now available for IAR, GCC, Arm Compiler 5, Arm Compiler 6

CMSIS-RTOS2: FreeRTOS adoption (release) is available https://github.com/ARM-software/CMSIS-FreeRTOS

CMSIS-RTOS2: RTX5 available for Cortex-A

CMSIS-Core: compiler agnostic features extended to simplify transition on LLVM based front-end

CMSIS-Core-A: CMSIS-Core for Cortex-A

CMSIS-NN: Bare metal Neural Network function library.

Implemented Enhancements

Support for Armv8-M Architecture (Mainline and Baseline) as well as devices Cortex-M23 and Cortex-M33

CMSIS-RTOS Version 2 API and RTX reference implementation with several enhancements:

Dynamic object creation, Flag events, C API, additional thread and timer functions

CMSIS-RTOS API Secure and Non-Secure support, multi-processor support

Further Planned Enhancements

CMSIS-DAP: extended trace support

CMSIS-Zone: management of complex system

Improvements for Cortex-A / M hybrid devices (focus on Cortex-M interaction)

CMSIS-Pack


Improvements for Cortex-A / M hybrid devices (focus on Cortex-M interaction)

CMSIS-Pack

Additions for generic example and project templates
Adoption of IAR Flash Loader technology

For further details see also the Slides of the Embedded World CMSIS Partner Meeting.

Directory Structure

CMSIS/Core

CMSIS-Core related files (for release)

CMSIS/DAP

CMSIS-DAP related files and examples

CMSIS/Driver

CMSIS-Driver API headers and template files

CMSIS/DSP

CMSIS-DSP related files

CMSIS/NN

CMSIS-NN related files

CMSIS/RTOS

RTOS v1 related files (for Cortex-M)

CMSIS/RTOS2

RTOS v2 related files (for Cortex-M & Armv8-M)

CMSIS/Pack

CMSIS-Pack examples and tutorials

CMSIS/DoxyGen

Source of the documentation

CMSIS/Utilities

Utility programs

Generate CMSIS Pack for Release

This GitHub development repository contains already pre-built libraries of various software components (DSP, RTOS, RTOS2).
These libraries are validated for release.

To build a complete CMSIS pack for installation the following additional tools are required:

doxygen.exe    Version: 1.8.6 (Documentation Generator)

mscgen.exe     Version: 0.20  (Message Sequence Chart Converter)

7z.exe (7-Zip) Version: 16.02 (File Archiver)

Using these tools, you can generate on a Windows PC:

CMSIS Software Pack using the batch file gen_pack.bat (located in ./CMSIS/Utilities). This batch file also generates the documentation.

CMSIS Documentation using the batch file genDoc.bat (located in ./CMSIS/Doxygen).

The file ./CMSIS/DoxyGen/How2Doc.txt describes the rules for creating API documentation.

License


License

Arm CMSIS is licensed under Apache-2.0.

Contributions and Pull Requests

Contributions are accepted under Apache-2.0. Only submit contributions where you have authored all of the code.

Issues and Labels

Please feel free to raise an issue on GitHub
to report misbehavior (i.e. bugs) or start discussions about enhancements. This
is your best way to interact directly with the maintenance team and the community.
We encourage you to append implementation suggestions as this helps to decrease the
workload of the very limited maintenance team.

We will be monitoring and responding to issues as best we can.
Please attempt to avoid filing duplicates of open or closed items when possible.
In the spirit of openness we will be tagging issues with the following:

bug – We consider this issue to be a bug that will be investigated.

wontfix - We appreciate this issue but decided not to change the current behavior.

enhancement – Denotes something that will be implemented soon.

future - Denotes something not yet schedule for implementation.

out-of-scope - We consider this issue loosely related to CMSIS. It might by implemented outside of CMSIS. Let us know about your work.

question – We have further questions to this issue. Please review and provide feedback.

documentation - This issue is a documentation flaw that will be improved in future.

review - This issue is under review. Please be patient.

DONE - We consider this issue as resolved - please review and close it. In case of no further activity this issues will be closed after a week.

duplicate - This issue is already addressed elsewhere, see comment with provided references.

Important Information - We provide essential informations regarding planned or resolved major enhancements.


You are viewing documentation for version: 3.5 (latest)| 3.4 | Version History

Getting Started with Connect Stack

Connect Documentation | Release Notes | Downloads

Silicon Labs is developing products designed to meet the demands of customers as we move to an ever-connected world of devices in
the home, what is often referred to as the IoT (Internet of Things). At a high level the goals of IoT for Silicon Labs are to:

Connect all the devices in the home with best-in-class mesh networking, whether with Ember ZigBee PRO or other emerging standards.

Leverage the company's expertise in low-power, constrained devices.

Enhance established low-power, mixed-signal chips.

Provide low-cost bridging to existing Ethernet and Wi-Fi devices.

Enable cloud services and connectivity to smartphones and tablets that promote ease of use and a common user experience for
customers.

Achieving all of these goals will increase adoption rates and user acceptance for IoT devices in the Connected Home.

One such challenge is managing devices requiring low power consumption, such as battery-powered devices where long battery life is
essential. To meet this challenge Silicon Labs has developed the Silicon Labs Connect stack. Connect provides a fully-featured, easily-customizable wireless networking solution optimized for devices that require low power consumption and are used in a simple network
topology. Connect is configurable to be compliant with regional communications standards worldwide. Each RF configuration is designed
for maximum performance under each regional standard.


The Silicon Labs Connect stack supports many combinations of radio modulation, frequency and data rates. The stack provides support
for end nodes, coordinators, and range extenders. It includes all wireless MAC (Medium Access Control) layer functions such as scanning
and joining, setting up a point-to-point or star network, and managing device types such as sleepy end devices, routers, and coordinators.
With all this functionality already implemented in the stack, users can focus on their end application development and not worry
about the lower-level radio and network details.

The Connect stack should be used in applications with simple network topologies, such as a set of data readers feeding information
directly to a single central collection point (star or extended star topology), or a set of nodes in the same range exchanging data in a
single-hop fashion (direct devices or MAC devices). It does not provide a full mesh networking solution such as that provided by the
EmberZNet PRO or Silicon Labs Thread stacks.

The Connect stack is part of the Silicon Labs Flex SDK (Software Development Kit), installed through Simplicity Studio. Connect runs
on top of RAIL (Radio Abstraction Interface Layer), also included with the Flex SDK. RAIL provides an intuitive, easily-customizable
radio interface layer that is designed to support proprietary or standards-based wireless protocols. For more information, see UG103.13: RAIL Fundamentals.

The Connect stack supports efficient application development through its “building block” plug-in design. When used with the Simplicity
Studio IDE (Integrated Development Environment), developers can easily select the functions that should be included in the application.
The resulting applications are completely portable, in that they can be recompiled for different regions, different MCUs, and different
radios.

Device Types

The Connect stack supports the following device types:


Device Types

The Connect stack supports the following device types:

Star coordinator: The star coordinator forms and manages the star or extended star network. The star coordinator also communicates
with other range extenders and end nodes. Each Connect star network has a single coordinator.

Star range extender: A device between the star coordinator and one or more star end nodes that can be used to extend the range of
the star end nodes. Each range extender can serve up to 32 star end nodes.

Star end node: Joins to a star coordinator or a star range extender.

Direct device: A device able to send and receive messages from other (direct) devices in range on the same PAN, with no star topology
restrictions.

MAC device: A device able to send and receive standard 802.15.4 messages from other 802.15.4 devices in range.

Stack Structure

The Connect stack provides code organized into three functional layers, as shown in the following figure:

PHY (physical)

MAC

Network

The PHY and MAC layers are based on the IEEE 802.15.4-2011 standard IEEE 802.15.4-2011 Specification.

The Network layer is based on a proprietary protocol.

Finally, the Connect Application Framework provides a complete tool and API infrastructure over the underlying stack layers. Functionality
within the Application Framework and the Connect stack layers is provided in the form of individual building blocks called plugins.
Details of the plugins for each layer are provided in the Silicon Labs Connect Application Framework API Reference included in the
stack documentation.

For more information about Connect Stack, see UG103.12.

Connect Documentation

The Connect SDK and the accompanying RAIL SDK are delivered as part of the Proprietary Flex SDK.

Getting Started


Getting Started

Getting Started with Simplicity Studio 5 and the Gecko SDK -
Describes downloading development tools and the Gecko SDK, which includes the Flex SDK (Connect and RAIL). Introduces the Simplicity Studio 5 interface.

QSG168: Proprietary Flex SDK v3.x Quick Start Guide -
Provides basic information on configuring, building, and installing applications using Silicon Labs Connect and RAIL, the two development paths in the Silicon Labs Proprietary Flex SDK v3.x.

UG103.12: Connect Fundamentals -
Describes the features and functions of the Silicon Labs Connect stack, including its device types, network topologies, and its 'building block' development methodology using plugins.

UG103.01: Wireless Networking Fundamentals -
Introduces some fundamental concepts of wireless networking. These concepts are referred to in other Fundamentals documents. If you are new to wireless networking, you should read this document first.

Developing with Connect

UG435.01: About the Connect v3.x User's Guide -
Introduces the Connect User's Guide collection for the Flex SDK v3.x.

UG435.02: Using Silicon Labs Connect v3.x with IEEE 802.15.4 -
Introduces the IEEE 802.15.4 standard on which Connect v3.x is based.

UG435.03: Architecture of the Silicon Labs Connect Stack v3.x -
Describes the architecture of the Silicon Labs Connect stack v3.x an how it implements IEEE 802.15.4.

UG435.04: Customizing Applications with Silicon Labs Connect v3.x -
Describes how to use components, callbacks, and events on top of the Gecko Platform application framework to configure features and application behavior.


UG435.05: Using Real Time Operating Systems with Silicon Labs Connect v3.x -
Describes the process to implement a Connect-based application on top of one of the supported Real Time Operating Systems (RTOS).

UG435.07: Energy Saving with Silicon Labs Connect v3.x -
Describes the features available in Connect v3.x to reduce power consumption. Using those features is described in AN1252: Building Low Power Networks with the Silicon Labs Connect Stack v3.x.

AN1252: Building Low Power Networks with the Silicon Labs Connect Stack v3.x -
Illustrates reducing power consumption in a Connect v3.x application using the sensor example.

UG162: Simplicity Commander Reference Guide -
Describes how and when to use Simplicity Commander's Command-Line Interface.

Bootloading

UG103.06: Bootloader Fundamentals -
Introduces bootloading for Silicon Labs networking devices. Discusses the Gecko Bootloader as well as legacy Ember and Bluetooth bootloaders, and describes the file formats used by each.

UG435.06: Bootloading and OTA with Silicon Labs Connect v3.x -
Explains standalone (serial) and application (OTA) bootloader options available for use within Connect v3.x-based applications.

AN1085: Using the Gecko Bootloader with Silicon Labs Connect -
Includes detailed information on using the Silicon Labs Gecko Bootloader with Connect. It supplements the general Gecko Bootloader implementation information provided in UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher -
Describes the high-level implementation of the Silicon Labs Gecko Bootloader for EFR32 SoCs and NCPs, and provides information on how to get started using the Gecko Bootloader with Silicon Labs wireless protocol stacks in GSDK 4.0 and higher.


AN1326: Transitioning to the Updated Gecko Bootloader in GSDK 4.0 and Higher -
Gecko Bootloader v2.x, introduced in GSDK 4.0, contains a number of changes compared to Gecko Bootloader v1.x. This document describes the differences between the versions, including how to configure the new Gecko Bootloader in Simplicity Studio 5.

AN1218: Series 2 Secure Boot with RTSL -
Contains detailed information on configuring and using the Secure Boot with hardware Root of Trust and Secure Loader on Series 2 devices, including how to provision the signing key. This is a companion document to UG489: Silicon Labs Gecko Bootloader User's Guide for GSDK 4.0 and Higher.

Multiprotocol

UG103.16: Multiprotocol Fundamentals -
Describes the four multiprotocol modes, discusses considerations when selecting protocols for multiprotocol implementations, and reviews the Radio Scheduler, a required component of a dynamic multiprotocol solution.

UG305: Dynamic Multiprotocol User's Guide -
Describes how to implement a dynamic multiprotocol solution.

Non-Volatile Data Storage

UG103.07: Non-Volatile Data Storage Fundamentals -
Introduces non-volatile data storage using flash and the three different storage implementations offered for Silicon Labs microcontrollers and SoCs: Simulated EEPROM, PS Store, and NVM3.

AN1135: Using Third Generation Non-Volatile Memory (NVM3) Data Storage -
Explains how NVM3 can be used as non-volatile data storage in various protocol implementations.


AN961: Bringing Up Custom Devices for the EFR32MG and EFR32FG Families -
Describes how to initialize a piece of custom hardware (a 'device') based on the EFR32MG and EFR32FG families so that it interfaces correctly with a network stack. The same procedures can be used to restore devices whose settings have been corrupted or erased.

AN1154: Using Tokens for Non-Volatile Data Storage -
Describes tokens and shows how to use them for non-volatile data storage in EmberZNet PRO and Silicon Labs Flex applications.

Security

UG103.05: IoT Endpoint Security Fundamentals -
Introduces the security concepts that must be considered when implementing an Internet of Things (IoT) system. Using the ioXt Alliance's eight security principles as a structure, it clearly delineates the solutions Silicon Labs provides to support endpoint security and what you must do outside of the Silicon Labs framework.

AN1190: Series 2 Secure Debug -
Describes how to lock and unlock the debug access of EFR32 Gecko Series 2 devices. Many aspects of the debug access, including the secure debug unlock are described. The Debug Challenge Interface (DCI) and Secure Engine (SE) Mailbox Interface for locking and unlocking debug access are also included.

AN1222: Production Programming of Series 2 Devices -
Provides details on programming, provisioning, and configuring Series 2 devices in production environments. Covers Secure Engine Subsystem of Series 2 devices, which runs easily upgradeable Secure Engine (SE) or Virtual Secure Engine (VSE) firmware.

AN1247: Anti-Tamper Protection Configuration and Use -
Shows how to program, provision, and configure the anti-tamper module on EFR32 Series 2 devices with Secure Vault.


AN1268: Authenticating Silicon Labs Devices using Device Certificates -
How to authenticate an EFR32 Series 2 device with Secure Vault, using secure device certificates and signatures.

AN1271: Secure Key Storage -
Explains how to securely "wrap" keys in EFR32 Series 2 devices with Secure Vault, so they can be stored in non-volatile storage.

AN1303: Programming Series 2 Devices Using the Debug Challenge Interface (DCI) and Serial Wire Debug (SWD) -
 Describes how to provision and configure Series 2 devices through the DCI and SWD.

AN1311: Integrating Crypto Functionality Using PSA Crypto Compared to Mbed TLS -
Describes how to integrate crypto functionality into applications using PSA Crypto compared to Mbed TLS.


Software Advisory for detailed information (registration required).

Gecko OS

Gecko OS is a highly-optimized yet feature-packed IoT operating system designed specifically to power Silicon Labs hardware platforms with secure wired and wireless networking capabilities.
With integrated support for firmware updates and cloud-connectivity, devices powered by Gecko OS can be seamlessly managed from the cloud with just a few clicks.
Gecko OS already supports various technologies offered by Silicon Labs including Wi-Fi and Bluetooth, with others in active development.

Gecko OS offers two consistent API options depending on where your application runs.
Applications that run on an external host microprocessor, or on a network connected device such as a smartphone, tablet or PC can use the Xpress Command API.
Whereas applications that run on Silicon Labs hardware can use the programmatic Gecko OS native 'C' API along with the Gecko OS Application SDK.

Editions

Standard License

Gecko OS 4

Wi-Fi and Ethernet with Command API and Application SDK

Wi-Fi, Ethernet

WGM160P

Xpress License

Gecko OS 2

Wi-Fi Xpress with Command API

Wi-Fi

AMW007, AMW037

Gecko OS 1

Bluetooth Xpress with Command API

Bluetooth

BGX13P, BGX13S

Legacy Editions

ZentriOS WZ

Zentri Wi-Fi portfolio with Command API and Application SDK

Wi-Fi

AMW106, AMW136

ZentriOS WL

Zentri Wi-Fi portfolio with Command API

Wi-Fi

AMW007, AMW037

ZentriOS W

Zentri Wi-Fi portfolio with Command API

Wi-Fi

AMW006, AMW036


General Overview

What is Bluetooth Xpress

Bluetooth Xpress (BGX) devices are pre-programmed modules that provide a host
microcontroller with a Bluetooth Low Energy (BLE) connection to another Bluetooth
Xpress module device or a smart phone. Bluetooth Xpress modules such as the BGX13P
and BGX13S modules are designed to substantially reduce
design effort and aid time-to-market in applications that require BLE connectivity
to other BLE capable devices.

A host microprocessor communicates with a Bluetooth Xpress module via a
serial interface. A host microcontroller can configure
the module and stream data to and from connected Bluetooth devices. Application
operation may be customized by setting individual configuration variables.

Bluetooth Xpress modules use the Xpress command API to enable host control, together
with variables to enable host configuration. Beyond commands
and variables, Bluetooth Xpress modules provide a rich feature set for
wireless and peripheral command and control.

Serial Interface

Bluetooth Xpress modules provide one of the easiest to use and flexible serial BLE
interfaces in the industry. The Xpress command API provides UART support,
different serial communications modes, including command mode and stream mode. The protocol
is easy to use for both humans and machines alike.

See Serial Interface.

Bluetooth Low Energy

Bluetooth Xpress modules provide an easy-to-use serial API allowing you to focus your
efforts on application development, rather than the time-consuming complexity
and interoperability issues associated with the development of a wireless
network stack.

Bluetooth Xpress modules support operating modules in Central and Peripheral roles.

See Commands and Variables.

I/O

Port control APIs are available to provide access to general purpose IO, inputs
to control Bluetooth Xpress operational state through pin conditions, and outputs designed
to signal BLE connection status with connected LEDs.

See GPIOs.

Security


See GPIOs.

Security

The primary BLE services provided by Bluetooth Xpress modules are always encrypted
for privacy. To use either the Xpress Streaming Service
or the OTA firmware update service, connecting devices will need to pair. BGX devices
may be configured to use either Just Works (unauthenticated) or Passkey (authenticated)
pairing methods. Support is provided for both LE Secure Connections and LE legacy pairing.

See Security.


Software Advisory for detailed information (registration required).

General Overview

Xpress Command API

AMW007 - Wi-Fi Module
            AMW037 - Wi-Fi Module with antenna

What is Gecko OS Edition 2?

Gecko OS is an IoT operating system that runs on Silicon Labs wireless and wired IoT connectivity modules. Gecko OS helps you build your wireless IoT app by shielding you from the complexity of hardware, protocols and standards, leaving you to focus on building a great IoT application. All Wireless Xpress products from Silicon Labs are powered by Gecko OS making use of the Gecko OS Command API.

Hardware running Gecko OS provides a product with a powerful and secure wireless connection to a mobile device or the cloud. Developers can build IoT Applications that communicate with Gecko OS using the extensive Wi-Fi Command API, via serial interface, HTTP REST or a remote terminal.

Command API

The Gecko OS 2 Command API is available for applications connecting with a wired serial interface, or a wireless interface using HTTP REST or Remote Terminal. The API provides direct access to peripherals connected to Gecko OS hardware via GPIO. For a quick start guide to using a Gecko OS evaluation board, see Getting Started.

Features and Interfaces

The Gecko OS 2 Command API offers a powerful set of commands for control of connected devices, together with a large number of variables for configuration.

A host MCU communicates with Gecko OS via a UART.

A mobile or desktop app communicates with Gecko OS via the HTTP Server RESTful API or by the local or remote terminal interface.

The local or remote host sends commands to control the operation of Gecko OS and to exchange data with other devices on the network.

A summary of Gecko OS 2 features and interfaces is outlined in the following sections.

Wi-Fi, Networking & Web

Multiple interfaces including serial, softAP and WLAN client

Concurrent operation of softAP and WLAN client

Servers: TCP, HTTP, DHCP, DNS


Concurrent operation of softAP and WLAN client

Servers: TCP, HTTP, DHCP, DNS

Clients: TCP/TLS, UDP, NTP, DHCP, DNS

HTTP Server with RESTful API

HTTP file upload/download

Fully-customizable mobile responsive web application

Remote terminal access

Multiple Wi-Fi setup options including Web setup with softAP

Peripherals & Sensors

GPIOs for control, indication and monitoring

Automated broadcast and streaming of sensor data

Local caching of sensor data

System

Wireless OTA (Over-the-Air) Update to remotely manage firmware using the

Failsafe bootloader and kernel with safemode operation

Configurable power states and sleep/wake timers

Read/Write file system

Storage of large files

All Gecko OS commands can be issued manually using human mode or under host control using machine mode. Human mode should only be used for evaluation and manual testing. Machine mode is strongly recommended for production.

For human mode, the interfaces are a Gecko OS Terminal, the Web App, or a remote terminal.

Getting Started

To start using your Gecko OS hardware in human mode, see Getting Started.

Web App

The Web App provides complete monitoring and control of your Gecko OS hardware using a web browser.

See Web App.

Serial Interface

Gecko OS provides one of the easiest to use and most flexible serial Wi-Fi networking interfaces in the industry. The Gecko OS serial interface provides support for multiple serial buses, different serial communications modes including command mode and stream mode, and is easily configured for use by humans and machines alike.

See Serial Interface.

Wi-Fi

Gecko OS provides an easy-to-use serial API allowing you to focus your efforts on application development, rather than the time-consuming complexity and interoperability issues associated with the development of a full-featured secure wireless network stack.


Two Wi-Fi interfaces are supported, including a Wi-Fi client (wlan) and Wi-Fi soft access point (softAP) interface. Each interface may be run independently or concurrently to suit various application needs.

See Wi-Fi Interface.

Networking and Security

Gecko OS includes a full IPv4 networking stack and SSL/TLS security suite that supports a range of popular networking protocols including TCP, UDP, DNS, DHCP. Additional network application libraries are provided for native HTTP/S and secure cloud access.

See Networking and Security.

Peripherals

Various peripheral APIs are available to provide access to general purpose IOs (GPIOs), analog functions such as analog-digital and digital-analog converters, and timers including a real time clock. Special system and network functions can be assigned to GPIOs to enable handy features including:

automatic LED status indicators to show the state of Wi-Fi and network connections;

an indication of when one or more network clients are connected to a local Gecko OS server; and

the ability to control the connection state of a client or server.

See Peripherals.

File System

Most connected applications require the ability to store configuration information or cache local data. Gecko OS provides a reliable read/write filesystem and on-board flash storage to satisfy application storage requirements. With just a few simple commands, Gecko OS provides your application with complete access to local and network connected storage.

See File System.

Memory

For management of Gecko OS device memory, see Memory.

Configuration and Setup

Several options are available to setup a module running Gecko OS. The most common option, and also the most convenient when prototyping is to use a command line and serial interface such as a UART. A PC terminal can be quickly connected to a Gecko OS evaluation board, and within 60 seconds it is possible to be connected to a Wi-Fi network and downloading HTTP webpages or connecting to a remote TCP server.

Other methods for configuration, setup and Wi-Fi provisioning include:


Other methods for configuration, setup and Wi-Fi provisioning include:

a softAP and webserver interface

an (optionally) password-secured remote terminal that provides command line convenience over one of the Gecko OS wireless network interfaces; and

automatic execution of a custom configuration script on boot-up

See Configuration and Setup.

System Functions

System functions include:

Configuring Gecko OS Command Mode and Response

Power management

Monitoring System State

Controlling the Boot Application

System Identification and Version

See System Functions.

Update and Recovery

Gecko OS is part of a larger sophisticated application framework installed on all Gecko OS devices. The framework provides a hardened bootloader, read/write file system, safemode recovery mechanism, and over-the-air (OTA) update capability.

Silabs manages a secure on-line OTA server that offers each Gecko OS device with the ability to securely update individual files, applications or an entire firmware bundle. In the rare event that Gecko OS fails to regularly execute correctly, the bootloader switches the boot application to safe mode. The safe mode application provides the host with the ability to update the firmware, switch back to Gecko OS or even factory reset the module.

See Update and Recovery.


Gecko OS Variables

Shortcuts

Documentation Format

List of Variables

Variable Properties

This page provides a list of Gecko OS variables with a full description of the function of each variable together with example usage.

Variables are cached in volatile RAM and must be saved to non-volatile flash memory to persist between reboots. To save variables to flash, use the save command. Some variables impact the operation of the entire system, wake and sleep timers for example. A save and reboot is required before new settings for these types of variables take effect.

Variable settings can be loaded using the load command.

The get and set Command API functions are used to read and write Gecko OS variables respectively.

Shortcuts

A shortcut is assigned to each variable. The format for shortcuts is shown in the following table. The shortcut is a hybrid of the first two characters of the first word of the variable name, plus (typically) the first character of the second word (if a second word exists), plus (typically) the first character of the third word of the variable name (if a third word exists). Each of these characters is separated by a space character. In some instances, it was not possible to use the first letter of the second or third word in the variable name, in these cases another letter has been somewhat arbitrarily chosen.

Template

first_word.second_word.third_word

fi s t

Example 1

time.uptime

ti u

Example 2

wlan.scan.retries

wl s r

Documentation Format

Many Gecko OS responses shown in the examples on this page were captured with system.print_level = 0, and system.cmd.header_enabled = 1. These machine friendly settings make it easy for a host MCU to parse responses by examining response headers.
Documentation for each variable is provided in the format shown below.

variable

Abbreviation

var

Access

get/set

Description

A description of the function of the variable.

Arguments


var

Access

get/set

Description

A description of the function of the variable.

Arguments

A full list of mandatory and optional arguments.

Default

The factory reset default value.

Get example

An example of how to read the variable, including response codes.

Set example

An example of how to write the variable, including response codes (for writeable variables).

NOTE! Don't forget to check out command navigation tips to make it easier to find and type specific variable names.

List of Variables

All Variables
all

Broadcast
broadcast.databroadcast.http.hostbroadcast.interfacebroadcast.intervalbroadcast.udp.ipbroadcast.udp.remote_port

Bus
bus.modebus.stream.cmd_gpiobus.stream.cmd_seqbus.stream.flush_countbus.stream.flush_timebus.stream.flush_time_reset

DMS
dms.bundle_id

GPIO
gpio.initgpio.usage

Host Boot
hboot.filenamehboot.gpio

HTTP Server
http.server.api_enabledhttp.server.cors_originhttp.server.enabledhttp.server.interfacehttp.server.max_clientshttp.server.notfound_filenamehttp.server.porthttp.server.root_filename

IO Connection
ioconn.control_gpioioconn.enabledioconn.local_portioconn.protocolioconn.remote_hostioconn.remote_portioconn.status_gpio

Network
network.default_interfacenetwork.tls.ca_certnetwork.tls.client_certnetwork.tls.client_keynetwork.tls.handshake_timeoutnetwork.tls.version

NTP
ntp.enabledntp.interfacentp.intervalntp.server

Remote Terminal
remote_terminal.enabledremote_terminal.interfaceremote_terminal.passwordremote_terminal.portremote_terminal.timeout

Setup
setup.gpio.control_gpiosetup.web.idle_timeoutsetup.web.passkeysetup.web.root_filenamesetup.web.ssidsetup.web.url


SoftAP Interface
softap.auto_startsoftap.captive_portal_enabledsoftap.channelsoftap.client_listsoftap.dhcp_server.enabledsoftap.dns_server.enabledsoftap.dns_server.urlsoftap.hide_ssidsoftap.idle_timeoutsoftap.infosoftap.max_clientssoftap.passkeysoftap.ssidsoftap.static.gatewaysoftap.static.ipsoftap.static.netmask

Stream
stream.auto_close

System
system.build_numbersystem.cmd.bufferedsystem.cmd.echosystem.cmd.formatsystem.cmd.header_enabledsystem.cmd.prompt_enabledsystem.gotosleep.timeoutsystem.indicator.gpiosystem.indicator.statesystem.memory.usagesystem.oob.event_masksystem.oob.gpiosystem.oob.gpio_levelsystem.oob.rising_edge_masksystem.oob.statussystem.print_levelsystem.safemode.disabledsystem.safemode.statussystem.uuidsystem.versionsystem.wakeup.timeout

TCP Client
tcp.client.auto_interfacetcp.client.auto_retriestcp.client.auto_starttcp.client.connect_timeouttcp.client.connected_strtcp.client.disconnected_strtcp.client.local_porttcp.client.remote_hosttcp.client.remote_porttcp.client.retriestcp.client.retry_periodtcp.client.tls_enabled

TCP Keepalive
tcp.keepalive.enabledtcp.keepalive.initial_timeouttcp.keepalive.retry_counttcp.keepalive.retry_timeout

TCP Server
tcp.server.auto_interfacetcp.server.auto_starttcp.server.connected_gpiotcp.server.data_gpiotcp.server.idle_timeouttcp.server.port

Time
time.last_settime.rtctime.uptimetime.zone

UART
uart.bauduart.datauart.flowuart.parityuart.stop

UDP Client
udp.client.auto_interfaceudp.client.auto_startudp.client.remote_hostudp.client.remote_port

UDP Server
udp.server.auto_interfaceudp.server.auto_startudp.server.data_gpioudp.server.lock_clientudp.server.portudp.server.remote_hostudp.server.remote_port


WLAN Interface
wlan.auto_join.enabledwlan.auto_join.retrieswlan.auto_join.retry_delaywlan.dhcp.enabledwlan.dhcp.hostnamewlan.hide_passkeywlan.infowlan.join.retrieswlan.join.timeoutwlan.macwlan.network.dnswlan.network.gatewaywlan.network.ipwlan.network.netmaskwlan.network.statuswlan.passkeywlan.rate.protocolwlan.ssidwlan.static.dnswlan.static.gatewaywlan.static.ipwlan.static.netmaskwlan.tx_power

Variable Properties

The table below indicates properties of variables:

When a change in variable value takes effect:
Immediate - a change in the variable value takes effect immediatelyUART Update - run the uart_update command to apply a change in the variable valueNetwork Restart - restart the network to apply a change in the variable valueSetup Restart - restart the web setup to apply a change in the variable valueSave and Reboot - a save and reboot is required to apply a change in the variable value

Safe Mode - variable is available in safe mode

Fac Persist - variable persists through factory reset

broadcast.data

Immediate

broadcast.http.host

Immediate

broadcast.interface

Save and Reboot

broadcast.interval

Save and Reboot

broadcast.udp.ip

Immediate

bus.mode

Save and Reboot

Safe Mode

NVM Backup

Lockable

bus.stream.cmd_gpio

Save and Reboot

bus.stream.cmd_seq

Save and Reboot

bus.stream.flush_count

Save and Reboot

bus.stream.flush_time

Save and Reboot

bus.stream.flush_time_reset

Save and Reboot

gpio.init

Save and Reboot

http.server.api_enabled

Network Restart

http.server.cors_origin

Network Restart

http.server.enabled

Network Restart

http.server.interface

Network Restart

http.server.max_clients

Network Restart

http.server.notfound_filename

Network Restart

http.server.port

Network Restart

http.server.root_filename

Network Restart


Network Restart

http.server.port

Network Restart

http.server.root_filename

Network Restart

ioconn.control_gpio

Save and Reboot

ioconn.enabled

Save and Reboot

ioconn.local_port

Immediate

ioconn.protocol

Immediate

ioconn.remote_host

Immediate

ioconn.remote_port

Immediate

ioconn.status_gpio

Save and Reboot

network.default_interface

Immediate

network.tls.ca_cert

Immediate

Safe Mode

network.tls.client_cert

Immediate

network.tls.client_key

Immediate

network.tls.version

Immediate

ntp.enabled

Save and Reboot

ntp.interface

Save and Reboot

ntp.interval

Save and Reboot

ntp.server

Save and Reboot

remote_terminal.enabled

Network Restart

remote_terminal.interface

Network Restart

remote_terminal.password

Immediate

remote_terminal.port

Network Restart

remote_terminal.timeout

Immediate

setup.gpio.control_gpio

Save and Reboot

setup.web.idle_timeout

Setup Restart

setup.web.passkey

Setup Restart

setup.web.root_filename

Setup Restart

setup.web.ssid

Setup Restart

setup.web.url

Setup Restart

softap.auto_start

Network Restart

softap.channel

Network Restart

softap.dhcp_server.enabled

Network Restart

softap.dns_server.enabled

Network Restart

softap.dns_server.url

Network Restart

softap.hide_ssid

Network Restart

softap.idle_timeout

Network Restart

softap.max_clients

Immediate

softap.passkey

Network Restart

softap.ssid

Network Restart

softap.static.gateway

Network Restart

softap.static.ip

Network Restart

softap.static.netmask

Network Restart

stream.auto_close

Immediate

system.cmd.buffered

Immediate

Safe Mode

NVM Backup

system.cmd.echo

Immediate

Safe Mode

NVM Backup

system.cmd.header_enabled

Immediate

Safe Mode

NVM Backup

system.cmd.prompt_enabled

Immediate

Safe Mode


Immediate

Safe Mode

NVM Backup

system.cmd.prompt_enabled

Immediate

Safe Mode

NVM Backup

system.gotosleep.timeout

Save and Reboot

system.indicator.gpio

Save and Reboot

system.indicator.state

Save and Reboot

system.oob.event_mask

Immediate

system.oob.gpio

Save and Reboot

system.oob.gpio_level

Immediate

system.oob.rising_edge_mask

Immediate

system.print_level

Immediate

Safe Mode

NVM Backup

system.safemode.disabled

Save and Reboot

Safe Mode

system.safemode.status

Safe Mode

system.uuid

Safe Mode

system.version

Safe Mode

system.wakeup.timeout

Immediate

tcp.client.auto_interface

Save and Reboot

tcp.client.auto_retries

Save and Reboot

tcp.client.auto_start

Save and Reboot

tcp.client.connect_timeout

Immediate

Safe Mode

NVM Backup

tcp.client.local_port

Immediate

Safe Mode

NVM Backup

tcp.client.remote_host

Immediate

tcp.client.remote_port

Immediate

tcp.client.retries

Immediate

Safe Mode

NVM Backup

tcp.client.retry_period

Immediate

Safe Mode

NVM Backup

tcp.client.tls_enabled

Immediate

tcp.keepalive.enabled

Immediate

NVM Backup

tcp.keepalive.initial_timeout

Immediate

NVM Backup

tcp.keepalive.retry_count

Immediate

NVM Backup

tcp.keepalive.retry_timeout

Immediate

NVM Backup

tcp.server.auto_interface

Network Restart

tcp.server.auto_start

Network Restart

tcp.server.connected_gpio

Network Restart

tcp.server.data_gpio

Network Restart

tcp.server.idle_timeout

Network Restart

tcp.server.port

Network Restart

time.rtc

Immediate

time.zone

Immediate

uart.baud

UART Update

Save and Reboot

Safe Mode

NVM Backup

Lockable

uart.data

UART Update

Save and Reboot

Safe Mode


NVM Backup

Lockable

uart.data

UART Update

Save and Reboot

Safe Mode

NVM Backup

Lockable

uart.flow

UART Update

Save and Reboot

Safe Mode

NVM Backup

Lockable

uart.parity

UART Update

Save and Reboot

Safe Mode

NVM Backup

Lockable

uart.stop

UART Update

Save and Reboot

Safe Mode

NVM Backup

Lockable

udp.client.auto_interface

Network Restart

udp.client.auto_start

Network Restart

udp.client.remote_host

Immediate

udp.client.remote_port

Immediate

udp.server.auto_interface

Network Restart

udp.server.auto_start

Network Restart

udp.server.data_gpio

Network Restart

udp.server.lock_client

Network Restart

udp.server.port

Network Restart

udp.server.remote_host

Network Restart

udp.server.remote_port

Network Restart

wlan.auto_join.enabled

Network Restart

wlan.auto_join.retries

Save and Reboot

wlan.auto_join.retry_delay

Save and Reboot

wlan.dhcp.enabled

Network Restart

Safe Mode

NVM Backup

wlan.dhcp.hostname

Network Restart

wlan.hide_passkey

Immediate

Safe Mode

NVM Backup

wlan.join.retries

Network Restart

Safe Mode

NVM Backup

wlan.join.timeout

Save and Reboot

Safe Mode

NVM Backup

wlan.mac

Safe Mode

wlan.network.dns

Safe Mode

wlan.network.gateway

Safe Mode

wlan.network.ip

Safe Mode

wlan.network.netmask

Safe Mode

wlan.network.status

Safe Mode

wlan.passkey

Network Restart

Safe Mode

NVM Backup

wlan.rate.protocol

Network Restart

Safe Mode

NVM Backup

wlan.ssid

Network Restart

Safe Mode

NVM Backup

wlan.static.dns

Network Restart

Safe Mode

NVM Backup

wlan.static.gateway

Network Restart


Network Restart

Safe Mode

NVM Backup

wlan.static.gateway

Network Restart

Safe Mode

NVM Backup

wlan.static.ip

Network Restart

Safe Mode

NVM Backup

wlan.static.netmask

Network Restart

Safe Mode

NVM Backup

wlan.tx_power

Immediate

Safe Mode

NVM Backup


Gecko OS 2.3 Hardware Support

Overview

Silabs provides software and tools for building connected products, from silicon to cloud.

Gecko OS is the operating system that allows rapid building of complex connected products.

Silabs provides platforms that run Gecko OS. Platforms include modules and evaluation boards.

For each hardware item below, the documentation includes links for product details and purchasing information.

Platforms

A platform is the basis of Gecko OS connectivity device. Gecko OS runs on a number of platforms.

A platform is a configuration of hardware capable of running Gecko OS. A platform runs a version of Gecko OS compiled specifically for that platform. A product is compiled for one or more platforms. The Silabs Device Management Server (DMS) classifies products by the platforms on which they can run.  The Gecko OS SDK detects the device platform.

Where procedures and features vary, depending on the platform, the details are noted throughout the documentation.

Where a configuration consists of subcomponents, a platform is the smallest Gecko OS-capable component that can be obtained separately. For example, a Gecko OS AMW106-E03 evaluation board contains a Gecko OS AMW106 module. The platform is the Gecko OS AMW106 module. In the case of the NXP-SCCK, no smaller module is available, and the platform is the NXP-SCCK evaluation board.

Wi-Fi Modules

Silabs

AMW007

Spectre

Wi-Fi module

Gecko OS-AMW007

Silabs

AMW037

Spectre 037

Wi-Fi module

Gecko OS-AMW007


You are viewing documentation for version: 4.2 (latest) | Version History

Gecko Platform

Gecko Platform is the common foundation for the Gecko SDK Suite.

Gecko Platform Components

EMLIB Peripheral Library

Common Utilities

Drivers

Services

Machine Learning

Middleware

Development Board APIs

External Device Drivers

Micrium OS

RAIL Library

Third-Party Libraries

ARM CMSIS

ARM mbed TLS


You are viewing documentation for version: 4.2 (latest) | Version History

Platform Drivers

Platform drivers is a set of function specific high performance drivers for
 EFM32, EZR32 and EFR32 on-chip peripherals. Drivers are typically DMA or
 interrupt based and are using all available low-energy features. For most
 drivers, the API offers both synchronous and asynchronous functions.

Most drivers are compile-time configurable to allow the highest possible
 code size optimization for the application. Compile-time configuration is
 defined in *_config.h files. Templates for the configuration files can be
 found in the config for each driver. When adding a driver using the Project
 Configurator in Simplicity Studio, the config files are automatically added
 to the project.

Plaform drivers are located in either the platform/driver or platform/emdrv
 folders. Drivers in platform/driver use error codes defined in
 sl_status.h, while emdrv drivers use error
 codes defined in ecode.h.


You are viewing documentation for version: 4.2 (latest) | Version History

Board APIs

The board APIs controls features specific to the Silicon Labs kit boards, like GPIO controlled power to external sensors. The board control API consists of both runtime functions to control the state and compile time configuration done through config headers which are editable by the user. During device initialization the configuration header settings are then applied by the board component itself.

Board Configuration Headers

The hardware/board/config subdirectory contains copies of configuration headers for miscellaneous drivers from the entire SDK. These configuration headers are tailored for the specific board, ensuring correct settings for pinout and other board-specific properties. The board-specific configuration headers override the default configuration header for the driver whenever the board is selected as a component in the SLC project.
All configuration headers are copied to the config/ directory of the project during SLC project generation. If a custom configuration is required, the configuration header in the project config/ directory can be further modified to fit application needs.
If developing for production hardware, you can start the project using a development board, and later change the target board to "Custom Board". In Simplicity Studio, this will show a prompt of whether to keep or overwrite the existing configuration file. If "keep my file" is selected, the board configuration settings from the development board are kept.

Note : The configuration must be modified on the copied board configuration headers in the generated project, under path config/ and not in the original SDK.

Thunderboard Sense 2 (BRD4166A) Support

Thunderboard Sense 2 has several I2C buses connected to the various sensors that are all connected to the EFR32. The BRD4166A support component provides functions to route pin connections of an I2C peripheral to the various I2C buses. This allows time multiplexed access to several I2C buses using only one I2C peripheral.


You are viewing documentation for version: 4.2 (latest) | Version History

External Device Drivers

The external device driver APIs enable using devices that are external to the EFR32/EFM32, such as sensors, displays, and external memory. While the drivers support external devices on the Silicon Labs kits, the drivers are board agnostic and can be used with other boards that include the same devices.