In summary, both modes leverage Bluetooth Low Energy (BLE) and make use of the Generic Attribute Profile (GATT) protocol, a communication framework that sets standardized rules for how two – or more – devices connect, interact, and exchange data. For example, it structures data into services, each with specific, defined characteristics. Simply put: "Reliability" Mode prioritizes secure, error-free data transfer, while "Speed" Mode emphasizes fast, real-time performance, allowing you to choose the best fit for your application needs.

Reliability Mode: Uses Write with Response, where each packet is acknowledged to ensure reliable and accurate data transfer. Ideal for critical updates like firmware upgrades, it prioritizes data integrity over speed, making it suitable for scenarios where errors are unacceptable.

Speed Mode: Uses Write Without Response instead, resulting in faster data transfer by skipping acknowledgments. While it does not guarantee delivery, it is preferred for non-critical updates, such as sensor data or telemetry, where speed is more important than reliability.

No, it is not possible to change the default UART pin mapping and assignment of RX, TX, RTS, and CTS pins, as they are hardcoded in the source code of our AT interface solution; however, that being said, if you require a different setup or, for example, cannot implement the standard configuration, please contact your local sales representative or FAE. We would be happy to discuss this further and explore a customized solution tailored to your application needs. Don’t hesitate to reach out — just ask!

Download + Install via Google Play and Apple App Store:

Android: https://play.google.com/store/apps/details?id=com.siliconlabs.bledemo
iOS: https://apps.apple.com/us/app/simplicity-connect/id1030932759

Access, Review, and Edit Source Code on GitHub:

Android: https://github.com/SiliconLabs/SimplicityConnect-android
iOS: https://github.com/SiliconLabs/SimplicityConnect-ios

Copyright 2021 Silicon Laboratories
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.


The EFR Connect app has been rebranded as Simplicity Connect (or Si Connect for short) with the release of version 2.9.0 for both Android and iOS in September 2024. This update reflects the app’s evolution beyond Bluetooth Low Energy (BLE) to also include support for Wi-Fi and Matter protocols. The rebranding aligns the app with Silicon Labs' Simplicity Studio 5, creating a unified tool for developers who are working with multiple wireless technologies. Simplicity Connect retains *all* the features of EFR Connect while introducing new functionality to support the expanded protocols, making it even more versatile and easier to use.

No, neither the Lyra (22) nor the Lyra 24 series have been certified for AEC-Q100, and there are no plans to do so in the near future. 

AEC-Q100 is a qualification standard for integrated circuits (ICs) used in automotive applications, developed by the Automotive Electronics Council (AEC). It defines the testing and performance requirements that electronic components must meet to ensure their robustness in harsh automotive environments. This includes factors like extreme temperatures, vibrations, and long-term usage.

In summary, this specification covers and defines the following three grades: Grade 1 supports temperatures from -40°C to +125°C and is used in critical systems like engine control units and airbags; Grade 2 supports -40°C to +105°C for less demanding applications; and Grade 3 supports -40°C to +85°C, typically for non-critical automotive or other applications. Please refer here for additional information.

Secure Vault is Silicon Labs' security solution integrated into their 32-bit microcontrollers to protect devices from a wide range of security threats once deployed in the field. By assigning each device a unique digital fingerprint, Secure Vault ensures the secure management of cryptographic keys. It also prevents unauthorized firmware from running by verifying that only authenticated code is executed during the boot process. Additionally, Secure Vault offers protection against physical tampering, restricts access to debug ports, and defends against side-channel attacks, such as those targeting power consumption patterns … and much more!

By default, three different security levels are available: Base (SVB), Mid (SVM), and High (SVH), allowing you to choose the right level of protection that best suits your application and device needs. The Lyra (22) series is equipped with Secure Vault "Mid" for robust security, while the 24 series provides maximum protection with Secure Vault "High". For more information and a detailed comparison of these security levels, please visit https://www.silabs.com/security.

NFC (Near Field Communication) allows devices to communicate wirelessly when positioned in close proximity, usually within a few centimetres. One device creates a small magnetic field that powers the other, enabling them to transfer data. This short-range setup is secure, making NFC ideal for tasks like contactless payments, access control, and quick data transfers. Unfortunately, neither the Lyra (22) nor the Lyra 24 series support NFC right out of the box; both are designed as Bluetooth Low Energy 5 (BLE)-only solutions.

