AN1269: Dynamic Multiprotocol

Development with Bluetooth® and

Proprietary Protocols on RAIL in
GSDK v3.x

This application note provides details on how to develop a multi-

protocol application running Bluetooth and a proprietary protocol KEY POINTS

at the same time, using SDKs from Gecko SDK Suite v3.x. First • Generic guidelines for protocol
the criteria for the coexistence of Bluetooth and a proprietary pro- coexistence
tocol are discussed. Then the application note guides you • Generating and configuring a new
Bluetooth/Proprietary DMP project
through how to create a new DMP application, how to configure • Sending and receiving proprietary packets
Bluetooth and your proprietary protocol, and how to transmit and • Using RAIL priorities
receive proprietary packets while Bluetooth is running. Finally a • Building and understanding the Light/
Light/Switch DMP example is introduced in more details. For Switch DMP example

background on Dynamic Multiprotocol Application development in

general and about Bluetooth task priorities and scheduling, see
UG305: Dynamic Multiprotocol User’s Guide.

silabs.com | Building a more connected world. Rev. 0.1

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Introduction

1. Introduction

UG305: Dynamic Multiprotocol User’s Guide provides information about the Dynamic Multiprotocol solution, where two protocols are
running on the same device in parallel, and includes general background as well as information on Bluetooth task priorities and sched-
uling. This application note introduces the Bluetooth / Proprietary multiprotocol solution. It assumes that the reader is familiar with the
principles of Dynamic Multiprotocol and with all the terms related to it.

1.1 Requirements

To be able to use all the features discussed in this document, you will need the followings installed on your computer:
• Bluetooth SDK version 3.0.0 or higher
• Micrium OS-5 kernel

To be able to run the Light/Switch example, you will need the following installed on your computer:
• Bluetooth SDK version 3.0.0 or higher
• Flex SDK version 3.0.0 or higher
• Micrium OS-5 kernel
• An EFR32 chip with at least 512 kB of flash (required to run all the necessary software components)
• IAR Embedded Workbench for ARM (IAR-EWARM) (required for the RAIL Switch application). See the release notes for the Blue-
tooth SDK for the required IAR-EWARM version.

silabs.com | Building a more connected world. Rev. 0.1 | 2

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Guidelines for Bluetooth and Proprietary Coexistence

2. Guidelines for Bluetooth and Proprietary Coexistence

When you start implementing a Bluetooth / Proprietary DMP application the first thing to consider is if your proprietary protocol is com-
patible with Bluetooth. Here are some guidelines that you should always take into account:
• Bluetooth is deterministic. The huge advantage of the Bluetooth protocol in a DMP scenario is that it does not send and receive
packets at random times, but at predefined time instances – always at the start of a connection interval. This means, among other
things, that Bluetooth does not need a background receive, and your proprietary protocol can receive in the background, of
course with some interruptions.
• Bluetooth needs accuracy. The consequence of predefined time instances is that Bluetooth packets cannot be late – their timing
needs 500 ppm accuracy. If you delay a Bluetooth packet, it will not be received on the other side. So in case of collision with a
proprietary packet, either the proprietary packet has to be delayed, or one of the packets has to be dropped.
• Bluetooth connection is active. Once a Bluetooth connection is established, the connection is kept alive by sending and receiving
at least an empty packet every connection interval. Consequently your proprietary protocol need to be prepared to be interrupted
every connection interval. You can, however, set the connection interval to a long period if you do not need low Bluetooth latency.
You can also use the slave latency parameter to make Bluetooth communication less frequent on the slave side.
• Bluetooth uses short packets. If there is no data to be sent, the Bluetooth connection is kept alive by empty packets. An empty
packet takes 80.µs to be sent out on 1 meg PHY, and 40 µs on 2 meg PHY. Empty packets sending + inter frame space + empty
packet receiving takes 80 + 150 + 80 = 310 µs or 40 + 150 + 40 = 230 µs. This is the usual time needed by Bluetooth in every
connection interval. The largest Bluetooth packet has 257 byte payload which takes 2120 µs to be sent on 1 meg PHY and 1060 µs
on 2 meg PHY. Along with receiving an empty response packet this takes 2120 + 150 + 80 = 2350 µs on 1 meg PHY and 1060 +
150 + 40 = 1250 µs on 2 meg PHY.
• Bluetooth uses packet chains. If the data to be sent does not fit into one packet, Bluetooth communication can be extended within
a connection interval, that is you can expect that more than one packet is sent and received in an interval, but this is rare.
• Bluetooth is robust. If a Bluetooth packet cannot be sent, then it will be retransmitted in the next connection interval. If a Blue-
tooth packet is received with a CRC error, it is always signaled by the other side by not sending a response packet. Again, the
packet will be retransmitted in the next connection interval. The only limit is the supervision timeout. If there is no successful trans-
mission within the supervision timeout, then the connection is dropped. In other words, Bluetooth communication can be subdued
by higher priority radio tasks for a time interval shorter that the supervision timeout.

