Lyra Series Bluetooth 5.3 Modules
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
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

- 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

- 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

Specifications
12.9 x 15.0 x 2.2 mm (PCB)
32 KB RAM
Part Number | Additional Description | Antenna Type | Bulk or Single | Chipset (Wireless) | Form Factor | Frequency Range (Max) | Frequency Range (Min) | Logical Interfaces | OS/Software | Packaging | Product Type | Technology |
---|---|---|---|---|---|---|---|---|---|---|---|---|
453-00090RBuy Now | Lyra P Module, Tape / Reel | Integrated Antenna | Bulk | Silicon Labs EFR32BG22 | PCB Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Tape / Reel | Embedded Module | Bluetooth 5.3 |
453-00091RBuy Now | Lyra S Module, Tape / Reel | Integrated Antenna OR external via trace pin | Bulk | Silicon Labs EFR32BG22 | SIP Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Tape / Reel | Embedded Module | Bluetooth 5.3 |
453-00090CBuy Now | Lyra P Module, Cut / Tape | Integrated Antenna | Bulk | Silicon Labs EFR32BG22 | PCB Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Cut / Tape | Embedded Module | Bluetooth 5.3 |
453-00091CBuy Now | Lyra S Module, Cut / Tape | Integrated Antenna OR external via trace pin | Bulk | Silicon Labs EFR32BG22 | SIP Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Cut / Tape | Embedded Module | Bluetooth 5.3 |
453-00147RBuy Now | Lyra P Module, Tape / Reel, with Wireless Xpress Firmware | Integrated Antenna | Bulk | Silicon Labs EFR32BG22 | PCB Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Tape / Reel | Embedded Module | Bluetooth 5.3 |
453-00147CBuy Now | Lyra P Module, Cut / Tape, with Wireless Xpress Firmware | Integrated Antenna | Bulk | Silicon Labs EFR32BG22 | PCB Module | 2480 MHz | 2400 MHz | UART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS | AT Commands, Wireless Xpress, Simplicity Studio | Cut / Tape | Embedded Module | Bluetooth 5.3 |
Development Kits
-
453-00090-K1
Additional DescriptionDevelopment Board for Lyra PAntenna TypeIntegrated AntennaLogical InterfacesUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS -
453-00091-K1
Additional DescriptionDevelopment Board for Lyra SAntenna TypeIntegrated Antenna OR external via trace pinLogical InterfacesUART, I2C, SPI, ADC, GPIO, PWM, PDM, Counter, Timer, Watchdog, PRS
Documentation
Certified Antennas
Can Lyra series modules support BLE Mesh
The
Silabs chipset from which Lyra series are designed (EFR32BGXX) does indeed
support BLE Mesh protocol. However, Laird Connectivity 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.
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 Laird Connectivity module you are working with linked below:
User Guide - AT Interface Application - Lyra Series
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.
- 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.
- 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).
- (Optional) Assign the device name to a variable, for example "DEVICE=/dev/ttyACM0".
- Configure "stty" to talk with the device "stty -F $DEVICE 115200 -echo -echoe -echok"
- 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.
- 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.
- (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 Laird Connectivity 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 Laird Connectivity 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 Laird Connectivity and legacy Bluetooth Xpress (BGX) bootloader you provide for Lyra?
In addition to the standard Laird Connectivity 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 Laird Connectivity 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 Laird Connectivity 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) |
---|---|---|
Laird Connectivity (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 Laird Connectivity 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.
Can I disable hardware flow control (RTS/CTS) on the Lyra Development Kit?
Addition to the regular RX (Receive) and TX (Transmit) pins, 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 later Lyra designs.
Hardware flow control (also know 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.
If needed, you can disable UART hardware flow control for your Lyra Development Kit 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 without having UART hardware flow control in place or active.
In Simplicity Studio 5 go to the Launcher page in the Debug Adapters view and right click on your Lyra Development Kit (ID:XXXXXXXXX). Select Launch Console and open the Admin tab. Now type "serial vcom config handshake disable". Please make sure to reset or power cycle your Lyra Development Kit once the settings have been applied. The default settings can be restored with the "serial vcom config handshake auto" command at any time.
Where can I find regulatory documents, certificates, approvals and test reports for Lyra?
|
Which Bluetooth Stack version is your Lyra AT Command Set Interface firmware implementation based on?
Laird Connectivity's AT Command Set Interface firmware implementation for Lyra is purely based on the Silicon Labs Gecko SDK (GSDK) version 3.2.3.0.
Please refer here for the Gecko Platform 3.2.3.0 GA release notes document. Additional information can be also found under https://www.silabs.com/developers/gecko-software-development-kit.
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\
- 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.
- 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.
- 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.
- 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.
- 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/
- 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.
- 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.
- 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.
- 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.
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.
- Open the .slcp file (Project Configurator) of the previously created project.
- Go to the Software Components tab.
- Click on the Platform -> Radio -> RAIL Utility, PTI component.
- Click on the Configure button.
PTI Component
The baud rate is selectable. The default baud rate is 1.6 Mbps. The maximum baud rate is 3.2 Mbps.
Note: when using 2M PHY with Bluetooth Low Energy, the default PTI-over-UART speed (1.6 Mbps) should be increased to a higher baud rate.
- Change the PTI Baud Rate (Hertz) field from 1600000 default to 3200000:
PTI Baud
Additionally, the speed at which the PTI frames are forwarded from the Lyra device back to USB/UART must also be increased by setting the PTI config corresponding to your adapter at the correct baud rate through the Admin Console interface.
- Right click on the device in the Debug Adapters view and select Launch Console
PTI Launch
- Select the Admin tab and execute the following command.
pti config 0 efruart 3200000
PTI Admin
This command will configure the debug adapter part of the Lyra DVK. Note that erasing or flashing the target does not have any effect on this configuration.
- Close the console.
- 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.
- Flash the application image to your device by going into the project explorer tab. In your project root folder, in the binaries folder, click on the drop down arrow and right click on "soc_empty.hex" -> Flash to device.
11. Click on the Program button in the pop-up window to start the programming:
How to: permanently securing the Lyra device
How to: permanently securing the Lyra device
Description:
The First Stage Bootloader Checker needs the Silicon Labs public key to verify the First Stage Bootloader. This was already burned into the ROM of the device at the Factory.
However, the First and Second Stage Bootloaders require the final product public key to verify the signature of any signed firmware images. This public key can be found in the files signing-key.pub and signing-key-tokens.txt. This key needs to be flashed into the device by the final product maker.
The commands below will permanently make your device secure. However, it will always require future software updates to be signed by the exact same private signing-key.
You may want to skip this step, knowing that you are preventing the device from having a complete Chain-of-Trust. Without the key stored in OTP memory, the First Stage Bootloader will not check the signature of future Second Stage Bootloader. This will allow you to reuse the chip with future projects by erasing the full-device along with the final product public key stored in flash.
If you choose to complete this section, you will need to use the same private key to sign future Second Stage Bootloader, Apploader and Application images.
-
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
-
Enable First Stage Bootloader to use Secure Boot to authenticate Second Stage Bootloader
-
Open the “Device Configuration”
-
Select the “Security Settings” tab, click “Read from Device”, and "Start Provisioning Wizard" to enable secure boot in the First Stage Bootloader
-
Enable irrevocable write data operation for OTP for public key. Alternatively, version number and certificate verification flags can be set, click Next:
-
In the “Security Keys” window you will notice that the sign key is already filled in, click Next:
-
Use the default settings in the “Secure Locks” dialog:
-
Review the summary, click “Provision” to continue, and then click “Yes” to complete changing the security settings:
-
At the “Security Settings” tab, you can verify success by reading “Secure Boot: Enabled” after completing the above steps:
-
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:
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
A popup will appear asking if you want to enable the CMSIS manager for the project, say yes
When the CMSIS Manager opens select the Device tab and under Silicon Labs see if there are any entries for the BGM22 Series. If not there might be entries for EFR32BG22 parts or else select [Help] > [Check for Updates]
From the Devices tab, select the EFR32BG22 or BGM22 group and then select the [Packs] tab and there should be a Silicon Labs.GeckoPlatform_EFR32BG22_DFP package. If not click the blue Refresh icon in the upper right. There should be a grey Install icon available, click that to install the support package
Once the CMSIS-PACK is installed the IAR tools are extended and ready yo be used to support Silicon Labs devices from BGM220 family
How to generate IAR 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
-
Check IAR EMBEDDED WORKBENCH PROJECT option
- Push Save button
Once the IAR project files were generated, the IAR IDE can be launch by clicking the *.eww inside or outside of the Simplicity Studio as needed:
- “IAR EMBEDDED WORKBENCH PROJECT” option generates three files (*.ewd, *.ewp, *.eww)
- The path to the location of the project and IAR files are at Resource Location property. To obtain the location please right click on the project -> Properties
How to generate GCC Makefile for 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
- Check GCC MAKEFILE option
- Push Save button
Once the Makefiles were generated, they can be updated outside of the Simplicity Studio as needed:
- “GCC Makefile” option generates two files (*.Makefile and *.mak)
- The path to the location of the project and makefiles are at Resource Location property. To open please right click on the project -> Properties
Summary
The project can be built with “make -f *.Makefile …” command from “Command Prompt” or using Cigwin on windows. Other platforms: iOS, Linux support “make” command natively.
The “make” utility generates: *.hex, and *.bin files which are firmware executables. They can be loaded to the internal flash using SWD interface, bootloader UART interface or other methods.
Please note that bootloader UART interface accepting firmware image in [GBL] format and generated by Make utility files should be converted before using this method.
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
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 ] -> Start)
- Select “Technology type” “Bootloader” from “Example Projects & Demos” tab:
-
Import one of the Bootloader projects from the “resources found” list by clicking “Create” of the resources:
- Assign the name to the Bootloader projects once the New Project Wizard is opened:
- Update and save *.hwconf and *.isc files as requested for the project.
- From the *.isc file configuration interface click on "Generate" for project generation:
- Upon successfully completing the generation of the project, Simplicity Studio will output the "Generation successful" message with the list of generated, updated and unmodified files, please save this info and click "OK" to continue:
-
The project is ready to be built, debugged and tested. In addition, the Bootloader binary can be loaded to the internal flash location @ address: 0x00 of the module using J-Link Segger utility
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:
- Select “1” for uploading [GBL]
- Send the application image [GBL] file using XMODEM protocol, example below for TeraTerm
- Once the update is completed, to test the BLE application(example: soc-empty) please used mobile application (e.g.: nRFConnect, EFRConnect). The device should be advertising with “Empty Example” device name if soc-empty project produced firmware was used for update without any additional modifications. The device name can be updated in the soc-empty project using GATT configurator as shown:
Summary:
The steps above prove with basic usage information on utilizing UART XMODEM BOOTLOADER for modifying the firmware application partition of the internal flash of BGM220P and BGM220S module
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:
- ./uart_dfu.exe - name of the application
- COM42 - serial communication port of the connected DVK
- 115200 - serial port baud rate
- full.gbl - Geko Bootloader file [GBL]. This file is generated by running the create_bl_files.bat/.sh scripts. The script is included into soc-empty project templated that is provided by Simplicity studio. For testing please use soc-empty template project from Simplicity studio for experimenting and creating the GBL file
- The utility generates the following message upon successful application update completion:
-
Once the update is completed, to test the BLE application(example: soc-empty) please used mobile application (e.g.: nRFConnect, EFRConnect). The device should be advertising with “Empty Example” device name if soc-empty project produced firmware was used for update without any additional modifications. The device name can be updated in the soc-empty project using GATT configurator as shown:
Summary:
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:
The program will be halted by debug session at main() and the debugging procedures can be started. The program execution can be resumed by pressing “Resume” button. The following screen indicates that program was launched and halted at main()
Summary:
The basic steps which are described above can help with getting stated with debugging the bootloader template provided by Silicon Labs. In addition, it can support maintaining the exiting functions and developing a new procedures where firmware troubleshooting is required.
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 Bootloader, Apploader and Application firmware images received in the future. The key tokens come in an X,Y pair.
- signing-key - file is in a Privacy Enhanced Mail (PEM) format. This is common for certificates in Web servers and was used for storing the private keys. This cannot be discovered by other users. If others gain access to the private key, they could generate images that the device would validate using the public keys generated by this private key. The private key should be securely stored.
- signing-key.pub - file contains the public key that can be used to verify that the GBL files were generated by the correct private key. If you were to verify the OTA upgrade on another platform, like a gateway or smartphone app, they would likely consume this PEM-encoded public key file.
Note: Hardware Security Module (HSM) is recommended for key generation in production environment, storage, and image signing. HSM provides with strong protection of sensitive data. According to the instructions from the HSM vendor, have it generate an ECDSA-P256 key pair and export the public key in PEM format to the file signing-key.pub. Then use Simplicity Studio commander to convert the key to token format, suitable for writing to the EFR32BG22 device using the following command:
commander gbl keyconvert --type ecc-p256 signing-key.pub --outfile signing-key-tokens.txt
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 Apploader, Application.
- Other GBL files.
- The script for creating the GBL files targeting both platforms Linux and Windows.
- The public and private keys, that are used for signing the images.
The following list describes the files:
signing-key-tokens.txt - file is used by commander to program devices during manufacturing. The tokens are generated from the specific private keys, so there is no issue with outsiders using these public tokens to generate malware. However, these tokens are used by the chip to validate signed images for Second Stage Bootloader, Apploader and Application firmware images received in the future. The key tokens come in an X,Y pair.
signing-key - file is in a Privacy Enhanced Mail (PEM) format. This is common for certificates in Web servers and was used for storing the private keys. This cannot be discovered by other users. If others gain access to the private key, they could generate images that the device would validate using the public keys generated by this private key. The private key should be securely stored. This file was used to sign bootloader image.
signing-key.pub - file contains the public key that can be used to verify that the GBL files were generated by the correct private key. If you were to verify the OTA upgrade on another platform, like a gateway or smartphone app, they would likely consume this PEM-encoded public key file.
app-sign-key.pem - this file is identical to signing-key file and was used to sign the Apploader and Application images.
create_bl_files.sh - script is targeting Linux platform and included in soc-empty template. It creates GBL signed and unsigned files.
create_bl_files.bat - script is targeting Windows platform and included in soc-empty template. It creates GBL signed and unsigned files.
application.gbl - unsigned GBL file for soc-empty application.
application-signed.gbl - signed GBL file for soc-empty application.
apploader.gbl - unsigned GBL file for Apploader.
apploader-signed.gbl - signed GBL file for Apploader.
full.gbl - unsigned GBL file for Apploader and soc-empty Application.
full-signed.gbl - signed GBL file for Apploader and soc-empty Application.
bootloader-storage-internal-single-512k.axf/bin/hex/s37/-crc.s37 - second stage bootloader unsigned image in different formats including CRC.
bootloader-storage-internal-single-512k-signed.s37 - second stage bootloader signed S-record image.
soc-empty.axf/bin/hex/s37 - soc-empty unsigned image in different formats.
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.gbl, application.gbl, apploader.gbl, apploader-signed.gbl, full.gbl, and full-signed.gbl to Dropbox cloud storage for example.
- Run EFR Connect to perform the OTA procedure, please experiment with partial, full signed images for successful updates and to initiate the failed update use unsigned images.
Silicon Labs Bluetooth Stack Features for Lyra Devices
Feature | Description |
---|---|
Bluetooth SIG version | Bluetooth(BT) 5.2 |
Bluetooth features |
BT 5.2 GATT caching
Concurrent central, peripheral, broadcaster, and observer modes LE secure connections |
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
- Simplicity Studio IDE v5 or higher
- Bluetooth SDK 3.2.1 or higher
Connection
Use the micro USB cable provided in the Lyra DVK and attach it to PC USB slot and the micro USB connector on the DVK
Building and running the firmware
Please launch Simplicity Studio IDE and import the SoC Empty project template:
- File->New->Silicon Labs Project Wizard...
- Assign Target:
- Boards[BGM220 Explorer Kit Board (BRD4314A)]
- Device[BGM220PC22HNA]
- 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]
- 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
- Download the EFR Connect for iOS or Android smartphone
- Open the app and choose the Bluetooth Browser
- Find the device advertising as "Empty Example". Select Connect
- The connection is opened, and the GATT database is discovered. Find the device name characteristic under Generic Access service and try to read out the device name. It should return Empty Example
Note:
The MCU might not halt at main() if the bootloader location on the Flash was erased. In order to recover from this error, the bootloader should be loaded to address#0 using the j-link utility command: loadfile bootloader.hex 0
What is Laird Connectivity's product lifecycle EOL and PCN policy?
Laird Connectivity is committed to the long-term supply of all its standard embedded wireless modules and packaged products. Laird Connectivity’s products are specifically designed to meet the needs of the industrial and medical markets, which typically require 7 – 10 years product lifecycle. Although Laird Connectivity can’t guarantee that a component used in our products will not be obsoleted and cannot be reasonably substituted, Laird Connectivity can assure customers we will continue to sell our product when we have customer demand and can obtain the necessary components to build our products.
Resource Center
-
Future Proof Your Next Generation Bluetooth LE design – Capable, Flexible and Secure - The Lyra 24
An informative webinar on the Lyra 24 family utilizing Silicon Labs EFR32BG24 SoC, designed to empower your next generation Bluetooth Low Energy (LE) projects.
-
Introduction - Lyra Series Bluetooth 5.3 Modules
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...
-
Laird Connectivity Extends Global Partnership with Silicon Labs Announcing the Lyra 24 Series
Next Generation Bluetooth LE for Advanced IoT Device Development
-
Lyra Series – GA2 Release Notes - Additional Information for Customers
A brief walkthrough of new features and resolved issues in our latest GA2 firmware release for the Lyra series.
-
Lyra Series: Frequently Asked Questions
A short list of the most commonly-asked questions about getting started with our Lyra Series Bluetooth 5.3 modules.
-
Our Lyra24 Partnership with Silicon Labs
Discussing the value we add to Silicon Labs' hardware in our Lyra24 Bluetooth modules.
-
Unboxing the Lyra Series Development Kits
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...
-
Using External Antennas with the Lyra S DVK
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...
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
Buy Now
Distributor | Part | In Stock | Region | Buy |
---|---|---|---|---|
Mouser | 453-00090-K1 | 102 | North America | Buy Now |
Avnet | 453-00090-K1 | 30 | North America | Buy Now |
Future Electronics | 453-00090-K1 | 30 | North America | Buy Now |
DigiKey | 453-00090-K1 | 29 | North America | Buy Now |
Farnell | 453-00090-K1 | 28 | EMEA | Buy Now |
Newark | 453-00090-K1 | 28 | North America | Buy Now |
Symmetry Electronics | 453-00090-K1 | 28 | North America | Buy Now |
element14 APAC | 453-00090-K1 | 28 | APAC | Buy Now |
Classic Components | 453-00090-K1 | 23 | North America | Buy Now |
Symmetry Electronics | 453-00090C | 1000 | North America | Buy Now |
Jak Electronics | 453-00090C | 543 | APAC | Buy Now |
Utmel Electronic | 453-00090C | 461 | APAC | Buy Now |
Mouser | 453-00090C | 454 | North America | Buy Now |
Avnet | 453-00090C | 300 | North America | Buy Now |
Farnell | 453-00090C | 250 | EMEA | Buy Now |
Farnell | 453-00090C | 250 | EMEA | Buy Now |
Newark | 453-00090C | 250 | North America | Buy Now |
element14 APAC | 453-00090C | 250 | APAC | Buy Now |
element14 APAC | 453-00090C | 250 | APAC | Buy Now |
Chip One Stop | 453-00090C | 220 | APAC | Buy Now |
Classic Components | 453-00090C | 193 | North America | Buy Now |
DigiKey | 453-00090C | 11 | North America | Buy Now |
Future Electronics | 453-00090C | 0 | North America | Buy Now |
Jak Electronics | 453-00090R | 3023 | APAC | Buy Now |
Mouser | 453-00090R | 2548 | North America | Buy Now |
Utmel Electronic | 453-00090R | 2180 | APAC | Buy Now |
Avnet | 453-00090R | 1000 | North America | Buy Now |
Farnell | 453-00090R | 917 | EMEA | Buy Now |
Farnell | 453-00090R | 917 | EMEA | Buy Now |
Newark | 453-00090R | 917 | North America | Buy Now |
element14 APAC | 453-00090R | 917 | APAC | Buy Now |
element14 APAC | 453-00090R | 917 | APAC | Buy Now |
DigiKey | 453-00090R | 619 | North America | Buy Now |
DigiKey | 453-00090R | 619 | North America | Buy Now |
Symmetry Electronics | 453-00090R | 460 | North America | Buy Now |
DigiKey | 453-00090R | 0 | North America | Buy Now |
Future Electronics | 453-00090R | 0 | North America | Buy Now |
DigiKey | 453-00091-K1 | 60 | North America | Buy Now |
Mouser | 453-00091-K1 | 39 | North America | Buy Now |
Avnet | 453-00091-K1 | 30 | North America | Buy Now |
Farnell | 453-00091-K1 | 30 | EMEA | Buy Now |
Newark | 453-00091-K1 | 30 | North America | Buy Now |
Symmetry Electronics | 453-00091-K1 | 30 | North America | Buy Now |
element14 APAC | 453-00091-K1 | 30 | APAC | Buy Now |
Future Electronics | 453-00091-K1 | 28 | North America | Buy Now |
Chip One Stop | 453-00091-K1 | 26 | APAC | Buy Now |
Classic Components | 453-00091-K1 | 22 | North America | Buy Now |
Jak Electronics | 453-00091C | 3228 | APAC | Buy Now |
Mouser | 453-00091C | 2349 | North America | Buy Now |
Utmel Electronic | 453-00091C | 2341 | APAC | Buy Now |
Farnell | 453-00091C | 625 | EMEA | Buy Now |
Farnell | 453-00091C | 625 | EMEA | Buy Now |
Newark | 453-00091C | 625 | North America | Buy Now |
element14 APAC | 453-00091C | 625 | APAC | Buy Now |
element14 APAC | 453-00091C | 625 | APAC | Buy Now |
Avnet | 453-00091C | 600 | North America | Buy Now |
Sourcengine | 453-00091C | 600 | North America | Buy Now |
Classic Components | 453-00091C | 249 | North America | Buy Now |
Future Electronics | 453-00091C | 103 | North America | Buy Now |
DigiKey | 453-00091C | 0 | North America | Buy Now |
Symmetry Electronics | 453-00091C | 0 | North America | Buy Now |
Origin Data Global Limited | 453-00091R | 10000 | APAC | Buy Now |
DigiKey | 453-00091R | 6696 | North America | Buy Now |
DigiKey | 453-00091R | 6696 | North America | Buy Now |
Avnet | 453-00091R | 2500 | North America | Buy Now |
DigiKey | 453-00091R | 2500 | North America | Buy Now |
Farnell | 453-00091R | 2500 | EMEA | Buy Now |
Farnell | 453-00091R | 2500 | EMEA | Buy Now |
Newark | 453-00091R | 2500 | North America | Buy Now |
Symmetry Electronics | 453-00091R | 2500 | North America | Buy Now |
element14 APAC | 453-00091R | 2500 | APAC | Buy Now |
element14 APAC | 453-00091R | 2500 | APAC | Buy Now |
Jak Electronics | 453-00091R | 1992 | APAC | Buy Now |
Classic Components | 453-00091R | 1925 | North America | Buy Now |
Utmel Electronic | 453-00091R | 1829 | APAC | Buy Now |
Mouser | 453-00091R | 1584 | North America | Buy Now |
Future Electronics | 453-00091R | 0 | North America | Buy Now |
Mouser | 453-00147C | 247 | North America | Buy Now |
Classic Components | 453-00147C | 193 | North America | Buy Now |
Avnet | 453-00147C | 0 | North America | Buy Now |
Symmetry Electronics | 453-00147C | 0 | North America | Buy Now |
DigiKey | 453-00147R | 1885 | North America | Buy Now |
DigiKey | 453-00147R | 1885 | North America | Buy Now |
DigiKey | 453-00147R | 1000 | North America | Buy Now |
Mouser | 453-00147R | 967 | North America | Buy Now |
Avnet | 453-00147R | 0 | North America | Buy Now |
Symmetry Electronics | 453-00147R | 0 | North America | Buy Now |
Distributors
Distributor | Phone Number | Region | Website |
---|---|---|---|
Alpha Micro UK Only | +44 1256-851770 |
EMEA | 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 |
Digi-Key | 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 |
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 |
Solid State Supplies 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 |