Lyra Series Bluetooth 5.3 Modules

Recommended for New Design (RND)

Overview

The newest addition to Ezurio's (formerly Laird Connectivity) extensive Bluetooth Low Energy product range is the Lyra Series, based on Silicon Labs EFR32BG22 SoC. This range of flexible modules marries all the benefits of Silicon Labs hardware, software, and tools offerings with Ezurio's added value application software, services, certification, and support capabilities. This seamless partnership provides customers with multiple software development options suited to their resources and skillsets in Bluetooth LE-enabled product development.

The Lyra Series includes small form factor PCB modules, as well as ultra-compact SIP options, to suit any host board footprint. Together, Silicon Labs and Ezurio, will drive down your total cost of ownership, design complexity and risk, whilst ensuring you the fastest time to market for your next Bluetooth LE-enabled IoT design.

Connect to any Wirepas 2.4 GHz mesh network, enabling fast and reliable deployment for your IoT project.

  • True industrial operating range: Designed and certified to the highest industrial temperature range of -40 ºC to +105 ºC for every component utilized.
  • Global approvals – make yourself at home: Carries several modular FCC, ISED, EU, UKCA, MIC, KC, and Bluetooth SIG approvals.
  • Low power operation for battery powered IoT: Intelligent power schemes, deep sleep mode, and low power consumption leads to long-performing IoT solutions even on a battery
  • Security features on EFR32BG22: Secure Boot, ARM Trustzone, Hardware Cryptographic Acceleration

Choose Hardware, Firmware, and Support

Lyra P - PCB Module

  • +8 dBm Output Power
  • 12.9 x 15.0 x 2.2 mm
  • Integrated Antenna

Lyra S - SIP Module

  • +6 dBm Output Power
  • 6 x 6 x 1.1 mm
  • Integrated antenna OR external via pinout
  • Pre-certified range of antennas
lyra-square.png
  • AT Command Set - Fully featured and extensible, proven over 5+ years. Simplest implementation with all key Wireless Xpress features, proven over 5 years
  • Wireless Xpress - Frozen at current release, path for existing Silicon Labs customers. Secure FOTA-capable firmware, Xpress command API for iOS/Android
  • C Code - Full software development with Silicon Labs SDK and toolchain. Use Simplicity Studio IDE for full functionality of Silicon Labs HW/SW
lyra-sw.png
  • Technical and application support for ALL available firmware options
  • Continuous development of AT Command Set – extensible for new features and customer requests
  • Multiple range of internal antennas, pre certified for all certification regions for Lyra S module.
  • Full Service options available  – Antenna, Engineering & Certification Services to support your project
Support.png

Development Kits

  • 453-00090-K1

    453-00090-K1

    Additional Description
    Development Board for Lyra P
    Antenna Type
    Integrated Antenna
    Logical Interfaces
    UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS
    Learn More
  • 453-00091-K1

    453-00091-K1

    Additional Description
    Development Board for Lyra S
    Antenna Type
    Integrated Antenna OR external via trace pin
    Logical Interfaces
    UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS
    Learn More

Certified Antennas

  • EBL2400A1-10MH4L

    EBL2400A1-10MH4L

    NanoBlue Series Bluetooth Internal Antenna
    Learn More
  • 001-0022

    001-0022

    FlexPIFA / FlexPIFA 6E Flexible Adhesive-Backed PIFA Internal Antennas
    Learn More
  • EFA2400A3S-10MH4L

    EFA2400A3S-10MH4L

    mFlexPIFA Flexible Adhesive-Backed PIFA Internal Antenna
    Learn More

Specifications