Summary: When implementing your DMP protocol, you have to take into account that Bluetooth will need the radio every connection
interval for a short time (230 µs – 2350 µs). Bluetooth needs accurate timing, so Bluetooth packets cannot be delayed. The Bluetooth
packets can interrupt both your packet sending and packet receiving, hence the proprietary protocol should implement acknowledge-
ment and retransmission mechanisms, or a deterministic timing that is interleaved with the Bluetooth communication. Bluetooth commu-
nication can be subdued by a higher priority radio task for a time interval shorter than the supervision timeout.

silabs.com | Building a more connected world. Rev. 0.1 | 3

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Software Architecture of a Bluetooth / Proprietary DMP application

3. Software Architecture of a Bluetooth / Proprietary DMP application

DMP applications are based on Micrium RTOS. The RTOS helps run the Bluetooth and Proprietary protocols in parallel and independ-
ently.

Since the Bluetooth stack itself is just a collection of functions, Bluetooth needs separate tasks to run the stack. The BluetoothTask()
and the LinkLayerTask() are responsible for this, and they can be used as they are. The functions of the Bluetooth stack can be ac-
cessed through these tasks using BGAPI, as in the case of an RTOS-less or an NCP application. The Bluetooth application (handling
Bluetooth events and calling Bluetooth commands) has to be implemented by the developer in sl_bt_on_event() , which is (indirect-
ly) called from the sl_bt_event_handler_task(). For details please refer to AN1260: Integrating Silicon Labs Bluetooth® Applications
with the Micrium RTOS.

The proprietary protocol is implemented in the proprietaryAppTask(). Unlike Bluetooth, the proprietary protocol can access the radio
directly through the RAIL API. RAIL events need a callback function – sl_rail_app_on_event() – to be defined. This function is called
every time a new RAIL event is generated, and can notify the application about the event. Note: sl_rail_app_on_event() is called
from interrupt context, so only time-critical functions should be implemented in it. Everything else should be done in the application.

Although the Bluetooth and Proprietary applications are independent, they can communicate using inter-process communication (IPC).

silabs.com | Building a more connected world. Rev. 0.1 | 4

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

4. Developing a Bluetooth / Proprietary DMP Project

4.1 Create a New Project

Silicon Labs Bluetooth SDK (v2.9 or later) includes the “Soc Empty Rail Dmp” software sample that should be used as a starting point
for every Bluetooth / Proprietary application. This sample project:
• Includes the multiprotocol RAIL library
• Includes the Bluetooth library
• Includes the Micrium RTOS
• Has a default Bluetooth GATT database configuration
• Has a default RAIL configuration
• Has a default RTOS configuration
• Implements Bluetooth initialization
• Implements RAIL initialization
• Implements RTOS initialization

The only thing you have to do is to modify the configurations according to your needs and implement the Bluetooth application task and
the Proprietary application task. As default the proprietaryAppTask() is defined and implemented in the files proprietary_app.c and
proprietary_app.h.

For the Bluetooth part, the default implementation contains the Bluetooth event handler, the sl_bt_on_event() function, defined in the
bluetooth_app.c file.

The GATT database can be configured with the visual GATT Configurator in Simplicity Studio 5, while the RAIL configuration can be
generated with the Radio Configurator tool. You may also need to add some emlib and emdrv files to your project to support peripheral
configuration. The general workflow to create a DMP project looks like this:

To create a new project.

1. Open Simplicity Studio 5.
2. Select a connected device in the Debug Adapters view, or select a part in the My Products view.
3. Click File > New > Silicon Labs Project Wizard.
4. Review your SDK and toolchain. If you have more than one GSDK version installed, verify that Gecko SDK Suite v3.x is shown. If
you wish to use IAR instead of GCC, be sure to change it here. Once you have created a project it is difficult to change toolchains.
Click NEXT.
5. On the Example Project Selection dialog, filter on Bluetooth and select SOC – Empty – RAIL – DMP. Click NEXT.
6. Name your project. Click [FINISH].

