Lyra Series Bluetooth 5.3 Modules

Under Development

Overview

The newest addition to Laird Connectivity’s 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 Laird Connectivity’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 Laird Connectivity, 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.

  • 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

Register for a Chance to Win a Lyra DVK!

The Lyra S and Lyra P development kits are a reliable, flexible route to prototyping your wireless design. Supporting the full range of our firmware development options and exposing the full capabilities of the Lyra modules, the Lyra DVKs drive down design complexity and risk and ensure the fastest time to market for your Bluetooth LE-enabled IoT design. 

Register below for a chance to win one of ten free samples of the Lyra development kits!

Sign Up

Lyra P and Lyra S Development Boards

Specifications

Bluetooth Version
5.3 Low Energy
Programming Options
AT Command Set, Silicon Labs Wireless Xpress, or Simplicity Studio
Dimensions
6 x 6 x 1.1 mm (SIP)
12.9 x 15.0 x 2.2 mm (PCB)
Chipset (MCU)
ARM Cortex-M33
Chipset (Wireless)
Silicon Labs EFR32BG22
Logical Interfaces
UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS
Memory
512 KB flash memory
32 KB RAM
Operating Temp (Max) (°C)
105 °C
Operating Temp (Min) (°C)
-40 °C
System Architecture
Hosted or Hostless
Antenna Type Bulk or Single Chipset (Wireless) Form Factor Frequency Range (Min) Frequency Range (Max) Logical Interfaces OS/Software Packaging Product Type Technology Additional Description
453-00090-K1 Integrated Antenna Single Silicon Labs EFR32BG22 Development Board 2400 MHz 2480 MHz UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Single Development Kit Bluetooth 5.3 Development Board for Lyra P
Product Type Technology OS/Software Chipset (Wireless) Antenna Type Logical Interfaces Frequency Range (Min) Frequency Range (Max) Bulk or Single Packaging Form Factor Additional Description
453-00090C Embedded Module Bluetooth 5.3 AT Commands, Wireless Xpress, Simplicity Studio Silicon Labs EFR32BG22 Integrated Antenna UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS 2400 MHz 2480 MHz Bulk Cut / Tape PCB Module Lyra P Module, Cut / Tape
Product Type Technology OS/Software Chipset (Wireless) Antenna Type Logical Interfaces Frequency Range (Min) Frequency Range (Max) Bulk or Single Packaging Form Factor Additional Description
453-00090R Embedded Module Bluetooth 5.3 AT Commands, Wireless Xpress, Simplicity Studio Silicon Labs EFR32BG22 Integrated Antenna UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS 2400 MHz 2480 MHz Bulk Tape / Reel PCB Module Lyra P Module, Tape / Reel
Antenna Type Bulk or Single Chipset (Wireless) Form Factor Frequency Range (Min) Frequency Range (Max) Logical Interfaces OS/Software Packaging Product Type Technology Additional Description
453-00091-K1 Integrated Antenna OR external via trace pin Single Silicon Labs EFR32BG22 Development Board 2400 MHz 2480 MHz UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS AT Commands, Wireless Xpress, Simplicity Studio Single Development Kit Bluetooth 5.3 Development Board for Lyra S
Product Type Technology OS/Software Chipset (Wireless) Antenna Type Logical Interfaces Frequency Range (Min) Frequency Range (Max) Bulk or Single Packaging Form Factor Additional Description
453-00091C Embedded Module Bluetooth 5.3 AT Commands, Wireless Xpress, Simplicity Studio Silicon Labs EFR32BG22 Integrated Antenna OR external via trace pin UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS 2400 MHz 2480 MHz Bulk Cut / Tape SIP Module Lyra S Module, Cut / Tape
Product Type Technology OS/Software Chipset (Wireless) Antenna Type Logical Interfaces Frequency Range (Min) Frequency Range (Max) Bulk or Single Packaging Form Factor Additional Description
453-00091R Embedded Module Bluetooth 5.3 AT Commands, Wireless Xpress, Simplicity Studio Silicon Labs EFR32BG22 Integrated Antenna OR external via trace pin UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS 2400 MHz 2480 MHz Bulk Tape / Reel SIP Module Lyra S Module, Tape / Reel

Photo Gallery

453-00090R

453-00091R

453-00090C

453-00091C

453-00090-K1

453-00091-K1

Certified Antennas

  • Nano Blue Series - Bluetooth Internal

    EBL2400A1-10MH4L

    NanoBlue Series Bluetooth Internal Antenna

    2.4 GHz planar antenna with 2 dBi of Gain and an integrated ground plane for ease of integration.

    Learn More
  • FlexPIFA and FlexPIFA 6E

    001-0022

    FlexPIFA / FlexPIFA 6E Flexible Adhesive-Backed PIFA Internal Antennas

    Industry-first, flexible, planar inverted-F antennas for curved surfaces.

    2.5-3 dBi gain.

    Available in 2.4 GHz, dual-band 2.4/5 GHz and Wi-Fi 6E 2.4/5/6 GHz.

    Learn More
  • mFlexPIFA Antenna

    EFA2400A3S-10MH4L

    mFlexPIFA Flexible Adhesive-Backed PIFA Internal Antenna

    FlexPIFA antenna for metal mounting with minimal detuning. 2.4 GHz and dual-band 2.4/5.5 GHz with 2 dBi of gain. 

    Learn More

Become a Laird Connectivity Customer and Gain Exclusive Access to Our Design Services Team

  • 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

Documentation

Name Part Type Last Updated
Product Brief - Lyra Series All Product Brief 02/18/2022
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 02/25/2022
Regulatory Information - Lyra S All Certification 02/25/2022
Datasheet - Lyra P All Documentation 02/18/2022
Datasheet - Lyra S All Documentation 02/18/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 - Flashing Bluetooth Xpress Firmware - Lyra Modules All Documentation 05/13/2022
Schematic & PCB Assembly - Lyra P Dev Board All Technical Drawings 04/27/2022
Schematic & PCB Assembly - Lyra S Dev Board All Technical Drawings 04/27/2022
User Guide - Lyra S Development Kit All Documentation 04/27/2022
User Guide - Lyra P Development Kit All Documentation 04/27/2022
User Guide - Firmware Options and Upgrading - Lyra Series All Documentation 05/03/2022

FAQ

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.

 

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

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

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.  

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.

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

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.    

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

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 

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

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.

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

 

 

  

 

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  

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

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

 

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