Bluetooth Version
5.3 Low Energy
Logical Interfaces
UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS
Chipset (Wireless)
Silicon Labs EFR32BG22
Certifications
FCC, ISED, CE, UKCA, MIC, KC, AS/NZS
Chipset (MCU)
ARM Cortex-M33
Dimensions
6 x 6 x 1.1 mm (SIP)
12.9 x 15.0 x 2.2 mm (PCB)
Memory
512 KB flash memory
32 KB RAM
Operating Temp (Max) (°C)
+105 °C
Operating Temp (Min) (°C)
-40 °C
Programming Options
AT Command Set, Silicon Labs Wireless Xpress, or Simplicity Studio
System Architecture
Hosted or Hostless
Part NumberAdditional DescriptionAntenna TypeBulk or SingleChipset (Wireless)Form FactorFrequency Range (Max)Frequency Range (Min)Logical InterfacesOS/SoftwarePackagingProduct TypeTechnology
Lyra P - PCB Module
453-00090CBuy Now
Lyra P Module, Cut / Tape Integrated Antenna Bulk Silicon Labs EFR32BG22 PCB Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Cut / Tape Embedded Module Bluetooth 5.3
Lyra P - PCB Module
453-00090RBuy Now
Lyra P Module, Tape / Reel Integrated Antenna Bulk Silicon Labs EFR32BG22 PCB Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Tape / Reel Embedded Module Bluetooth 5.3
Lyra S - SIP Module
453-00091CBuy Now
Lyra S Module, Cut / Tape Integrated Antenna OR external via trace pin Bulk Silicon Labs EFR32BG22 SIP Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Cut / Tape Embedded Module Bluetooth 5.3
Lyra S - SIP Module
453-00091RBuy Now
Lyra S Module, Tape / Reel Integrated Antenna OR external via trace pin Bulk Silicon Labs EFR32BG22 SIP Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Tape / Reel Embedded Module Bluetooth 5.3
Lyra P - PCB Module
453-00147CBuy Now
Lyra P Module, Cut / Tape, with Wireless Xpress Firmware Integrated Antenna Bulk Silicon Labs EFR32BG22 PCB Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Cut / Tape Embedded Module Bluetooth 5.3
Lyra P - PCB Module
453-00147RBuy Now
Lyra P Module, Tape / Reel, with Wireless Xpress Firmware Integrated Antenna Bulk Silicon Labs EFR32BG22 PCB Module 2480 MHz2400 MHzUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Tape / Reel Embedded Module Bluetooth 5.3

Documentation

Name Part Type Last Updated
Product Brief - Lyra Series All Product Brief 03/01/2023
3D Model - Lyra P (453-00090) All Technical Drawings 02/14/2022
3D Model - Lyra S (453-00091) All Technical Drawings 02/14/2022
PCB footprint (DXF and Altium format) - Lyra P All Technical Drawings 02/15/2022
PCB footprint (DXF and Altium format) - Lyra S All Technical Drawings 02/15/2022
SCH Symbols (Altium format) - Lyra P All Technical Drawings 02/15/2022
SCH Symbols (Altium format) - Lyra S All Technical Drawings 02/15/2022
Regulatory Information - Lyra P All Certification 08/11/2022
Regulatory Information - Lyra S All Certification 08/11/2022
Datasheet - Lyra P All Datasheet 03/03/2023
Datasheet - Lyra S All Datasheet 06/13/2022
3D Model - Lyra P Dev Board (453-00091-K1) All Technical Drawings 02/18/2022
3D Model - Lyra S Dev Board (453-00090-K1) All Technical Drawings 02/18/2022
User Guide - Bluetooth Xpress (BGX) Migration - Lyra Modules All Documentation 09/19/2022
Schematic & PCB Assembly - Lyra P Dev Board All Technical Drawings 06/10/2022
Schematic & PCB Assembly - Lyra S Dev Board All Technical Drawings 06/10/2022
User Guide - Lyra S Development Kit All Documentation 08/31/2022
User Guide - Lyra P Development Kit All Documentation 08/31/2022
User Guide - Firmware Options and Upgrading - Lyra 22/24 Series All Documentation 08/02/2023
Application Note - Using BGAPI Direct Test Mode - Lyra P All Application Note 10/04/2024
Application Note - Using BGAPI Direct Test Mode - Lyra S All Application Note 08/19/2022
Bluetooth Xpress (BGX) Online Documentation (External Link) All Documentation 06/13/2022
User Guide - Lyra Series C-Code Development All Documentation 06/16/2022
Application Note - How to Set Up vSP with AT Commands - Lyra and Lyra 24 Series All Application Note 08/16/2023
User Guide - AT Interface Application - Lyra 22/24 Series All Documentation 09/09/2024
Quick Start Guide - AT Command Set Firmware - Lyra Series All Documentation 08/19/2022
Application Note - Custom GATT Database with AT Command Set - Lyra Series All Application Note 08/19/2022
Firmware - Lyra Series (GitHub) All Software 08/18/2023
Release Notes - Lyra Series AT Command Firmware vX.3.1.173 All Documentation 10/05/2022
Lyra C Code Samples All Software 08/12/2022
Application Note - Configuring the EVK UART Baud Rate - Lyra 22/Lyra 24/RM126x All Application Note 09/15/2023
Quick Start Guide - AT Interface Application - Lyra 22/24 Series All Documentation 08/02/2023
Application Note - Peripheral Interface Guide - Lyra, Lyra 24, and RM126x Series All Application Note 06/10/2024
RoHS 3 - Bluetooth All Certification 01/11/2024