silabs.com | Building a more connected world. Rev. 0.1 | 5

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

4.2 Configure Bluetooth

Configuring Bluetooth consists of two steps:

• Configuring the local GATT database
• Configuring the Bluetooth stack

To configure the local GATT database, use Simplicity Studio 5's GATT Configurator.
1. Open the .slcp file in the project (if it is not already open).
2. Click the Software Components tab.
3. Under the Advanced Configurators group, select the Bluetooth GATT Configurator and click Open.

4. Add your custom services and characteristics as described in QSG169: Bluetooth® SDK v3.x Quick Start Guide (or use the default
GATT database).
5. Your changes are automatically saved and project files are generated.

To configure the Bluetooth stack:

1. Go to the Software Components tab

silabs.com | Building a more connected world. Rev. 0.1 | 6

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

2. Find Bluetooth > Feature > Bluetooth Core component.

3. Change the config according to your needs. For details see UG434: Silicon Labs Bluetooth® C Application Developers Guide for
SDK v3.x (or use the default configuration).

silabs.com | Building a more connected world. Rev. 0.1 | 7

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

4.3 Configure Proprietary Protocol

Configuring the proprietary protocol consists of two steps:

• Configuring the radio channels (base frequency, modulation, and so on)
• Configuring the RAIL

To configure the radio channels, use Simplicity Studio 5's Radio Configurator tool:
1. Open the .slcp file in the project (if it is not already open).
2. Click the Software Components tab.
3. Under the Advanced Configurators group, select the Radio Configurator and click Open.

4. Select Base Profile from the radio profiles.

5. Select a predefined radio PHY from the list, or select Custom settings, and apply your settings. For details see AN1253: EFR32
Radio Configurator Guide for Simplicity Studio 5.

To configure RAIL:

silabs.com | Building a more connected world. Rev. 0.1 | 8

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

1. On the Software Components tab, select Flex > RAIL > Utility. Click Configure.

2. Change configurations as needed. For details see AN1253: EFR32 Radio Configurator Guide for Simplicity Studio 5.

silabs.com | Building a more connected world. Rev. 0.1 | 9

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

4.4 Develop Bluetooth Application

Bluetooth applications have to be implemented the same way as in a non-DMP scenario:

• BGAPI commands can be called from anywhere (except from interrupt context!)
• BGAPI events have to be fetched from the internal event queue of the Bluetooth stack. This is typically done in an infinite loop.

A single protocol Bluetooth application can run with or without RTOS. The DMP Bluetooth application can, however, only run over
RTOS. As described in section 3. Software Architecture of a Bluetooth / Proprietary DMP application, you must implement Bluetooth
event handling in the Bluetooth application task. The skeleton of this task is implemented in main.c. To handle new Bluetooth events,
simply add new case statements with the appropriate event IDs. The general process can be seen in the following figure:

silabs.com | Building a more connected world. Rev. 0.1 | 10

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Developing a Bluetooth / Proprietary DMP Project

4.5 Develop Proprietary Application

Proprietary application uses RAIL directly:

• RAIL API commands can be called from anywhere.
• RAIL API events have to be handled in the events callback function.

By default the events callback function is set to sl_rail_app_on_event(). An empty sl_rail_app_on_event() function is implemen-
ted as a weak function in sl_rail_util_callbacks.c. It can be overloaded in the application. This function is called every time a new radio
event is received from RAIL. Each RAIL event sets a specific flag in the 64-bit bitfield. Be aware that multiple flags may be set, so you
may have to handle multiple events within one callback. Note: The events callback function is called from an interrupt context, so you
have to handle it as an interrupt handler! Do only quick calculations, and set a flag to inform your main loop about the changes.

The main loop to process the radio events is to be implemented in the proprietaryAppTask(), which runs parallel to the
sl_bt_event_handler_task() that ultimately calls the sl_bt_on_event() event handler. It is the developer’s job to decide how to
communicate between the radio event handler (sl_rail_app_on_event()) and the proprietaryAppTask(), but in general it is recom-
mended to use the services of the RTOS, like semaphores, flags, message queues, and so on.

The general process is shown in the following figure:

4.6 Communication between Bluetooth and Proprietary Protocol

Bluetooth and the proprietary protocol are running parallel in two independent tasks. However, often they need to be synchronized, for
example if you want to send out a proprietary packet when a value changed in the local GATT database, or you want to change a value
in the local GATT database when you received a proprietary packet.

