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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

User Guide - BL65x AT Interface Application

User Guide - AT Interface Application - Lyra Series

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

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

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

User Guide - AT Interface Application - Lyra Series

User Guide - AT Interface Application - BL65x 

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

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

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

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

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

Yes. Lyra is a 100% software functional replacement for the BGX220 and BGX13 parts. We recommend reading and evaluating the OUI (Organizationally Unique Identifier) of the BLE MAC address. The OUI is a 24-bit number that uniquely identifies a vendor, manufacturer, or organization where the first three octets / bytes are assigned by the Institute of Electrical and Electronics Engineers (IEEE). For Lyra and 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.

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

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

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

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

In addition to the standard 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.

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

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

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

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

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

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

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

All Lyra modules ship pre-programmed with our own 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.

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

Windows

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

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

Linux

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

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

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

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

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

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

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

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

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

Wireless Xpress SW does not support SPI.

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

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

Description:

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

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

Configure the PTI Interface

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

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

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

PTI Component

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

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

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

PTI Baud

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

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

PTI Launch

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

     pti config 0 efruart 3200000

PTI Admin

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

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

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

How to: permanently securing the Lyra device

Description: 

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

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

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

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

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

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

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

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

   1. Open the “Device Configuration”

      

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

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

      

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

      

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

      

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

      

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

      

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

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

​create_bl_files.bat/sh

The script generates signed files as shown:

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

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

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

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

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

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

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

     

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



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



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



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

How to generate IAR project files

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

Steps to generate IAR project

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

• Check IAR EMBEDDED WORKBENCH PROJECT option 

• Push Save button 

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

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

How to generate GCC Makefile for project

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

Steps to generate

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

• Check GCC MAKEFILE option 
• Push Save button 

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

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

Summary

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

SWD J-LINK application image update 

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

Commands 

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

SWD J-LINK Bootloader update 

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

Commands   

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

• Connect to the target: connect

• Select device: EFR32MG22CXXXF512

• Specify target interface: SWD

• Specify target interface speed: 1000kHz

• Perform target reset: r

• Erase bootloader sectors: erase 0x0 0x6000

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

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

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

Introduction:

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

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

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

Importing Bootloader Projects

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

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

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

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

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

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

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

UART XMODEM Bootloader

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

Updating the application image using UART XMODE Bootloader

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

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

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

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

Summary:

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

BGAPI UART DFU Bootloader

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

Updating the application using BGAPI UART DFU Bootloader

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

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

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

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

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

 

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

 Summary:

Introduction 

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

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

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

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

Building

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

Debugging  

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

Launching debug session  

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

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

 

Summary: 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please find below the naming description of:

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

The following list describes the files:

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

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

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

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

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

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

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

apploader.gbl - unsigned GBL file for Apploader.

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

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

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

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

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

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

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

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

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

Without Adaptive Frequency-Hopping (AFH)

ETSI EN 300 328

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

FCC 15.247

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

Summary

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

With Adaptive Frequency-Hopping (AFH)

ETSI EN 300 328

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

FCC 15.247

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

Summary

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

Application Examples

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

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

Bluetooth LE Stack Feature Examples

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

The list of the samples includes:

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

Python-Based Host Examples

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

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

The list of the samples includes:
 

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

Introduction 

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

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

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

sl_bt_on_event()

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

app_init() 
 

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

Summary  
 

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

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

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

Hardware

• Lyra S or P Development Kit 

• Micro USB cable

Software

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

Connection 

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

Building and running the firmware  

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

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

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

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

Test the firmware

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

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

Note:

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

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.

View our full policy here.