FAQ

Why are the source code files on the GitHub repository for the Lyra Series modules empty? Where can I access the source code?

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. 

Does Ezurio provide breakout boards for its Bluetooth modules?

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. 

I've connected my Lyra development board to my PC, but it does not show up in Simplicity Studio 5. What can I do?

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.

What is the Silicon Labs Proprietary Flex SDK and where can I find more information about it?

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.

Do you support a Remote Command Mode (or something similar) in your AT Interface app like Wireless Xpress?

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.

Is there a way in Simplicity Studio 5 to downgrade the Bluetooth Gecko SDK (GSDK) version?

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.

Do you provide support for the RM126x and Lyra development boards through the Simplicity Studio 5 Software & IDE?

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).

I would like to migrate from a BGX-based design and keep using Wireless Xpress. Is the Lyra (22) series pin-to-pin compatible with the BGX13 and/or BGX220?

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.

Do you support any echoing support in the AT Interface app / implementation such as ATE1 & ATE0 for example?

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.

Do you support User Functions (or something similar) in your AT Interface app like Wireless Xpress?

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.

Can I use or modify a Lyra development board to externally debug and flash Lyra modules?

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.

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?

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.

For programming and productions reasons, is there a way to merge or combine an existing bootloader and application hex image into a single file?

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

What is the „Simplicity Commander“ and where can I get it from?

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.

How can Lyra be configured for Regulatory testing if there is no UART access available?

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.

I’m interested in the source code of the Lyra AT Interface application and Wireless Xpress software solution. Where can I find, download, review and modify it?

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.

I'm using Wireless Xpress with Lyra (22) and found a bug or have a feature request, how can I share and report it to the Ezurio team?

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.

Is the Silicon Labs Wireless Xpress software solution also available for Lyra 24?

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.

Do I have to configure UART hardware flow control (RTS/CTS) on my Lyra development board first, or is it already enabled by default?

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.

Can I enable or disable UART hardware flow control (RTS/CTS) on my Lyra development board?

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.

When working with AT Interface firmware, what is the correct syntax to use the AT+LSCN command when not wanting to use all the optional parameters?

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

Can the Lyra P and Lyra S modules support Wirepas MESH?

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

 

Can Lyra series modules support BLE Mesh

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/

Why does it take so long for my VSP to establish a connection with a mobile device?

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.

Can Lyra support concurrent Peripheral and Central Roles when using AT Interface?

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. 

Does the BL5340, BL5340PA, BL65x and Lyra BLE modules include the DC-DC LC filters on the module?

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.

Does Lyra support a Multi-Central Topology as a Peripheral?

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.

How is a static passkey configured for use in AT Interface Application/Firmware?

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

Is the command used to set a static passkey with AT Interface firmware, AT+PKEY, persistent through a reset or power-cycle?

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 

Using STTY with the USB-SWD

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. 

Is there a way to distinguish between a BGX and Lyra module or device running Wireless Xpress in the field without having physical access to it?

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.

Does Lyra support Bluetooth LE Audio and/or the Low Complexity Communications Codec (LC3)?

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.

What is the difference between the Ezurio and legacy Bluetooth Xpress (BGX) bootloader you provide for Lyra?

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.

Bootloader Type BOOT Pin for Lyra P (PCB)
BOOT Pin for Lyra S (SIP)
Ezurio (Default) PC07 PA06
Legacy Bluetooth Xpress (BGX) PD02 PD02

Do you support Bluetooth features like BLE Mesh, AoA (Angle of Arrival) and/or Angle of Departure (AoD) in your own AT Command Set Interface implementation?

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.

Can I program and run your AT Command Set Interface firmware or the Wireless Xpress software solution from Silicon Labs on non-Lyra based devices?

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.