To notify the proprietary task from the Bluetooth task, or the other way around, the easiest way is to set an RTOS flag. You can define a
queue for events and use that to notify the other task. From the proprietary task you can also set an external event to the Bluetooth
stack, using the function sl_bt_external_signal(). This will generate an sl_bt_evt_system_external_signal_id event in the
Bluetooth stack.

silabs.com | Building a more connected world. Rev. 0.1 | 11

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Examples

5. Examples

5.1 Sending Proprietary Packets

This simple example sends out a proprietary packet every time a specific characteristic in the local GATT database is written.
1. Create a new Soc Empty Rail Dmp project as described in section 4.1 Create a New Project.
2. In the GATT configurator, add a new characteristic to the GATT database (as described in QSG169: Bluetooth® SDK v3.x Quick
Start Guide) with the following parameters:
a. Name: Proprietary characteristic
b. ID: prop_char
c. Value type: hex
d. Length: 16 byte
e. Properties: Read, Write, Notify
3. Define a CHARACTERISTIC_CHANGED flag. This flag will be used in the communication between sl-bt-on-event() and the
proprietaryAppTask, as part of the proprietary_event_flags flag group.

#define CHARACTERISTIC_CHANGED ((OS_FLAGS)0x01)

4. Create a Tx FIFO. Define the following in proprietary_app.c::

#define RAIL_TX_FIFO_SIZE (64)

static uint8_t txFifo[RAIL_TX_FIFO_SIZE];

5. In the Bluetooth application task (more precisely in sl_bt_on_event()):

a. Add a new event handler to the switch – case statement to handle characteristic value changes.
b. Check if it is the prop_char that has changed.
c. Set a flag to notify the proprietary protocol.

case sl_bt_evt_gatt_server_attribute_value_id:
if (evt->data.evt_gatt_server_attribute_value.attribute == gattdb_prop_char)
{
OSFlagPost(&proprietary_event_flags,
CHARACTERISTIC_CHANGED,
OS_OPT_POST_FLAG_SET,
&err);
}
break;

6. In the proprietaryAppTask() – before the infinite loop:

a. Set up the Tx FIFO for RAIL.
b. Define scheduler info for the packet to be sent.

RAIL_SetTxFifo(railHandle, txFifo, 0, RAIL_TX_FIFO_SIZE);

RAIL_SchedulerInfo_t txSchedulerInfo = (RAIL_SchedulerInfo_t){ .priority = 100,
.slipTime = 100000,
.transactionTime = 800 };

silabs.com | Building a more connected world. Rev. 0.1 | 12

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Examples

7. Within the infinite loop of the proprietaryAppTask():

a. Wait for the CHARACTERISTIC_CHANGED flag.
b. Copy the content of the characteristic into the Tx FIFO.
c. Send out the packet.

while (DEF_TRUE) {
RTOS_ERR err;
OSFlagPend(&proprietary_event_flags,
CHARACTERISTIC_CHANGED,
(OS_TICK)0,
OS_OPT_PEND_BLOCKING \
+ OS_OPT_PEND_FLAG_SET_ANY \
+ OS_OPT_PEND_FLAG_CONSUME,
NULL,
&err);

sl_status_t result;;
result = sl_bt_gatt_server_read_attribute_value(gattdb_prop_char, 0, 16, data_len,
dataPacket);
RAIL_WriteTxFifo(railHandle, dataPacket, data_len, true);
RAIL_StartTx(railHandle, 0, RAIL_TX_OPTIONS_DEFAULT, &txSchedulerInfo);
}

8. In sl_rail_app_on_event():
a. Check for the packet_sent event, and do not forget to yield the radio.

static void sl_rail_on_event(RAIL_Handle_t railHandle,

RAIL_Events_t events)
{
if (events & RAIL_EVENT_TX_PACKET_SENT) {
RAIL_YieldRadio(railHandle);
}
}

silabs.com | Building a more connected world. Rev. 0.1 | 13

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Examples

5.2 Receiving Proprietary Packets

This example implements a receiver for the transmitter implemented in the previous section. Once a proprietary packet is received the
example updates a characteristic in the local GATT database.

To implement a receiver use the transmitter project described in the previous section and extend it with the following procedure.
1. Define a new flag for signaling packet reception to the proprietary application.

#define PACKET_RECEIVED ((OS_FLAGS)0x02)

2. Create an Rx FIFO. Define the following in proprietary_app.c:

#define RAIL_RX_FIFO_SIZE (64)

static uint8_t rxFifo[RAIL_RX_FIFO_SIZE];