The reason for this is primarily because Silicon Labs does not natively support NFC, as they lack built-in NFC hardware. Instead, NFC functionality, when needed, is typically achieved by interfacing with external components. In this case, developers often integrate other NFC modules or chips alongside the EFR32 to enable the desired features. Silicon Labs offers NFC libraries (https://github.com/SiliconLabs/nfc) and examples to help incorporate NFC capabilities, such as with the NXP NT3H2111, for example: https://github.com/SiliconLabs/bluetooth_applications/tree/master/bluetooth_nfc_pairing.

No, only the Normal Mode is available for both the Lyra (22) and Lyra 24 series. The Incremental Analog-to-Digital Converter (IADC) from Silicon Labs is a feature in their EFR32-based microcontrollers that converts analog signals to digital data, offering up to three different sampling modes, depending on the chip version: Normal Mode for balanced performance and typical use, High-Speed Mode for faster sampling rates, useful for quick data collection, and High-Accuracy Mode for precise readings, ideal when accuracy is critical. These three modes are helpful and allow developers to adjust the device’s performance according to their unique application needs.

No, the Backup Real Time Counter (BURTC) is not available in either the Lyra (22) or Lyra 24 series, both in terms of software and hardware. The BURTC is a timer that supports timekeeping across all energy modes, including EM4, with a total current consumption of less than 0.5 μA. It includes a 32-bit counter and can be clocked by a 32.768 kHz crystal oscillator, a 32.768 kHz RC oscillator, or a 2 kHz ultra-low-frequency RC oscillator.

Our Lyra series includes two main versions: Lyra 22 and Lyra 24. Lyra 22 is based on the EFR32BG22 SoC, whereas Lyra 24 uses the EFR32BG24 SoC from Silicon Labs. Both are built and featuring the Wireless Gecko Series 2. This naming scheme helps distinguish between the two series and their parts.

Please keep in mind that Lyra and Lyra 22 are the same and refer to the identical version. There is no difference between Lyra or Lyra 22 (and vice versa). Typically, when we mention or just say Lyra, we mean Lyra 22, unless otherwise specified, as it was the first hardware generation we released.

First Lyra Generation = Lyra aka. Lyra 22: https://www.ezurio.com/lyra-series.
Second Lyra Generation = Lyra 24: https://www.ezurio.com/lyra24-series.

When a GitHub release is created, it automatically zips up any source that is in that repo. However, we do not provide the source code for our firmware, as it is proprietary. We just use the repo to provide our releases which are only available as binaries. This is why the source archives will be empty. 

Ezurio did provide breakout boards for our older BL600(EOL) modules but we do not produce breakout boards for any of our current range of Bluetooth modules as of 2024.

This includes all BL65x, BL53xx, BL54xxx, BTxxx, Vela and Lyra modules.

We do provide development kits for all of our module offerings. To learn more, visit any product page on ezurio.com. 

Before contacting our support team, please follow the below mentioned steps for troubleshooting the connection between your Lyra development board and PC.

Hardware: Inspect the Lyra development board visually for any mechanical or physical damage. Try a different USB port on your PC and use the supplied micro USB cable. Also, verify that the SEGGER J-Link LED (in the bottom-right corner) is active when powered. If you own another DVK or got a spare board somewhere, then please connect it for validation and cross-checks to see if it works or not with the same setup.

Software: In Simplicity Studio 5, go to "Help" -> "Update Software" and apply all available updates if prompted. Check that both Simplicity Studio 5 installation and Silicon Labs Gecko SDK (GSDK) are up to date. Also, try to start Simplicity Studio 5 as an Administrator for testing reasons only. Make sure that your local firewall or antivirus program is not blocking any traffic / access. Install the latest version of the J-Link Software and Documentation Pack manually.

The Silicon Labs Proprietary Flex SDK is a complete software development suite for proprietary wireless applications. Per its namesake, Flex offers two software implementation options and paths:

• RAIL (Radio Abstraction Interface Layer) is an intuitive and easy customizable radio interface layer designed to support both proprietary and standards-based wireless protocols. It simplifies and accelerates the development process. This is the lowest layer available for all networking stacks in the Bluetooth Gecko SDK (GSDK).
• Connect is an IEEE 802.15.4-based networking stack designed for customizable broad-based proprietary wireless networking solutions that require low power consumption and operates in either the sub-GHz or 2.4 GHz frequency bands. This solution is targeted towards simple network topologies.

No. Unfortunately, we do not provide any support for a Remote Command Mode in our own AT Interface application at the moment which would e.g. allow AT commands to be sent, received, and processed over a BLE link (via GATT) – between two Lyra devices – for remote configuration reasons.

Yes. This feature is already on our Lyra (22) and 24 software roadmap. We’ve received many requests from different customers in the past asking us this question. The plan is to make it available in conjunction with both existing VSP (Virtual Serial Port) and non-VSP modes. See also our Lyra (22) and 24 Series – AT Interface Application User Guide for further details. We will provide more information on this topic once the implementation has been fully evaluated and finalized.

Yes, it is possible. You can for example downgrade in Simplicity Studio 5 from the Bluetooth Gecko SDK (GSDK) version 4.4.0 to 4.2.1 at any time. Refer to https://www.silabs.com/developers/gecko-software-development-kit for the latest release notes documents.

First, launch Simplicity Studio 5 and go to the Welcome / Launcher page if necessary. Next make sure that you are logged in with your Silicon Labs account – otherwise please apply and register under https://www.silabs.com. Now open the "Install" window which by default can be located in the upper-left corner of the submenu.

Go to "SDKs" and search for "Gecko SDK - 32-bit and Wireless MCUs". Click on the three dots (...) right next to the current installed version number shown and select "Change Version". Confirm your choice and GSDK release by pressing the "Finish" button. This process may take a few minutes to complete.

Yes, indeed we do. Similar like with other Silicon Labs based devices which you may have worked before already. Currently, all below mentioned RM126x and Lyra (22) + 24 development boards are automatically recognized and added to the “Debug Adapters” list once you connect them to your PC. They are displayed and found on the (Welcome) Launcher page within Simplicity Studio 5 – as usual. Simply speaking: This would be the starting point if you want to develop custom LoRaWAN / BLE applications in C when using our modules.

RM126x Series

• Ezurio RM1261 Development Kit (BRD2900A Rev A00),
• Ezurio RM1262 Development Kit (BRD2901A Rev A00).
  
  

Lyra 24 Series

• Ezurio Lyra 24P 10dBm (Built-in) Ant Development Kit (BRD2902A Rev A00),
• Ezurio Lyra 24P 20dBm (Built-in) Ant Development Kit (BRD2904A Rev A00),
• Ezurio Lyra 24P 20dBm (RF) Pin Development Kit (BRD2903A Rev A00),
• Ezurio Lyra 24S 10dBm Development Kit (BRD2905A Rev A00).
  
  

Lyra (22) Series

• Ezurio Lyra P Development Kit (BRD4330A Rev A00),
• Ezurio Lyra S Development Kit (BRD4331A Rev A00).

The Lyra (22) series was introduced as a 100% software functional replacement for both BGX220 and BGX13 parts. We do support running the latest available Wireless Xpress v1.3.2XXX.X on it. Please find here the official Wireless Xpress release notes document.

From a pure hardware perspective, the BGX13 is not pin-to-pin compatible whereas the BGX220 is (except for the BOOT pin). See also: What is the difference between the Ezurio and legacy Bluetooth Xpress (BGX) bootloader you provide for Lyra? 

Please make sure to carefully review our latest Lyra Series – Bluetooth Xpress (BGX) Migration Guide when migrating from a BGX-based module.

Both ATE1 and ATE0 commands are pretty common in the modem world which would turn on and off the echo mode. In this case, any typed character(s) will be displayed to the screen or terminal – otherwise they are completely suppressed. This behaviour can be very useful for debugging or in some applications. However, there is currently no support for any echoing in our own AT Interface app and implementation. We recommend (if possible) to use a terminal application as an alternative such as UwTerminalX. In PuTTY, Tera Term or RealTerm this can be configured and enabled if needed.

Yes. User functions are available for both Lyra (22) and 24 series. In this case, please verify and make sure that you run a recent version of our AT Interface app such as >= GA2 for Lyra (22) and >= GA1 for Lyra 24 on your module.

They can be used to trigger a specific behaviour when a module event occurs. For example, you can toggle a GPIO when establishing a BLE connection, remove bonding information on disconnect, change TX power or the BLE device appearance, modify scan and advertising intervals, and a lot more – with less work and logic to be handled by an external MCU.

In the past, initial support for user functions was added to allow customers migrating from Wireless Xpress (and a BGX-based design) to our AT Interface application more easily. User functions can be used in conjunction with the AT+UFU and AT+SIOC commands. Refer to our latest Lyra Series – AT Interface Application User Guide and Lyra Series – Peripheral Interface Application Note for more details and examples. The usage of user functions is optional and disabled (not active) by default.

Please consider the following: Currently, only one AT command can be associated with each user function. Supported are SIO (Signal Input/Output) and BLE connection events as well as the boot event which gets triggered each time after resetting or rebooting the Lyra module. The number of user functions is limited, and not more than 320 bytes of total storage can be reserved for all AT command parameters.

No. It is not possible to use any of our Lyra (22) or 24 development boards for such task(s). This is not supported by the hardware. In this case, please refer to Which out of the box hardware can be used to externally debug and flash Lyra modules via the Serial Wire Debug (SWD) interface in development and production stage? for further information.

In order to debug and program our Lyra (22) and 24 modules externally via the Serial Wire Debug (SWD) interface in development or production stage, we recommend using the Simplicity Link Debugger (BRD1015A) board for example or any SLWSTK* part number which is listed under https://www.silabs.com/development-tools (Starter Kits) that comes with an onboard SEGGER J-Link debugger and debug out functionality.

Of course, it is also possible to use a debug probe from SEGGER directly or any other SEGGER compatible hardware with no vendor lock which does support EFR32BG22* and EFR32BG24* target devices / SoCs. See https://www.segger.com/supported-devices/silicon-labs/blue-gecko for more details and an overview.

Yes. For Lyra, the below command can be used to merge an existing bootloader and application hex file into a single hex image with the help of the Simplicity Commander CLI. See also: What is the „Simplicity Commander“ and where can I get it from?

Syntax: C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\commander\commander.exe convert <BOOTLOADER-IMAGE>.hex <APPLICATION-IMAGE>.hex -o <COMBINED-IMAGE>.hex

Example: C:\SiliconLabs\SimplicityStudio\v5\developer\adapter_packs\commander\commander.exe convert LYRA-P_Bootloader_480-00184-R126.1.0.3.hex LYRA-P_Bluetooth_Xpress.hex -o combined.hex

The Simplicity Commander is a utility that provides a graphical user interface (GUI) and command line interfaces (CLI) to the debug features of an EFR32-based device. We highly recommend using it in conjunction with our Lyra (22) and 24 series. It for example allows you to reprogram the Lyra module, update development board firmware, and lock, or unlock debug access if needed. This tool is part of the Simplicity Studio 5 Software & IDE by default. A portable version for Windows, GNU/Linux and macOS can also be found at https://www.silabs.com/developers/simplicity-studio#commander.

Silicon Labs provides a Wireless Direct Test Mode (DTM) application that can programmed onto a Lyra module that allows for DTM commands to be completed wirelessly from another device such as a mobile phone using EFR Connect Mobile app.

There is an existing page (Implementing Wireless Direct Test Mode (DTM)) in the Silicon Labs Bluetooth Docs that explains operation and provides source to be added to a Simplicity Studio project. However, at the time of the writing of this FAQ the source is based on much older Simplicity Studio 4 and doesn’t build properly with Simplicity Studio 5. An updated Wireless DTM application is available on the following Silicon Labs GIT page and source provided will build using Simplicity Studio 5.

Bluetooth Wireless DTM

An application is created in Simplicity Studio IDE based on Bluetooth_soc_empty application. The existing app.c file is replaced with app.c provided from the src folder in Bluetooth Wireless DTM. GATT table configuration is also made available in the config folder in Bluetooth Wireless DTM.

With the Wireless DTM application loaded and programmed the Lyra module will begin advertising and show as dtm_test. 

Once connected to Lyra dtm_test you can see the GATT Services; DTM Control, DTM RX and DTM TX. Note the services will not be presented as shown below. You will need to determine each service based on UUID which is shown on Bluetooth Wireless DTM but also provided below for demonstration.

Expanding on the DTM Control Service the characteristics for that service can be observed. Each characteristic is written to configure the test as detailed at in Bluetooth Wireless DTM.

Further command and command argument information can be found on the Testing Commands page.

Many thanks for your interest in our products. The Ezurio AT Interface implementation for both Lyra (22) and 24 series is closed source and proprietary, hence, we do not share any source code. This also applies to Wireless Xpress which was developed and released by Silicon Labs.

There are currently no plans to make any source files available to the public nor to open source our software projects on GitHub. For more details or individual requests, please reach out to your local sales representative or FAE at Laird.

In general, please be advised that the Wireless Xpress software solution from Silicon Labs is frozen at its current release and therefore will not receive any further development or bug fixing in the future.

However, if you've found a bug, have a feature request, or would like to send us feedback, please feel free to get in touch with our team under https://www.lairdconnect.com/resources/support by opening a support ticket. You can also send us an email via support@lairdconnect.com. We are always happy to assist.

In this case, please provide and share with us as much information as possible. This will help us to better understand customer needs and expectations, but also gives us the opportunity to improve with our next-gen products. Thank you.

Unfortunately, no. You cannot run Wireless Xpress on Lyra 24. There is no software and hardware support for it, and as now (2024) we have no plans to port, develop and/or release a compatible version for this hardware platform.

In you are migrating from a BGX-based device such as the BGX13 or BGX220, please feel free to investigate and review our Lyra (22) Series under https://www.lairdconnect.com/lyra-series in case you would like to continue using Wireless Xpress in your current design – but with one of our BLE modules as an alternative.

Also, please be advised that the Wireless Xpress software solution from Silicon Labs is frozen at its current release and therefore will not receive any further development or bug fixing in the future.

All Lyra development boards are by default in a floating state and use an "auto" configuration for the virtual COM Port (VCOM); therefore, it is highly recommended to do so whenever possible. In this case, please refer here for instructions and more details on how to set up UART hardware flow control (RTS/CTS) properly with your Lyra hardware for evaluation.

Yes. It is possible to enable and disable UART hardware flow control on your Lyra development board through Simplicity Studio 5 by modifying the Virtual COM Port (VCOM) settings. This for example can be helpful in cases where you would like to perform reference tests with or without having UART hardware flow control in place.

In Simplicity Studio 5 go to the Launcher page in the Debug Adapters view and right click on your Ezurio | Lyra Development Kit (ID:XXXXXXXXX). Select Launch Console and open the Admin tab. Now type "serial vcom config handshake rtscts" to enable or "serial vcom config handshake disable" for disabling UART hardware flow control.

Please make sure to reset or power cycle your Lyra development board once the settings have been applied. The default settings can be restored with the "serial vcom config handshake auto" command at any time.

As per the AT Interface User Guide, the AT+LSCN has four parameters, all of which are optional: timeout, escape pattern, rssi, and scan type, using the following syntax:

AT+LSCN <,scanType>>>>

Therefore, the correct syntax for AT+LSCN without using all optional parameters would be to leave the unused parameters blank (not a "0", just blank) while still dividing each of the optional parameters using commas. For example, if the only parameter required is to configure it the scan type (last parameter) to enable scanning for 1M and Coded PHY (256k) with extended advertisements you would use the following syntax:

AT+LSCN ,,,7

Please see the AT Interface User Guide for the module you are working with for more information.

Lyra Series Modules – AT Interface User Guide

BL65x Series Modules – AT Interface User Guide

Lyra P and Lyra S modules do support Wirepas Mesh but only in low-energy mode node as a non-router, thus you cannot configure it to act as a sink and/or low-latency device within the Wirepas network. This limitation is due to the smaller 32K SRAM size of the EFR32BG22 mcu used on Lyra P/S.

For more details on Lyra P and Lyra S Wirepas solution refer to the following page:

Wirepas Partnership (lairdconnect.com)

For information related to the Wirepas Mesh 2.4GHz FW v5.3.0 refer to the following Release Notes:

Wirepas Mesh 2.4 GHz Firmware v5.3.0 Release Notes: Wirepas Developer Portal

The Silabs chipset from which Lyra series are designed (EFR32BGXX) does indeed support BLE Mesh protocol. However, Ezurio AT Interface firmware doesn't expose BLE Mesh functionality. To get access to this protocol, you'll need to develop your own C code application through Simplicity Studio. You may find the following link useful for developing your own C code application: https://docs.silabs.com/

When making a connection to a mobile device using Lyra VSP service there is a 15 second delay between the "Ring" indication and the "Connect" indication. This issue is not actually a firmware issue and more of a use case issue. In a scenario whereby two LYRAs are connecting the central LYRA will kickstart the process and once a BT connection is established a series of commands will be sent to the peripheral LYRA to ensure the VSP is ready. These things include writing the Modem in & out descriptors to ensure that the devices are in a good state to send data (set to '1') and also to enable notifications on the Modem out and TX characteristics so that the central can view the incoming data. 

In the case where a different non-LYRA device is acting as a central for a VSP connection these extra commands are not automatically sent therefore it is the central devices responsibility to send these commands. 

Writing to the Modem In characteristic is the write that specifically breaks the peripheral LYRA out of the delay state and to output the connect message. This does not necessarily mean that the VSP system is ready the other commands must also be sent for the system to work properly.

If the 15 second delay is not tolerable for an application, then simply writing any value to the MODEM_IN Characteristic will allow the connection handshake to proceed. For example, using nRF Connect to connect to the Lyra DVK running VSP and connected to a UwTerminalX terminal, a simple write of 0xFF results will then show connect.

Yes. When using non-VSP mode multiple concurrent connections and roles can be used. The stack can in theory support as many as 32 concurrent connections in any combination of roles. However, Lyra 22 modules can support 4 concurrent connections while Lyra 24 modules can support as many as 20. 

Yes, all BT modules include the needed LC filter components required for DC-DC Converter operation.

Lyra P and Lyra S modules include a 2.2uH inductor on VREGSW output and 4.7uF capacitor to ground.

The nRF528xx used on the BL65x modules use two voltage regulators, REG0 and REG1. In Normal Voltage mode only REG1 is enabled. In High Voltage mode both REG1 and REG0 are enabled. The BL65x modules include 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground on REG1. REG0 includes a 10uH inductor on DCCH output and 4.7uF cap to ground.

Note: The BL651 module uses the nRF52810 which uses a single voltage regulator. The BL651 includes 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground.

The nRF5340 used on the BL5340 and BL5340PA modules uses four voltage regulators, Main Voltage Regulator, Radio Voltage Regulator, High Voltage Regulator and a USB Regulator. In Normal Voltage mode the Main Voltage and Radio regulators are enabled while the High Voltage Regulator is disabled. In High Voltage mode the High Voltage regulator is enabled along with the Main Voltage and Radio regulators. The BL5340 module includes a 10uH inductor on the DCC outputs and 1uF capacitor to ground on the Main Voltage and Radio Voltage regulators. The High Voltage regulator includes a 10uH inductor on the DCCH output and 2.2uF capacitor to ground. The USB regulator uses an LDO only an no DC-DC filter components are needed.

Using Simplicity Studio SDK, a peripheral device can connect to a maximum of 32 centrals simultaneously (default is 4).  The number of connections can be increased from within Simplicity Studio by configuring the Bluetooth Core software component as described at the following Silicon Labs page:

https://docs.silabs.com/bluetooth/5.0/general/connections/multicentral-topology

However, while this is a maximum that can technically be supported the actual maximum on Lyra is 4 due to RAM size.

If using AT Interface application, 4 concurrent connections from a peripheral to multiple central devices are also supported. AT Interface provides two mutually exclusive modes of operation on start-up depending on the value of writable numeric parameter 100 (referred to as VSP or Bridge mode and non-VSP modes). Multiple concurrent connections can be made when configured for non-VSP mode.

As a peripheral device it will transmit connectable advertisements. A central device such as a smartphone can discover the peripheral and send a connection request at which point upon reception by the peripheral advertisements will be stopped. After a connection has been established the peripheral can then begin transmitting further advertisements allowing connections with further central devices.

Lyra modules must be preloaded with AT Interface firmware, while BL65x modules must be updated to the most current smartBASIC firmware version and programmed with the AT Interface smartBASIC sample application in order to use any AT Interface commands.

To configure a static passkey using AT Interface it is necessary to ensure that the I/O capability of the modules will result in Passkey Entry authentication (per the Bluetooth SIG's IO Capabilities mapping). The Lyra or BL65x module must be configured with the I/O Capability set to Keyboard Only (2) or Keyboard + Display (4), via S Register 107, using the command, ATS 107=x, where x=2 for Keyboard Only or x=4 for Keyboard + Display.

Then the "AT+PKEY " command can be used to issue a static passkey to the underlying stack for use during a pairing procedure in future connections. The passkey must be a 6-digit integer in the range of 000000 – 999999.

The pairing will still use LESC Diffie-Hellman based exchanges.  If a randomly generated number is used for the passkey the static passkey will be used.

Note: Pairing using a pre-programmed passkey makes pairing vulnerable to MITM attacks.

For more information on AT Interface configurations please reference the AT Interface User Guide for the specified module series.

User Guide - BL65x AT Interface Application

User Guide - AT Interface Application - Lyra Series

The AT+PKEY nnnnnn command, used by AT Interface to configure a static passkey, is an on-the-fly command and will not be persistent through a power-cycle/reset. Only S Register settings, using the ATS & AT%S commands, can be saved using AT&W followed by ATZ. All other AT commands are on-the-fly.

NOTE: Using a static, pre-programmed, passkey makes pairing vulnerable to MITM attacks.

For additional information on configuring a static passkey with AT Interface please refer to the appropriate AT Interface User Guide for the Ezurio module you are working with linked below:

User Guide - AT Interface Application - Lyra Series

User Guide - AT Interface Application - BL65x 

These instructions are intended for Linux or Macintosh OS. They may work using WSL, Cigwin, or other bash style terminals in Windows although this is untested. 

It may be desired to communicate with a device attached to the USB-SWD without terminal emulation, I.E. Picocom, Screen, Putty.  This can be useful for writing bash scripts, or if you're using Zephyr's "west flash" and would like a quick way to check your output. 

1. Verify you have the program "stty" available using the command "which stty", if this does not return a value you will need to install it.  Fortunately "stty" generally comes standard with Linux and MacOS.  
2. Identify your serial device.  This can be done using the command "dmesg -w" then connecting the USB-SWD.  You will see output like this (In Linux).

3. (Optional) Assign the device name to a variable, for example "DEVICE=/dev/ttyACM0".
4. Configure "stty" to talk with the device "stty -F $DEVICE 115200 -echo -echoe -echok"
5. To see output from the device execute "cat $DEVICE &".  This will send serial communication from the device to Linux's standard output.  The "&" is to run this program in the background.
6. Now press the reset button on the USB-SWD, you should see the output from your device.  In this example the Zephyr "Hello World" example has been flashed to a BT510. 

7. (Optional) if you would like to send commands back to the device you can use "echo" or add an argument to your shell, "foo() { echo -n -e "$1\r" > $DEVICE; }".  Now commands can be issued directly from the command line, for example "foo "my_command"" will send the string "my_command" to the device. 

Yes. Lyra is a 100% software functional replacement for the BGX220 and BGX13 parts. We recommend reading and evaluating the OUI (Organizationally Unique Identifier) of the BLE MAC address. The OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization where the first three octets / bytes are assigned by the Institute of Electrical and Electronics Engineers (IEEE). For Lyra and Ezurio it is 18-C2-93. In Wireless Xpress, you can make use of the bl a (BLE MAC Address) variable which will return with the complete BLE MAC address of the BGX device.

It is also possible to rely on both sy u (Hardware UUID) and sy v (Bluetooth Xpress Firmware Version) variables. The first 8 digits of the Hardware UUID must be always FFFFFFFF for Lyra. This value should also contain the Ezurio OUI (18C293) value somewhere in between. The Bluetooth Xpress Firmware Version must include the 1.3.0000.0-0-0 string at the end. We will only provide support for this particular software version, and it is the only Wireless Xpress release available for Lyra.

Please note that Wireless Xpress is frozen at its current software release / version, so it will not receive any further development or bug fixing in the future. For comparison reasons you will find attached an example of the get al (Get All Variables) command, captured using one of our Lyra S development boards running Wireless Xpress.

Lyra is based on the EFR32BG22 SoC which is a single-chip solution from Silicon Labs. Both Lyra S (SIP) and P (PCB) are Bluetooth 5.3 modules, but do not support any LE Audio and Low Complexity Communications Codec (LC3) features. Please note that by now Silicon Labs does not offer or released yet a Bluetooth audio stack.

LE Audio is the next-generation Bluetooth standard defined by the Bluetooth Special Interest Group (SIG) and offers enhanced performance in power consumption, latency, and bandwidth. Bluetooth LE Audio differs from Classic Bluetooth (also known as Bluetooth BR/EDR) by operating on the Bluetooth Low Energy (BLE) radio.

LC3 (Low Complexity Communication Codec) is an audio codec which was introduced within the Bluetooth LE audio specification. Simply put, you can say that an audio codec allows to compress the audio stream at the source and can be decompressed at the receiving end. It was designed as a low complexity communications codec to deliver high-quality speech and audio streaming.

You can learn more about LE Audio and LC3 in our Bluetooth LE Audio White Paper and under https://www.bluetooth.com/learn-about-bluetooth/recent-enhancements/le-audio.

In addition to the standard Ezurio bootloader for Lyra, our team also released the so called „legacy“ Bluetooth Xpress (BGX) bootloader on our Lyra Firmware GitHub page for compatibility reasons. It is based on the same bootloader configuration as introduced and used by the BGX220 Wireless Xpress modules. This bootloader version is therefore highly recommended for customers with existing Bluetooth Xpress (BGX) hardware designs moving to Lyra.

The main difference between the Ezurio and legacy Bluetooth Xpress (BGX) bootloader is the mapping / location of the BOOT pin. Please see the below table for more details. The BOOT pin is an active-low digital input to force the module into DFU bootloader on reset. It is used to determine when the execution of the bootloader is required, and for example enables updating firmware via the Serial DFU (UART) interface. For this reason, it is very important to verify the BOOT pin against your current hardware design, especially when migrating from a BGX13 or BGX220 module.

Please note that a bootloader for Lyra is required to execute and run applications. By default, all Lyra modules ship pre-programmed with the Ezurio bootloader type. You can replace and update the bootloader at any time, but only via the Serial Wire Debug (SWD) interface.

No. There is no software support for BLE Mesh, AoA (Angle of Arrival) and Angle of Departure (AoD) in our current AT Command Set Interface implementation. Please feel free to build and develop your own BLE Mesh, AoA or AoD application in C by using the Bluetooth SDK and tools from Silicon Labs. In this case, as a starting point, we highly recommend the Simplicity Studio 5 IDE which offers a rich set / collection of example projects and templates.

Bluetooth Mesh is a wireless mesh topology and standard which enables many-to-many (m:m) device communication for an enormous number of local BLE devices. It supports large-scale node networks without the need of an ordinary BLE gateway infrastructure. Refer to https://www.lairdconnect.com/making-bluetooth-mesh-simple and https://www.bluetooth.com/learn-about-bluetooth/recent-enhancements/mesh for additional information.

Angle of Arrival (AoA) and Angle of Departure (AoD) are two concepts for location positioning and direction finding. Without going into too much detail and to keep things very simple: One of the two BLE devices must have at least two antennas or more, so that the data received from those antennas then can be used to identify the direction and angular position of the location where the Bluetooth signals come from. Please find further information available at https://www.lairdconnect.com/resources/blog/magic-bluetooth-aoaaod-direction-finding and https://www.bluetooth.com/blog/new-aoa-aod-bluetooth-capabilities.

No, this is not possible and not supported. You cannot program and run our AT Command Set Interface firmware or the Wireless Xpress software solution from Silicon Labs on other EFR32-based SoCs or modules like the EFR32BG22 and BGM220 for example. Both applications will perform a self-test and hardware compatibility verification on startup, therefore they will only execute on genuine Lyra modules.

Unfortunately, this is not possible and not something we offer at the moment for our Lyra Series. We cannot ship Lyra modules with our own AT Command Set Interface firmware, Wireless Xpress software from Silicon Labs or a custom BLE application / bootloader pre-programmed.

If you require pre-programmed Lyra parts for manufacturing, we recommend getting in touch with a third-party company house which is offering and specialized in programming services. Please also ask your local distributor if this is a service they can provide you with.

By default, our Lyra DVKs ship completely empty and erased with no bootloader and no application. Before getting started, please make sure to first program a bootloader and application image on your Lyra DVK.

All Lyra modules ship pre-programmed with our own Ezurio bootloader type / configuration and a factory application. The bootloader enables firmware programming via Serial DFU (UART) on modules reset by triggering the BOOT pin and the factory application can be used to upload firmware over-the-air (OTA) via BLE for certain software options.

Please refer to our latest Lyra Series − Firmware Options and Upgrading User Guide document for more details about all available software options and firmware upgrade methods.

Yes! Simply locate and open the .slcp file (e.g. bt_ncp.slcp) in your NCP example project through the Simplicity Studio 5 project explorer view. Go to the software components section and search for the „gatt“ keyword. Install the Bluetooth GATT Configuration component which can be found under Bluetooth → GATT → Configuration with the following description: „Adds basic GATT Configuration to the project that can be customized with the GATT Configurator tool.“

Press the „Install“ button which will add the Bluetooth GATT Configuration tool to your project afterwards. Now you should be able to use the Bluetooth GATT configurator tool via the configuration tools section. Please note that by installing the Bluetooth GATT Configuration component additional files like the config/btconf/gatt_configuration.btconf, autogen/gatt_db.c and autogen/gatt_db.h will be automatically generated and linked to your NCP example project.

The Network Co-Processor (NCP) application runs the Bluetooth stack and provides access to it by exposing the Bluetooth API (BGAPI) via UART connection. This mode for examples makes it possible to run your application on an external MCU, host controller or PC.

Matter, previously known as Project Connected Home over IP (CHIP), is an open source and interoperability connectivity protocol developed by companies such as Amazon, Apple, Samsung, Google, Huawei, Infineon, NXP, Silicon Labs, STMicroelectronics, Texas Instruments, the Connectivity Standards Alliance (formerly Zigbee Alliance) and many many others.

The newly launched networking protocol is designed to connect and build an open, reliable, and secure IoT ecosystems. It aims to simplify the development for manufacturers and increase compatibility for the consumers, enabling communication across smart home devices, mobile apps, and cloud services.

Lyra is based on the Silicon Labs EFR32BG22 SoC (Wireless Gecko Series 2) and does not support the development of Matter applications.

No, it is optional. However, Laird strongly recommends that developers make use of UART hardware flow control by implementing and connecting both RTS (Request to Send) and CTS (Clear to Send) lines in their Lyra designs – beside the regular RX (Receive) and TX (Transmit) pins.

Hardware flow control (also known as RTS/CTS flow control) is called so because the control is handled by the hardware. It is useful in scenarios where the transmitter is able to send data faster than the receiver is able to process. The RTS and CTS lines are turned off and on from alternate ends to control data flow, for instance when a buffer is almost full. This design approach is an effective way to prevent data loss and helps to guarantee data integrity in your application.

Our AT Interface application and implementation for both Lyra (22) + 24 series are making use of the Silicon Labs Stack. They are based on the following − different − Bluetooth Gecko SDK (GSDK) versions:

• Lyra (22) series with Ezurio's GA release >= 2.2 (https://github.com/LairdCP/Lyra_Firmware/releases) is based on the Silicon Labs GSDK v4.0.2 (https://www.silabs.com/documents/public/release-notes/gecko-platform-release-notes-4.0.2.0.pdf)

• Lyra 24 series with Ezurio's GA release >= 1.1 (https://github.com/LairdCP/Lyra_24_Firmware/releases) is based on the Silicon Labs GSDK v4.2.0 (https://www.silabs.com/documents/public/release-notes/gecko-platform-release-notes-4.2.0.0.pdf)

Please also refer to https://www.silabs.com/developers/gecko-software-development-kit for additional information.

No, this is not possible. Lyra does not support the execution of multiple firmware options at the same time. You can only program and run one single firmware option. This includes our own AT Command Set Interface firmware, Wireless Xpress or any custom BLE application which was developed with the Simplicity 5 Studio IDE and the Silicon Labs Bluetooth Stack.

You can switch between the individual firmware options at any time by simply reprogramming the Lyra module via the Serial DFU (UART) or Serial Wire Debug (SWD) debug interface. Please find additional information in our latest Lyra Series − Firmware Options and Upgrading User Guide.

The ATS 302=? command can be used to query both minimum and maximum baud rate values supported by the Lyra AT Command Set Interface firmware. In our example ATS 302=? returns with 9600..1000000. ATS 302? in this case will return with the current defined baud rate value which by default is set to 115200 baud.

You can change the baud rate value individually with the ATS 302=<baud> command. Please make sure to save your new configuration with the AT&W command afterwards. Changes will take effect after a power cycle or a warm reset which can be triggered manually using the ATZ command.

Please note that baud rate values above 1000000 (e.g. 2000000) are not supported currently. Additional information about all AT commands, events, return values and error codes can be found in our latest Lyra Series − AT Interface Application User Guide.

The Lyra modules are based on the EFR32BG22 SoC which is a single-chip solution for BLE and Mesh applications only. Hence Lyra modules don't support 802.15.4, Thread nor Zigbee standards.

The UART DFU utility (also known as uart_dfu or bt_host_uart_dfu) is provided by Silicon Labs. It is a console application which enables firmware updates over a serial UART connection.

This host example is available in C and part of the official Gecko SDK (GSDK). In Windows the application can be built using, for example, MinGW or Cygwin. Under Linux or Mac the program can be compiled with the GCC toolchain.

Before starting, please make sure that Simplicity Studio 5 is installed on your Windows or Linux system. The Gecko SDK − 32-bit and Wireless MCUs technology / software component is mandatory, and the latest available version can be downloaded through the Installation Manager in Simplicity Studio at any time if needed.

Windows

You can either find the UART DFU host example under C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\\app\bluetooth\example_host\uart_dfu or C:\Users\\SimplicityStudio\SDKs\gecko_sdk\app\bluetooth\example_host\bt_host_uart_dfu. Depending on your Simplicity Studio 5 installation and configuration paths may be different. Otherwise, try to search for the uart_dfu folder on your Windows system.

1. Download the latest available Mingw-w64 compiler binaries for Windows and extract them e.g. under C:\mingw64 with 7-Zip. In our example we are using the x86_64-12.2.0-release-posix-seh-rt_v10-rev0.7z release on a Windows 10 Enterprise (21H2) x64 system.
2. Search under Windows for the Edit environment variables for your account shortcut or quick access item. Under User Variables, modify the Path variable. Click Edit and New and add your MinGW-w64 installation path to it. In our example it is C:\mingw64\bin. The bin folder is very important here. Click OK and save your environment variables. There is no need to reboot your computer. All environment variable changes are applied immediately.
3. Next open a Command Prompt (cmd.exe) window, update the environment variables with the set PATH=C:\mingw64\bin;%PATH% command and navigate into the UART DFU host example folder. In our example we are using the cd C:\Users\Laird\SimplicityStudio\SDKs\gecko_sdk\app\bluetooth\example_host\bt_host_uart_dfu command.
4. Now build the UART DFU host example by entering the mingw32-make command. This will take a few seconds. The bt_host_uart_dfu.exe binary can be found in a subfolder called "exe" once successfully completed.
5. Use the cd exe command to navigate into the exe directory. For testing, enter bt_host_uart_dfu.exe which should print a similar usage information text as following: bt_host_uart_dfu.exe -t | -u [-b ] [-f] [-l ] [-h]

Linux

You can either find the UART DFU host example under /opt/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite//app/bluetooth/example_host/uart_dfu or //SimplicityStudio/SDKs/gecko_sdk/app/bluetooth/example_host/bt_host_uart_dfu. Depending on your Simplicity Studio 5 installation and configuration paths may be different. Otherwise, try to search for the uart_dfu folder on your Linux filesystem.

1. Make sure that the build-essential package is installed on your Linux system with the sudo apt install build-essential command. In our example we are using a Ubuntu 22.04 LTS x64 system.
2. Next open a Terminal window and navigate into the UART DFU host example folder. In our example we are using the cd /root/SimplicityStudio/SDKs/gecko_sdk/app/bluetooth/example_host/bt_host_uart_dfu command.
3. Now build the UART DFU host example by entering the make command. This will take a few seconds. The bt_host_uart_dfu binary can be found in a subfolder called "exe" once successfully completed.
4. Use the cd exe command to navigate into the exe directory. For testing, enter ./bt_host_uart_dfu which should print a similar usage information text as following: bt_host_uart_dfu -t | -u [-b ] [-f] [-l ] [-h]

Based on your Lyra development board revision you may notice a slightly different silkscreen and labeling for the Software Development Selection Switch (SW1). On all Lyra development boards with revision 2.2 (or prior) AT/BGx is labelled as BGx and C-DEV labelled as AT/SWO. Please refer to our Lyra S Development Kit and Lyra P Development Kit User Guides for more details.

This modification was introduced with the latest available Lyra S and P development boards to better reflect all various and supported software development types. It is a cosmetic change only and does not have any impact on the function of the Lyra development board.

The revision number is printed on the back side of your Lyra development board as illustrated and highlighted in the below example. It can be located in one of the corners near the 10-pin header row, product label and Mini Simplicity Connector.

Lyra P and Lyra S modules are based on the Silicon Labs EFR32BG22 BLE SoC which contains 2x USART interfaces which can be configured for UART/SPI/SmartCard (ISO 7816)/IrDA/I2S. However, depending on the SW used for an application there are some details to be aware of. Lyra supports SW development using AT Interface Command Set, Wireless Xpress or C Code. The following notes should be considered depending on which SW is used for development. USART1 is used for DFU when loading the module with FW of choice. The bootloader FW that Lyra modules are shipped with reserves specific pins that are used by USART1. Refer to the Lyra S or Lyra P datasheets for details.

AT Interface does support SPI but only on the following pins:

• Lyra S:
  • SPI MOSI: PB01; Pin 9
  • SPI MISO: PB02; Pin 8
  • SPI CLK: PB03; Pin 7

• Lyra P:
  • SPI MOSI: PB01; Pin 5
  • SPI MISO: PB02; Pin 4
  • SPI CLK: PB03; Pin 3

Wireless Xpress SW does not support SPI.

For applications using C Code development pins from USART0 are available on any unused GPIO pins associated with Port A / B / C / D and if USART1 is not intended to be used for DFU pins are available on any unused GPIO pins associated with all port pins. Refer to the Lyra S or Lyra P datasheets for information on pins available as GPIO.

PTI enables debugging complex wireless systems. This interface allows to capture a trace of wireless network activity and supports a comprehensive way to analyze it using Simplicity Studio Network Analyzer.

Description:

PTI is an interface, which provides serial data access directly to the radio transmitter/receiver frame controller. Most Silicon Labs’ development kits have the PTI embedded and ready to use. It is also possible to use the network analysis features when working on custom hardware if the PTI pins are exposed via a debug interface. It is implemented in hardware so there is no software overhead for the application.

With Simplicity Studio Network Analyzer, users can tap into the data buffers of the radio transceiver via a dedicated Packet Trace Interface (PTI). PTI data can be then transferred via USB or Ethernet to a computer running Simplicity Studio. Finally, the time-stamped data can be interpreted and displayed in Simplicity Studio Network Analyzer tool.

Configure the PTI Interface

On Lyra devices, a mechanism is provided for the user to tap into the data buffers at the radio transmitter/receiver level. From the embedded software perspective, this is available through the RAIL Utility, PTI component in Simplicity Studio. That component is effectively a simple packet trace interface driver.

A single-pin UART signal is used for PTI data transfer. This can be configured in the RAIL Utility, PTI component.

1. Open the .slcp file (Project Configurator) of the previously created project.
2. Go to the Software Components tab.
3. Click on the Platform -> Radio -> RAIL Utility, PTI component.
4. Click on the Configure button.

PTI Component

The baud rate is selectable. The default baud rate is 1.6 Mbps. The maximum baud rate is 3.2 Mbps.

Note: when using 2M PHY with Bluetooth Low Energy, the default PTI-over-UART speed (1.6 Mbps) should be increased to a higher baud rate.

5. Change the PTI Baud Rate (Hertz) field from 1600000 default to 3200000:

PTI Baud

Additionally, the speed at which the PTI frames are forwarded from the Lyra device back to USB/UART must also be increased by setting the PTI config corresponding to your adapter at the correct baud rate through the Admin Console interface.

6. Right click on the device in the Debug Adapters view and select Launch Console

PTI Launch

7. Select the Admin tab and execute the following command.

     pti config 0 efruart 3200000

PTI Admin

This command will configure the debug adapter part of the Lyra DVK. Note that erasing or flashing the target does not have any effect on this configuration.

8. Close the console.
9. Switch back to Simplicity IDE tab and build the project by clicking on the hammer icon, which will generate the application image to be flashed to your device.
10. Flash the application image to your device by going into the project explorer tab. In your project root folder, in the binaries folder, click on the drop down arrow and right click on "soc_empty.hex" -> Flash to device.

11. Click on the Program button in the pop-up window to start the programming:

How to: permanently securing the Lyra device

Description: 

The First Stage Bootloader Checker needs the Silicon Labs public key to verify the First Stage Bootloader. This was already burned into the ROM of the device at the Factory.

However, the First and Second Stage Bootloaders require the final product public key to verify the signature of any signed firmware images. This public key can be found in the files signing-key.pub and signing-key-tokens.txt. This key needs to be flashed into the device by the final product maker.

The commands below will permanently make your device secure. However, it will always require future software updates to be signed by the exact same private signing-key.

You may want to skip this step, knowing that you are preventing the device from having a complete Chain-of-Trust. Without the key stored in OTP memory, the First Stage Bootloader will not check the signature of future Second Stage Bootloader. This will allow you to reuse the chip with future projects by erasing the full-device along with the final product public key stored in flash.

If you choose to complete this section, you will need to use the same private key to sign future Second Stage Bootloader, Apploader and Application images.

1. Flashing the public key to the OTP, run the following command, Type "Continue" to confirm, that this step is irrevocable:

   commander security writekey --sign signing-key.pub --device EFR32BG22C224F512IM40

2. Enable First Stage Bootloader to use Secure Boot to authenticate Second Stage Bootloader

   1. Open the “Device Configuration”

      

   2. Select the “Security Settings” tab, click “Read from Device”, and "Start Provisioning Wizard" to enable secure boot in the First Stage Bootloader
      
      

   3. Enable irrevocable write data operation for OTP for public key. Alternatively, version number and certificate verification flags can be set, click Next:

      

   4. In the “Security Keys” window you will notice that the sign key is already filled in, click Next:

      

   5. Use the default settings in the “Secure Locks” dialog:

      

   6. Review the summary, click “Provision” to continue, and then click “Yes” to complete changing the security settings:

      

   7. At the “Security Settings” tab, you can verify success by reading “Secure Boot: Enabled” after completing the above steps:

      

Simplicity Studio template such as: soc-empty includes a script create_bl_files.bat/sh, which generates bootloader files including signed images for Apploader and Application firmware. The script once is run creates a folder with name output_gbl, where the signed images are resided. In order to generate the signed images for Apploader and Application firmware the private key file signing-key should be copied to the root folder of the project. The private key should be placed in the same folder as the create_bl_files.bat/sh script and the name of the private key file should be changed to app-sign-key.pem. 

To run the script open command prompt on windows or bash shell on Linux and browse to the root folder of the project, where the script and private key files are resided. Don't forget to change the name of the private key to app-sign-key.pem before launching the script. Run the script using the command below:

​create_bl_files.bat/sh

The script generates signed files as shown:

Steps to adding a service UUID to advertising data of implemented by Silicon Labs adapted GATT services

The implementation of supported adapted GATT services in application firmware using Simplicity Studio IDE is enabled from *.slcp file of the project [Bluetooth] -> [GATT]. Once the developer selects the service, the source code with associated functions will be generated by the Simplicity Studio. However, in some cases the developer might need to extend the functionality of the generated service and add new functions. Example of such new function is a advertising of service UUID.

To add the service UUID to advertising data using [Bluetooth] -> [GATT] configuration, select the service and install it. Once is installed, click on [Configure] blue button in the top right corner and after the configuration is opened, select [</> View Source]. It will open XML file for the service. 
Set service advertising to "true" as follows: service advertise="true". Save the XML file and close it.

After rebuilding and loading the project firmware, the peripheral device with be advertising service UUID. It can be tested with EFR Connect or nRFConnect BLE applications by reviewing the information in the advertising packet.

Steps to install CMSIS-PACK in IAR for Silicon Labs devices

CMSIS-PACK manager helps with extending the functionality of IAR software to support device's specific functions of Silicon Labs IC. The steps below will describe the installation of Silicon Labs CMSIS packages using CMSIS manager within IAR Workbench IDE.

To launch the CMCIS-PACK Manager from the project: Open the project in IAR IDE and select [Project] -> [CMSIS-PACK] Manager

     

A popup will appear asking if you want to enable the CMSIS manager for the project, say yes



When the CMSIS Manager opens select the Device tab and under Silicon Labs see if there are any entries for the BGM22 Series. If not there might be entries for EFR32BG22 parts or else select [Help] > [Check for Updates]



From the Devices tab, select the EFR32BG22 or BGM22 group and then select the [Packs] tab and there should be a Silicon Labs.GeckoPlatform_EFR32BG22_DFP package. If not click the blue Refresh icon in the upper right. There should be a grey Install icon available, click that to install the support package



Once the CMSIS-PACK is installed the IAR tools are extended and ready yo be used to support Silicon Labs devices from BGM220 family  

How to generate IAR project files

The IAR project's files can be generated using Simplicity Studio project generator option “IAR EMBEDDED WORKBENCH PROJECT”. Once generated the project can be imported to IAR

Steps to generate IAR project

• Open *.slcp file in Simplicity Studio 
• Change to Overview tab 
• Select Edit in Project Generators

• Check IAR EMBEDDED WORKBENCH PROJECT option 

• Push Save button 

Once the IAR project files were generated, the IAR IDE can be launch by clicking the *.eww inside or outside of the Simplicity Studio as needed:

• “IAR EMBEDDED WORKBENCH PROJECT” option generates three files (*.ewd, *.ewp, *.eww)
• The path to the location of the project and IAR files are at Resource Location property. To obtain the location please right click on the project -> Properties

How to generate GCC Makefile for project

The GCC Makefile for the projects can be generated using Simplicity Studio project generator option “GCC Makefile”. Once generated the project can be built outside of the Simplicity Studio using make tools

Steps to generate

• Open *.slcp file in Simplicity Studio 
• Change to Overview tab 
• Select Edit in Project Generators

• Check GCC MAKEFILE option 
• Push Save button 

Once the Makefiles were generated, they can be updated outside of the Simplicity Studio as needed:

• “GCC Makefile” option generates two files (*.Makefile and *.mak)
• The path to the location of the project and makefiles are at Resource Location property. To open please right click on the project -> Properties

Summary

The project can be built with “make -f *.Makefile …” command from  “Command Prompt” or using Cigwin on windows. Other platforms: iOS, Linux support “make” command natively.  
The “make” utility generates: *.hex, and *.bin files which are firmware executables. They can be loaded to the internal flash using SWD interface, bootloader UART interface or other methods.
Please note that bootloader UART interface accepting firmware image in [GBL] format and generated by Make utility files should be converted before using this method.    

SWD J-LINK application image update 

Serial Wire Debug (SWD) is a 2-pin (SWDIO/SWCLK) electrical alternative JTAG interface that has the same JTAG protocol on top. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface documentation. It can be used to access SoC/module internal resources and perform basic erase/ read/ write operations on embedded flash. The steps below describe the update of the internal flash with the new application image firmware using SWD interface.

Commands 

• Open J-link utility (e.g.: windows location: C:\Program Files (x86)\SEGGER\JLink)
• Connect to the target: connect
• Select device: EFR32MG22CXXXF512
• Specify target interface: SWD
• Specify target interface speed: 1000kHz
• Perform target reset: r
• Erase application sectors: erase 0x6000 0x80000
• Program the application: loadfile c:\prj\soc_empty_x.bin 0x6000
• Restart the module using the “Reset” button on the Explorer board
• After reset the firmware will start advertising w/ name: “Empty Example”. Any scanner application(e.g.: nRF Connect or EFR Connect) can be used for testing the application update 

SWD J-LINK Bootloader update 

Serial Wire Debug (SWD) is a 2-pin (SWDIO/SWCLK) electrical alternative JTAG interface that has the same JTAG protocol on top. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface documentation. It can be used to access SoC/module internal resources and perform basic erase/ read/ write operations on embedded flash. The steps below describe the update of the internal flash with the new bootloader image using SWD inetrface.

Commands   

• Open J-link utility (e.g.: windows location: C:\Program Files (x86)\SEGGER\JLink)

• Connect to the target: connect

• Select device: EFR32MG22CXXXF512

• Specify target interface: SWD

• Specify target interface speed: 1000kHz

• Perform target reset: r

• Erase bootloader sectors: erase 0x0 0x6000

• Program the bootloader image: loadfile c:\prj\bootloader.bin 0x0

• Restart the module using the “Reset” button on the Lyra board

• Please note, the LED on the board can be used to indicate that status of the update 

Introduction:

Lyra BGM220P, BGM220S modules from BG22 family can be programmed with two bootloaders types:

• BGAPI UART DFU – programmed by SiLabs to all BG22 modules, supports firmware updates over UART with special utility uart_dfu.exe 

• UART XMODEM – the firmware update can be performed over UART interface using TeraTerm or similar program, the protocol for sending the file is XMODEM
  
  

Importing Bootloader Projects

The easiest way to import one of the the bootloader templates is from Simplicity Studio Launcher tab:

• Start Simplicity Studio application 
• Open Launcher perspective - Window -> Perspective -> Launcher
• Attach Lyra DVK to the PC USB
• Using "Start" button connect Simplicity Studio to the Lyra DVK (Connected Devices - > [Select J-Link Silicon Labs device name ] -> Start) 
• Select “Technology type” “Bootloader” from “Example Projects & Demos” tab:

• Import one of the Bootloader projects from the “resources found” list by clicking “Create” of the resources: 

   
• Assign the name to the Bootloader projects once the New Project Wizard is opened:

• Update and save *.hwconf and *.isc files as requested for the project.
• From the *.isc file configuration interface click on "Generate" for project generation:

• Upon successfully completing the generation of the project, Simplicity Studio will output the "Generation successful" message with the list of generated, updated and unmodified files, please save this info and click "OK" to continue:

• The project is ready to be built, debugged and tested. In addition, the Bootloader binary can be loaded to the internal flash location @ address: 0x00 of the module using J-Link Segger utility  

UART XMODEM Bootloader

UART XMODEM Bootloader – the update can be performed over UART interface using TeraTerm or similar program, the protocol for sending the firmware images is XMODEM. Please make sure to load the bootloader image into the internal flash location 0x00 of the module if wasn't done already before proceeding to the next step. In addition, the [GBL] file is required for the firmware update to work.     

Updating the application image using UART XMODE Bootloader

• Please connect TeraTerm or similar program w/ 115200 baud rate, 8 bits, No parity, 1 Stop bit, No Flow Control to the communication port (e.g.: COM17)

• Once connected please press “Enter”, the screen output should be as shown:

• Select “1”  for uploading [GBL]
• Send the application image [GBL] file using XMODEM protocol, example below for TeraTerm
   

• Once the update is completed, to test the BLE application(example: soc-empty) please used mobile application (e.g.: nRFConnect, EFRConnect). The device should be advertising with “Empty Example” device name if soc-empty project produced firmware was used for update without any additional modifications. The device name can be updated in the soc-empty project using GATT configurator as shown:

Summary:

The steps above prove with basic usage information on utilizing UART XMODEM BOOTLOADER  for modifying the firmware application partition of the internal flash of BGM220P and BGM220S module

BGAPI UART DFU Bootloader

This bootloader firmware is programmed by Silicon Labs to all BG22 modules during the manufacturing process. It supports updates over UART with special utility uart_dfu.exe

Updating the application using BGAPI UART DFU Bootloader

• Please build the application uart_dfu.exe using “make” with “cigwin” or similar platform on Windows operating system. On Linux, and Mac OS/s the “make” is supported natively.
• As an example the source code of the application uart_dfu can be found under the following folder on WindowsOS: 

C:\SiliconLabs\SimplicityStudio\v5\developer\sdks\gecko_sdk_suite\v3.2\app\bluetooth\example_host\uart_dfu

• Please build the application uart_dfu using of the methods described above
• Locate the uart_dfu.exe executable and run the command:  
  ./uart_dfu.exe COM42 115200 full.gbl where:​​​

1. ./uart_dfu.exe - name of the application 
2. COM42 - serial communication port of the connected DVK 
3. 115200 - serial port baud rate
4. full.gbl - Geko Bootloader file [GBL]. This file is generated by running  the create_bl_files.bat/.sh scripts. The script is included into soc-empty project templated that is provided by Simplicity studio. For testing please use soc-empty template project from Simplicity studio for experimenting and creating the GBL file      

• The utility generates the following message upon successful application update completion:

 

• Once the update is completed, to test the BLE application(example: soc-empty) please used mobile application (e.g.: nRFConnect, EFRConnect). The device should be advertising with “Empty Example” device name if soc-empty project produced firmware was used for update without any additional modifications. The device name can be updated in the soc-empty project using GATT configurator as shown:
  
   

 Summary:

Introduction 

Lyra BGM220P, BGM220S modules from BG22 family can be programmed with two bootloaders types:

• BGAPI UART DFU – programmed by SiLabs to all BG22 modules, supports firmware updates over UART with special utility uart_dfu.exe 

UART XMODEM – the firmware update can be performed over UART interface using TeraTerm or similar program, the protocol for sending the file is XMODEM

The instructions below will provide with steps for building, and debugging the bootloader firmware using Simplicity Studio. 

Building

The bootloader project is built by right clicking the project in the Project Explorer and selecting “Build Project”. The project built takes several minutes and should complete without errors or warnings. The information on the progress of the building process is outputted to the Console. The output of the building process is a file in binary format 
 

Debugging  

The firmware is debugged with Simplicity Studio debug perspective. The bootloader executable, which includes debugging symbols and was produced by project build is loaded by debug session J-Link utility during launch to the internal flash of the module into location 0x00. Once the firmware is loaded to the flash the debug session will instruct the MCU to run the firmware from the Reset vector location. The debug session is configured to halt the MCU at main() and can be resumed by pressing "Resume" button within debug perspective.
 

Launching debug session  

The built project can be loaded by Debug session in the Simplicity Studio by clicking project in the Project Explorer and selecting “Debug As” a  predefined “Silicon Labs ARM program” debug configuration as shown:

The program will be halted by debug session at main() and the debugging procedures can be started. The program execution can be resumed by pressing “Resume” button. The following screen indicates that program was launched and halted at main()

 

Summary: 

The basic steps which are described above can help with getting stated with debugging the bootloader template provided by Silicon Labs. In addition, it can support maintaining the exiting functions and developing a new procedures where firmware troubleshooting is required.  

The following three images are flashed to the chip in addition to the public key: 
- bootloader-storage-internal-single-512k-signed.s37 - signed **second stage bootloader 
- apploader-signed.gbl - signed apploader GBL for field OTA updated.  
- application-signed.gbl - signed application firmware GBL.

Please change to the folder where the images are located and run the commands below:
​    

commander flash bootloader-storage-internal-single-512k-signed.s37
​commander flash apploader-signed.gbl
​commander flash application-signed.gbl
 

Note: For testing the signed images, use the EFR Connect application.  The device loaded with signed application image of the soc-empty template project from Simplicity Studio without any modifications should be advertising with Empty Example name. The name Empty Example should be in the scan list to conclude that the signed images were created correctly. 

To generate public keys, perform signing operations for development purposes to evaluate or test secure boot or secure updates please use the command below, the ECDSA-P256 keys will be stored on your PC:

commander gbl keygen –-type ecc-p256 –-outfile signing-key

The following describes three different files that were generated by the command above:

• signing-key-tokens.txt - file is used by commander to program devices during manufacturing. The tokens are generated from the specific private keys, so there is no issue with outsiders using these public tokens to generate malware. However, these tokens are used by the chip to validate signed images for Second Stage Bootloader, Apploader and Application firmware images received in the future. The key tokens come in an X,Y pair.
• signing-key - file is in a Privacy Enhanced Mail (PEM) format. This is common for certificates in Web servers and was used for storing the private keys. This cannot be discovered by other users. If others gain access to the private key, they could generate images that the device would validate using the public keys generated by this private key. The private key should be securely stored.
• signing-key.pub - file contains the public key that can be used to verify that the GBL files were generated by the correct private key. If you were to verify the OTA upgrade on another platform, like a gateway or smartphone app, they would likely consume this PEM-encoded public key file.

Note: Hardware Security Module (HSM) is recommended for key generation in production environment, storage, and image signing. HSM provides with strong protection of sensitive data. According to the instructions from the HSM vendor, have it generate an ECDSA-P256 key pair and export the public key in PEM format to the file signing-key.pub. Then use Simplicity Studio commander to convert the key to token format, suitable for writing to the EFR32BG22 device using the following command:

commander gbl keyconvert --type ecc-p256 signing-key.pub --outfile signing-key-tokens.txt

The public key is used  by Second Stage Bootloader to verify Apploder and Application firmware. This key is stored into User Mode location on the chip. It is flashed into topmost page of the main flash and not accessible from the user application. To store the public key on the device use the following command: 

​commander flash –-tokengroup znet –-tokenfile signing-key-tokens.txt

The command above should be launched from the folder where the signing-key-tokens.txt file is located.

For strong security, public keys need to be protected from accidental or intentional modification. This protection can be accomplished via hardware support, such as storing the keys in an immutable memory such as OTP or a locked flash page, or the key can be crypto-graphically authenticated prior to it being used.

By default, the public key is stored in the last page of main flash memory. In order to secure this key, the flash page containing the key must be locked in order to prevent software from being able to modify the key. This flash page protection operation can be performed either in the Second Stage Bootloader or in the Application.

As an alternative to protecting the public key via hardware, it can be protected using cryptographic authentication. The method using cryptographic authentication using certificates represents the strongest and most flexible security solution.

Use the generated private key file signing-key and Second Stage Bootloader executable bootloader-storage-internal-single-512k.s37 to generate the signed version of the Second Stage Bootloader image. The output file, for example can be called: bootloader-storage-internal-single-512k-signed.s37. Issue the command below to generate the signed version of the Second Stage Bootloader:
 

​commander convert bootloader-storage-internal-single-512k.s37 –-secureboot –-keyfile signing-key –-outfile bootloader-storage-internal-single-512k-signed.s37
 

bootloader-storage-internal-single-512k.s37 - unsigned bootloader image, an input parameter for commander utility.

signing-key - private key, an input parameter for commander utility.
bootloader-storage-internal-single-512k-signed.s37 - signed bootloader image, an output file generated by commander utility.
 

Note: to use the command as shown above place the unsigned version of the Second Stage Bootloader executable and private key signing-key in the same folder. In addition, the command "commander" can be run from any folder if was added to the path environment variable. 

Please find below the naming description of:

• Signed and unsigned binaries of the Bootloader. 
• Unsigned images of Apploader, Application.
• Other GBL files.
• The script for creating the GBL files targeting both platforms Linux and Windows.
• The public and private keys, that are used for signing the images.

The following list describes the files:

signing-key-tokens.txt - file is used by commander to program devices during manufacturing. The tokens are generated from the specific private keys, so there is no issue with outsiders using these public tokens to generate malware. However, these tokens are used by the chip to validate signed images for Second Stage Bootloader, Apploader and Application firmware images received in the future. The key tokens come in an X,Y pair.

signing-key - file is in a Privacy Enhanced Mail (PEM) format. This is common for certificates in Web servers and was used for storing the private keys. This cannot be discovered by other users. If others gain access to the private key, they could generate images that the device would validate using the public keys generated by this private key. The private key should be securely stored. This file was used to sign bootloader image.

signing-key.pub - file contains the public key that can be used to verify that the GBL files were generated by the correct private key. If you were to verify the OTA upgrade on another platform, like a gateway or smartphone app, they would likely consume this PEM-encoded public key file.
app-sign-key.pem - this file is identical to signing-key file and was used to sign the Apploader and Application images.

create_bl_files.sh - script is targeting Linux platform and included in soc-empty template. It creates GBL signed and unsigned files.

create_bl_files.bat - script is targeting Windows platform and included in soc-empty template. It creates GBL signed and unsigned files.

application.gbl - unsigned GBL file for soc-empty application.

application-signed.gbl - signed GBL file for soc-empty application.

apploader.gbl - unsigned GBL file for Apploader.

apploader-signed.gbl - signed GBL file for Apploader.

full.gbl - unsigned GBL file for Apploader and soc-empty Application.

full-signed.gbl - signed GBL file for Apploader and soc-empty Application.

bootloader-storage-internal-single-512k.axf/bin/hex/s37/-crc.s37 - second stage bootloader unsigned image in different formats including CRC.

bootloader-storage-internal-single-512k-signed.s37 - second stage bootloader signed S-record image.

soc-empty.axf/bin/hex/s37 - soc-empty unsigned image in different formats.

This section summarizes how to perform Secure OTA firmware update to the Lyra devices in the field. For testing, the soc-empty template can be used and first steps is to modify the project so that a change can be detected in the EFR Connect mobile app if the device is successfully updated. The next steps is to store the signed image to a cloud storage service that your mobile device can access and the final steps will be to use EFR Connect to initiate an OTA update. 

• To generate signed images for soc-empty template please modify the BLE device name and change it to: LCI Example in the soc-empty project, build the project and finally run the script create_bl_files.bat/sh using the same private key file signing-key.
• Copy output_gbl folder with the images: application-signed.gbl, application.gbl, apploader.gbl, apploader-signed.gbl, full.gbl, and full-signed.gbl to Dropbox cloud storage for example. 
• Run EFR Connect to perform the OTA procedure, please experiment with partial, full signed images for successful updates and to initiate the failed update use unsigned images.

Local regulatory bodies put limitations on how much power a radio equipment is allowed to radiate. This document discusses the rules applied by two main regulatory bodies (ETSI and FCC) and presents how Silicon Labs' Bluetooth stack limits TX power to comply with these regulations.

Without Adaptive Frequency-Hopping (AFH)

ETSI EN 300 328

It is generally true that ETSI EN 300 328 allows 20 dBm RF output power when equipment is using wide band modulations other than FHSS (Frequency Hopping Spread Spectrum). In these cases, PSD (Power Spectral Density) also must be tested, which allows 10 dBm / 1 MHz. These restrictions apply to those BLE devices where adaptive frequency hopping is not enabled. For 125 kbps, 500 kbps and 1 Mbps PHY (~1 MHz bandwidth), which means that the maximum radiated power allowed is 10 dBm. For 2 Mbps PHY, it is a few tenths dB more.

FCC 15.247

Based on FCC part 15.247 for wideband digital modulation, the output power can go up to 30 dBm and the power spectral density must be below 8 dBm / 3 KHz. For 500 kbps (coded), 1 Mbps and 2 Mbps PHY, 30 dBm limitation is applied. For 125 Kbps coded PHY, the device doesn’t pass the 8 dBm/ 3 KHz PSD limit with full power. As a result, the maximum output power allowed is 14 dBm.

Summary

Because Bluetooth stack follows strict regulations, the maximum output power is 10 dBm in those cases when AFH is not enabled (or AFH is enabled but no more than 15 channels are available). This stack limitation (10 dBm EIRP) is valid for all PHYs and devices.
 

With Adaptive Frequency-Hopping (AFH)

ETSI EN 300 328

When adaptive frequency hopping is allowed (and at least 15 channels is available), the only limitation is maximum 20 dBm EIRP. There are no restrictions for PSD.

FCC 15.247

If AFH is used, the maximum output power, which is allowed by FCC, can be 30 dBm and there are no PSD limitations. FCC contains, however, a restricted band from 2483.5 MHz to 2500 MHz. As a result, in several cases power limitation is needed on the edge channels.

Summary

Considering regulations of FCC and ETSI, when AFH is applied and at least 15 channels are available, the maximum conducted output power, which is allowed by BLE stack, is 20 dBm on all channels except of on channel 37 and 38 (physical channels not logical channels) . The output power is limited to 18 dBm on channel 37 and 15.3 dBm on channel 38 in the case of all PHY/s. There isn’t any limitation on channel 39 because the upper channel is only used for advertisements, so with the low duty cycle correction advertisements can be sent at full power.

Application Examples

The Silicon Labs Bluetooth stack allows for a wide variety applications to be built on its foundation. This repo showcases some example applications built using the Silicon Labs Bluetooth stack. The link to the repo on Github - https://github.com/SiliconLabs/bluetooth_applications inludes the following samples:

• BLE Man-in-the-Middle vulnerability Demo with a solution
• BLE NFC Pairing with NT3H2111 and NT3H2211
• BLE SPP over BLE (Serial Port Profile)
• BLE SPP with Windows (Serial Port Profile)
• BLE OTA Firmware Update in User Application example
• BLE Uploading Images to Internal/External Flash Using OTA DFU
• BLE Using EM4 Energy Mode in Bluetooth iBeacon Application
• Explorer Kit BLE accelerometer example using I2C bus BMA400 accelerometer
• Explorer Kit BLE barometer example using I2C bus DPS310 pressure sensor
• Explorer Kit BLE bio-sensor example using I2C bus MAXM86161 HR and SpO2 sensor
• Explorer Kit BLE bio-sensor example using I2C bus MAXM86161 HR/SpO2 sensor and OLED display
• IR Generator (InfraRed)
• Log system example using UART(VCOM) or RTT with message levels
• Explorer Kit BLE accelerometer example using SPI bus BMA400 accelerometer

Bluetooth LE Stack Feature Examples

This repo - https://github.com/SiliconLabs/bluetooth_stack_features contains example projects which demonstrate the features of the Silicon Labs Bluetooth stack. The examples are categorized by the features that they demonstrate. These features are advertising, connections, GATT protocol, security, persistent storage, firmware upgrade, NCP, and system and performance.

The list of the samples includes:

• Advertising
• Connections
• GATT Protocol
• Security
• Persistent Storage
• Firmware Upgrade
  • OTA for NCP Hosts
  • OTA from Windows
• NCP
• System and Performance

Python-Based Host Examples

This repo - https://github.com/SiliconLabs/pybgapi-examples contains example projects based on pyBGAPI that implement simple Bluetooth and Bluetooth mesh applications for demonstration purposes. These examples can be used as references to implement custom Bluetooth and Bluetooth mesh applications in Python in just a few minutes without writing a single line of embedded code.

All examples in this repo reproduce the behavior of existing C examples from the Gecko SDK. The examples can be tested together with the EFR Connect mobile app. See the documentation of the original C examples to get more information.

The list of the samples includes:
 

Bluetooth - Empty
Bluetooth - iBeacon
Bluetooth - Thermometer
Bluetooth - Thermometer Client
Bluetooth mesh - Empty

Introduction 

Silicon Labs provides with several templates to get started with firmware development targeting BGM220 modules. The templates can be imported within Simplicity Studio. In order to extend the functionality of the templates the developers might need to add a new functions or modify the existent ones. Here we will be discussing the steps of modifying the provided by SOC-EMPTY template functions sl_bt_on_event() and app_init(). 
 

Steps/recommendations to modify the functions from template (example: SOC-EMPTY)

The template project SOC EMPTY has several C source and header files. The functions are implemented in the source files and declared in the header file. To extend the functionality of the project and add project specific functions the recommendation is to add [unique_name]_app.c file to the original template, where application specific functions should be implemented. All the template's provided files should remain unchanged with the exception of the the declaration of the sl_bt_on_event() function in app.c   

sl_bt_on_event()

sl_bt_on_event() function is implemented in app.c  and declared in autogenerated sl_bluetooth.h header file. Due to the auto-generation and "sl - silicon labs"  prefix is not recommended to change the original declaration of this function or modify the original body. If this function needs to be updated the recommendation is to change the original function definition in app.c  to SL_WEAK void sl_bt_on_event(sl_bt_msg_t *evt) , and in the added to the project [unique_name]_app.c  file the function definition for this function should be: void sl_bt_on_event(sl_bt_msg_t *evt) with required changes in the function body.
 

app_init() 
 

app_init() is declared in the app.h C header file of the project's template. The original definition of this function is in app.c SL_WEAK void app_init(void). It should remain unchanged. If this function needs to be updated the recommendation is to define a new function void app_init(void) in the unique_name]_app.c. Project specific initialization procedures, welcome message and etc... can be implemented in the body of this function.
 

Summary  
 

In the  steps above were described several recommendations for extending the functionality of the original templates for two functions: app_init() and sl_bt_on_event(). Similar approach can be taken to extend other provided in the  template functions, example: app_process_action(void) if required. SL_WEAK is defined in em_common.h as follows: 
/** @brief A macro for defining a weak symbol. */
#define SL_WEAK __attribute__ ((weak)) 

How to get started with developing firmware for Lyra BLE modules
 
Introduction 

The following article provides with brief introduction on how to get started with firmware development using Lyra P&S Bluetooth Low Energy Modules. It describes the required software tools, hardware and connection setup 

Hardware

• Lyra S or P Development Kit 

• Micro USB cable

Software

• Simplicity Studio IDE v5 or higher  
• Bluetooth SDK 3.2.1 or higher

Connection 

Use the micro USB cable provided in the Lyra DVK and attach it to PC USB slot and the micro USB connector on the DVK  

Building and running the firmware  

Please launch Simplicity Studio IDE and import the SoC Empty project template:

• File->New->Silicon Labs Project Wizard... 
• Assign Target:

1. Boards[BGM220 Explorer Kit Board (BRD4314A)]
2. Device[BGM220PC22HNA]
3. SDK[Gecko SDK Suite: Amazon, Bluetooth 3.2.1, Bluetooth Mesh 2.1.1, HomeKit 1.0.1.0, MCU 6.1.1.0, Micrium OS Kernel, OpenThread 1.2.1.0 (GitHub-48b129e74), Platform 3.2.1.0]
4. IDE / Toolchain[Simplicity IDE / GNU ARM v10.2.1]

• Click Next and on the left top in filter on keywords type: "SoC Empty" and select "SoC Empty" template on the right top, Click Next to import the selected template
• If required please change the "Project Name"  and click Finish
• Build the imported project: Right click on the "project name" in Eclipse Project Explorer tab in the left top and select "Build Project". The build should finish with 0 errors and 0 warnings   
• Run the project using debug session: Right click on the "project name" in Eclipse Project Explorer tab in the left top and select "Debug As" -> "Silicon Labs ARM Program" 
• If more than one device is connected to USB, please select the device to debug in Device Selection dialog  window and click OK. The firmware should start loading and right after the MCU execution should be halted in main().
• Please resume MCU execution by pressing F8     

Test the firmware

To test if the loaded firmware is running correctly please use EFR Connect application 

1. Download the EFR Connect for iOS or  Android smartphone
2. Open the app and choose the Bluetooth Browser
3. Find the device advertising as "Empty Example". Select  Connect
4. The connection is opened, and the GATT database is discovered. Find the device name characteristic under Generic Access service and try to read out the device name. It should return Empty Example 

Note:

The MCU might not halt at main()  if the bootloader location on the Flash was erased. In order to recover from this error, the bootloader should be loaded to address#0 using the j-link utility command: loadfile bootloader.hex 0