Is it possible to get pre-programmed Lyra parts from you?

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.

What are the factory states for your Lyra DVKs and modules?

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.

Is it possible to add the Bluetooth GATT Configuration utility to a NCP example project in Simplicity Studio 5?

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.

Does Lyra support the Matter Protocol?

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.

Do I need UART hardware flow control (RTS/CTS) with Lyra, and what is your recommendation?

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.

Where can I find regulatory documents, certificates, approvals and test reports for Lyra?

All regulatory documents, certificates, approvals and test reports for USA (FCC), Canada (ISED), United Kingdom (UKCA), Europe (CE), Japan (MIC/TELEC) and Korea (KC) will be shared upon request.

For both Lyra P and S modules, please reach out to your local sales representative or FAE. Otherwise, feel free to get in touch with our team under /support by opening a support ticket. We are also happy to assist you in this regard via email under support@lairdconnect.com.

Which Silicon Labs Bluetooth Stack and Gecko SDK (GSDK) version is the Lyra AT Interface application / implementation based on?

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:

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

Can I run with Lyra multiple firmware options simultaneously?

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.

What is the minimum / maximal supported baud rate value when using the Lyra AT Command Set Interface firmware and how can I modify it?

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.

Do Lyra modules support 802.15.4/Thread?

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.

How can I build my own UART DFU utility (also known as uart_dfu or bt_host_uart_dfu) under Windows and/or Linux?

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]

Why does the Software Development Selection Switch (SW1) on my Lyra development board look different?

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-S/D DVK Bottom View

Does Lyra S and Lyra P modules support SPI

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.

How to configure Packet Trace Interface for Bluetooth Low Energy traffic capture

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.

User-added image
 

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.

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

User-added image

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.

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

User-added image

PTI Launch

  1. Select the Admin tab and execute the following command.
      pti config 0 efruart 3200000

User-added image

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.

  1. Close the console.
  2. 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.
  3. 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.

User-added image

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

User-added image

How to: permanently securing the Lyra device

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 BootloaderApploader 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”

      User-added image

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

      User-added image

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

      User-added image

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

      User-added image

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

      User-added image

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

      User-added image

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

      User-added image

How to generate signed apploader and application firmware images using private key

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:

User-added image

How to add service UUID to advertising data of implemented by Silicon Labs adapted GATT service

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.

How to enable CMSIS-PACK support in IAR for Silicon Labs devices

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

User-added image     

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

User-added image

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]

User-added image

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

User-added image

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 soc_empty project

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

User-added image

 

  • Check IAR EMBEDDED WORKBENCH PROJECT option 

  • Push Save button 

User-added image

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

User-added image

How to generate GCC Makefile for soc_empty project

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

User-added image

  • Check GCC MAKEFILE option 
  • Push Save button 

User-added image

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

User-added image

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.    

Firmware update of the application image using Segger J-Link and SWD interface

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 

User-added image

Firmware update of the bootloader using Segger J-Link and SWD interface

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 

Steps to generate bootloader using Simplicity Studio for Lyra BLE modules

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 ] -> StartSimplicity Studio USB connection
  • Select “Technology type” “Bootloader” from “Example Projects & Demos” tab:

  User-added image

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

     User-added image
  • Assign the name to the Bootloader projects once the New Project Wizard is opened:

User-added image

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

User-added image

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

User-added image

  • 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  

Firmware update over UART using UART XMODEM Bootloader

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:

User-added image

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

User-added image

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

User-added image

 

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

Firmware update over UART using BGAPI UART DFU Bootloader

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 scriptsThe 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:
User-added image 
  • 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:

    User-added image 

 Summary:

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

How to build, debug bootloader project for Lyra modules

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:

 User-added image
 

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()

 User-added image

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.  

How to flash images to the Lyra device using commander utility

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. 

How to generate public and private keys using Simplicity Studio Commander

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

How to store public key into device Flash

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.

How to generate signed bootloader image using private key

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. 

Description for GEKO bootloader files and security keys, which are generated for Lyra device

Please find below the naming description of:

  • Signed and unsigned binaries of the Bootloader. 
  • Unsigned images of ApploaderApplication.
  • 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 BootloaderApploader 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.

How to perform OTA update of Lyra devices using EFR Connect

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.gblapplication.gblapploader.gbl, apploader-signed.gblfull.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.

 