3. In the proprietaryAppTask() – before the infinite loop:

a. Set Rx transition in order to automatically restore Rx state after packet reception.
b. Set the Rx priority lower than the Tx priority.
c. Start Rx (before the infinite loop!).

RAIL_StateTransitions_t stateTransition = (RAIL_StateTransitions_t){

.success = RAIL_RF_STATE_RX,
.error = RAIL_RF_STATE_RX };
RAIL_SetRxTransitions(railHandle,&stateTransition);
RAIL_SchedulerInfo_t rxSchedulerInfo = (RAIL_SchedulerInfo_t){ .priority = 200 };
RAIL_StartRx(railHandle, 0, &rxSchedulerInfo);

4. In the radio event handler, such as sl_rail_app_on_event():

a. Check if a packet was successfully received.
b. Copy the packet content to your local Rx FIFO.
c. Set a flag to notify the proprietary protocol about the new packet.

if (events & RAIL_EVENT_RX_PACKET_RECEIVED) {

RAIL_RxPacketInfo_t packetInfo;
RTOS_ERR err;

RAIL_GetRxPacketInfo(railHandle,
RAIL_RX_PACKET_HANDLE_NEWEST,
&packetInfo);

if (packetInfo.packetStatus == RAIL_RX_PACKET_READY_SUCCESS) {
RAIL_CopyRxPacket(rxFifo,&packetInfo);
OSFlagPost(&proprietary_event_flags,PACKET_RECEIVED,OS_OPT_POST_FLAG_SET,&err);
}
}

silabs.com | Building a more connected world. Rev. 0.1 | 14

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Examples

5. Within the infinite loop of the proprietaryAppTask():

a. Check for two event flags: CHARACTERISTIC_CHANGED and PACKET_RECEIVED. You can wait for both of them and then
check which one was set.
b. If the PACKET_RECEIVED flag is set then write the content of the received packet into the local GATT database and
c. Notify the Bluetooth stack that the value has changed (using a Bluetooth external signal).

while (DEF_TRUE) {
RTOS_ERR err;
OS_FLAGS active_flags = OSFlagPend (&proprietary_event_flags,
CHARACTERISTIC_CHANGED \
+ PACKET_RECEIVED,
(OS_TICK)0,
OS_OPT_PEND_BLOCKING \
+ OS_OPT_PEND_FLAG_SET_ANY \
+ OS_OPT_PEND_FLAG_CONSUME,
NULL,
&err);

if (active_flags & CHARACTERISTIC_CHANGED)

{
sl_status_t result;
result = sl_bt_gatt_server_read_attribute_value(gattdb_prop_char, 0, 16, data_len,
dataPacket);
RAIL_WriteTxFifo(railHandle, dataPacket 16, true);
RAIL_StartTx(railHandle, 0, RAIL_TX_OPTIONS_DEFAULT, &txSchedulerInfo);
}

if (active_flags & PACKET_RECEIVED)

{
sl_bt_gatt_server_write_attribute_value(gattdb_prop_char,0,16,rxFifo);
sl_bt_external_signal(CHARACTERISTIC_CHANGED);
}
}

6. In sl_bt_on_event():
a. Add a new event handler for the external signal.
b. Check if you got a CHARACTERISTIC_CHANGED signal.
c. Send out a notification.

case sl_bt_evt_system_external_signal_id:
if (bluetooth_evt->data.evt_system_external_signal.extsignals &
CHARACTERISTIC_CHANGED)
{
sl_bt_cmd_gatt_server_send_characteristic_notification(0xff, gattdb_prop_char,
16, rxFifo, &sent_len);
}
break;

silabs.com | Building a more connected world. Rev. 0.1 | 15

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Light/Switch Example

6. Light/Switch Example

This section provides details on working with the Light/Switch multiprotocol example code.

6.1 Working with the Light/Switch Example

To work with Light/Switch dynamic multiprotocol example you must install both the Flex SDK version 3.0.0 or higher, and the Bluetooth
SDK version 3.0.0 or higher. The Micrium kernel is installed along with the Bluetooth SDK. Use the version of IAR Embedded Work-
bench for ARM (IAR-EWARM) that is documented in the release notes for the SDK. The RAIL Switch and Bluetooth/RAIL Light Dynam-
ic multiprotocol applications are generated, built, and uploaded in the same way as other applications in their SDKs.
• To see details about installing Simplicity Studio and the Flex SDK and building an example application, see QSG168: Proprietary
Flex SDK v3.x Quick Start Guide.
• To see details about installing Simplicity Studio and the Bluetooth SDK and building an example application, see QSG169: Blue-
tooth® SDK v3.x Quick Start Guide.
Note: In a demonstration configuration with multiple RAIL/Bluetooth dynamical protocol light devices and a single switch device, unpre-
dictable behavior may occur. We recommend testing with a single light device and a single switch device.