Silicon Labs Bluetooth Stack Features for Lyra Devices

Feature Description
Bluetooth SIG version Bluetooth(BT) 5.2
Bluetooth features

BT 5.2 GATT caching
BT 5 2M PHY 
BT 5 LE Long Range
BT 5 advertisements (ADV) sets and scan event reporting
BT 5 extended ADV/s

  1. Anonymous ADV
  2. Periodic ADV
  3. Extended ADV packet size: up to 1650 B 

Concurrent central, peripheral, broadcaster, and observer modes LE secure connections
LE Privacy 1.2 (peripheral) LE packet length extensions LE dual topology
Whitelisting (central side only)
LE Power Control

Simultaneous connections Up to 32 Simultaneous connections  regardless of role (master or slave)
Maximum throughput 1300 kbps over 2M PHY
700 kbps over 1M PHY
Encryption AES-128
Pairing modes Just works, Man-in-the-Middle with numeric comparison and passkey Out-Of-Band
Number of simultaneous bondings Up to 32 
Link Layer packet size Up to 251 B
ATT protocol packet size Up to 250 B
Support BT profiles and services All GATT based profiles and services are supported
Apple HomeKit Apple HomeKit R15-complant implementation, which implements all Apple HomeKit profiles and services. The HomeKit SDK is available separately for Apple MFI licensees
Host (NCP) interfaces 4-wire UART with RTS/CTS control or 2-wire UART w/o RTS/CTS
GPIO/s for sleep and wakeup power management
Wi-Fi Coexistence Using Packet Trace Arbitration (PTA)
Bootloader Secure Gecko Bootloader supporting authenticated and encrypted updates over OTA or UART and Secure Boot.
The Gecko Bootloader also supports flash partitioning for both internal and external SPI flash types.
Non-volatile memory NVM3

 

 

  

 

TX Power Limitations on Lyra devices for Regulatory Compliance (ETSI, FCC)

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.
 

Power Limits w/o AFH EIRP [dBm] EIRP [dBm]
   125 kbps coded PHY 500 kbps, 1Mbps and 2 Mbps
FCC 14 30
ETSI 10 10
Supported by stack 10 10

 

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.

Power Limits w/ AFH EIRP [dBm] EIRP [dBm] EIRP [dBm]
  channel 37 channel 38 all other channels
FCC 18 15.3 30
ETSI 20 20 20
Supported by stack 18 15.3 20

 

Extended list of code examples for Lyra devices

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

Firmware development - extending SOC EMPTY project

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

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

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 BrowserUser-added image
  3. Find the device advertising as "Empty Example". Select  ConnectUser-added image
  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 User-added image

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    

Resource Center

Become an Ezurio Customer to Gain Exclusive Access to Our Design Experts

  • Antenna Scans
  • Antenna selection and placement
  • Custom antenna design
  • Worldwide EMC testing / certifications
  • Embedded RF hardware / firmware design
  • Cloud architecture and integration
  • Mobile application development
  • Product & Industrial Design

Talk to an Expert

Buy Now

Distributor Part In Stock Region Buy
Mouser 453-00090-K1 75 North America Buy Now
Mouser 453-00090-K1 64 North America Buy Now
DigiKey 453-00090-K1 52 North America Buy Now
Arrow Electronics 453-00090-K1 26 North America Buy Now
Farnell 453-00090-K1 23 EMEA Buy Now
Arrow Electronics 453-00090-K1 0 North America Buy Now
Avnet 453-00090-K1 0 North America Buy Now
Future Electronics 453-00090-K1 0 North America Buy Now
DigiKey 453-00090C 389 North America Buy Now
Mouser 453-00090C 264 North America Buy Now
Farnell 453-00090C 55 EMEA Buy Now
Farnell 453-00090C 55 EMEA Buy Now
Farnell 453-00090C 55 EMEA Buy Now
Farnell 453-00090C 55 EMEA Buy Now
Arrow Electronics 453-00090C 0 North America Buy Now
Avnet 453-00090C 0 North America Buy Now
Future Electronics 453-00090C 0 North America Buy Now
Mouser 453-00090R 3463 North America Buy Now
DigiKey 453-00090R 1639 North America Buy Now
DigiKey 453-00090R 1639 North America Buy Now
DigiKey 453-00090R 1000 North America Buy Now
Farnell 453-00090R 858 EMEA Buy Now
Farnell 453-00090R 858 EMEA Buy Now
Farnell 453-00090R 858 EMEA Buy Now
Farnell 453-00090R 858 EMEA Buy Now
Arrow Electronics 453-00090R 0 North America Buy Now
Avnet 453-00090R 0 North America Buy Now
Future Electronics 453-00090R 0 North America Buy Now
Mouser 453-00091-K1 124 North America Buy Now
DigiKey 453-00091-K1 48 North America Buy Now
Farnell 453-00091-K1 29 EMEA Buy Now
Farnell 453-00091-K1 29 EMEA Buy Now
Arrow Electronics 453-00091-K1 2 North America Buy Now
Avnet 453-00091-K1 0 North America Buy Now
Future Electronics 453-00091-K1 0 North America Buy Now
Mouser 453-00091C 2339 North America Buy Now
Mouser 453-00091C 2157 North America Buy Now
Farnell 453-00091C 625 EMEA Buy Now
Farnell 453-00091C 625 EMEA Buy Now
Arrow Electronics 453-00091C 0 North America Buy Now
Avnet 453-00091C 0 North America Buy Now
Future Electronics 453-00091C 0 North America Buy Now
Mouser 453-00091R 5565 North America Buy Now
Mouser 453-00091R 2660 North America Buy Now
DigiKey 453-00091R 2173 North America Buy Now
DigiKey 453-00091R 2173 North America Buy Now
Farnell 453-00091R 2087 EMEA Buy Now
Farnell 453-00091R 2087 EMEA Buy Now
DigiKey 453-00091R 1795 North America Buy Now
Arrow Electronics 453-00091R 0 North America Buy Now
Avnet 453-00091R 0 North America Buy Now
Future Electronics 453-00091R 0 North America Buy Now
Mouser 453-00147C 2178 North America Buy Now
Arrow Electronics 453-00147C 0 North America Buy Now
Avnet 453-00147C 0 North America Buy Now
Mouser 453-00147R 1452 North America Buy Now
DigiKey 453-00147R 418 North America Buy Now
DigiKey 453-00147R 418 North America Buy Now
Arrow Electronics 453-00147R 0 North America Buy Now
Avnet 453-00147R 0 North America Buy Now

Distributors

Distributor Phone Number Region Website
Arrow Electronics 1-855-326-4757
+44 2039 365486
APAC, North America, South America, EMEA Website
Avnet 1-480-643-2000
+44 1628 512900
APAC, North America, South America, EMEA Website
Braemac Australia, New Zealand, South East Asia +61 2 9550 6600
+64 9 477 2148
APAC Website
Cal-Chip Connect 1-215-942-8900
North America Website
DigiKey 1-800-344-4539
North America, South America, APAC, EMEA Website
EBV Elektronik EMEA Website
Farlink Technology China, Hong Kong +86 13266922199
APAC Website
Farnell 1-800-936-198
+44 3447 11 11 22
EMEA Website
Future Electronics 1-800-675-1619
1-514-428-8470
North America, South America, APAC, EMEA Website
Glyn +49-6126-590-0
EMEA Website
Hy-Line Germany Only +49 89 614 503 0
EMEA Website
Jetronic China, Hong Kong and Taiwan 852-27636806 
APAC Website
Laird Connectivity 1-847-839-6925
+44 1628 858941
North America, South America, APAC, EMEA Website
M2M Germany +49-6081-587386-0
EMEA Website
Martinsson +46 8 7440300
EMEA Website
McCoy South East Asia +65 6515 2988
APAC Website
Mouser 1-800-346-6873
+44 1494 427500
North America, South America, APAC, EMEA Website
RS Components +852-2421-9898
+44 3457-201201
North America, South America, APAC, EMEA Website
Ryoyo Japan +81-3-3543-7711
APAC Website
Solsta UK Only +44 (0) 1527 830800
EMEA Website
Supreme Components International India, South East Asia +65 6848-1178
APAC Website
Symmetry Electronics 1-866-506-8829
North America Website
Tekdis Australia and New Zealand +61 3 8669 1210
APAC Website
Telsys +972 3 7657666
EMEA Website
WPG +44 1628 958460
EMEA Website