The following summary procedures are provided for your convenience.

6.1.1 Building the RAIL:Switch Application

1. Open Simplicity Studio 5.

2. Select a connected device in the Debug Adapters view.
3. Click File > New > Silicon Labs Project Wizard.
4. Review your SDK and toolchain and change as necessary. Click NEXT.
5. On the Example Project Selection dialog, filter on Proprietary and select Flex (RAIL) - Switch. Click NEXT.
6. Name your project. Click [FINISH].
7. Either automatically compile and flash using the debug button, or manually compile and then load.

Application load success indicators are code-dependent. With the RAIL: Switch example, the LCD displays a short menu before chang-
ing over to the light bulb display.

silabs.com | Building a more connected world. Rev. 0.1 | 16

 AN1269: Dynamic Multiprotocol Development with Bluetooth® and Proprietary Protocols on RAIL in GSDK v3.x
Light/Switch Example

6.1.2 Building the Bluetooth Light Application

The Bluetooth Light application requires the Gecko Bootloader be loaded on the device. The Gecko Bootloader is loaded when you
load the precompiled SOC-Light-Rail-Dmp demonstration. Alternatively you can build and load your own Gecko Bootloader combined
image (called <projectname>-combined.s37), as described in UG266: Silicon Labs Gecko Bootloader User’s Guide.
1. Open Simplicity Studio 5.
2. Select the connected device in the Debug Adapters view.
3. Click File > New > Silicon Labs Project Wizard.
4. Review your SDK and toolchain, and change as necessary. Click NEXT.
5. On the Example Project Selection dialog, filter on Bluetooth and select Soc Light Rail Dmp. Click NEXT.
6. Name your project. Click [FINISH].
7. Either automatically compile and flash using the debug button, or manually compile and then load.

Application load success indicators are code-dependent. With the Soc Light Rail Dmp example, the LCD displays a light bulb.

6.1.3 Changing the PHY Configuration

The default PHY configuration for the RAIL/Bluetooth example is a sub Gigahertz configuration. You may want to modify this PHY con-
figuration as you begin to develop applications for your own hardware.

To change the PHY configuration:

1. Open the RAIL Switch project.
2. Open the .slcp file in the project, and click the Software Components tab.
3. Under Advanced Configurators, select the Radio Configurator and click Open.
4. Select a new PHY.
5. The new config will be generated into the folder autogen, with the names of rail_config.c and rail_config.h.
6. Open the Soc Light Rail Dmp project.
7. Copy rail_config.c and rail_config.h from the RAIL Switch project to the Soc Light Rail Dmp project.
8. Make sure that you overwrite the old rail_config.c and rail_config.h files.
9. Rebuild and flash both projects as you would normally.

silabs.com | Building a more connected world. Rev. 0.1 | 17

 Smart.
Connected.
Energy-Friendly.

Products Quality Support and Community

www.silabs.com/products www.silabs.com/quality community.silabs.com

Disclaimer
Silicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or
intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical"
parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without
further notice to the product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Without prior
notification, Silicon Labs may update product firmware during the manufacturing process for security or reliability reasons. Such changes will not alter the specifications or the performance
of the product. Silicon Labs shall have no liability for the consequences of use of the information supplied in this document. This document does not imply or expressly grant any license
to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any FDA Class III devices, applications for which FDA premarket approval is
required, or Life Support Systems without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health,
which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs
products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering
such weapons. Silicon Labs disclaims all express and implied warranties and shall not be responsible or liable for any injuries or damages related to use of a Silicon Labs product in such
unauthorized applications.

Trademark Information
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, ClockBuilder®, CMEMS®, DSPLL®, EFM®, EFM32®,
EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®,
Gecko OS, Gecko OS Studio, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® , Zentri, the Zentri logo and Zentri DMS, Z-
Wave®, and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a
registered trademark of ARM Limited. Wi-Fi is a registered trademark of the Wi-Fi Alliance. All other products or brand names mentioned herein are trademarks of their respective holders.

Silicon Laboratories Inc.

400 West Cesar Chavez
Austin, TX 78701
USA

http://www.silabs.com