Note before you read this KBA: On SDK 2.4.0 a new API was introduced which allows changing the OTA device name in run-time. On SDK 2.4.2 a new feature was added to gecko_cmd_le_gap_set_adv_data which allows to manually set the content of the OTA advertisement packet. Both of these are described in this KBA. In practice this means that you can keep the gecko configuration structure as const and you can use the new API to set the device name instead of the structure fields.

Introduction

This article shows how you can read the Bluetooth (BT) address before initializing the stack, together with a use case example of how you can set it as the device name for OTA.

Typically the BT address can be read using the API command system_get_bt_address(), but it requires the stack to be initialized and boot event received. There are use cases where it might be required to read the BT address prior to initializing the stack which can be done by reading it straight from the underlying EFR32 registers.

Please note that this method does not work when the BT address is overwritten, it’s only usable for the default BT address

Where is the default Bluetooth address stored

The default BT address can be extracted from the device unique number that is in the Device Information page in flash, registers UNIQUEL and UNIQUEH (EFR32 reference manual, page 34). This is programmed in production and cannot be changed by the user so there is no risk of losing it, not even with a full flash erase.

The unique device number can be seen when you connect to a device using Simplicity Commander, in the lower right-hand corner, the last row of the “MCU Information”, Unique ID.

The unique number is 64-bits wide and if you exclude the 16 bits in the middle (0xfffe) you can see that it is the same as the BT address. In this example 00:0B:57:26:2F:32.

You can also run commander from command line, without the GUI. By passing commands device info as parameter, you can easily read the unique ID register as well as other information (such as the exact part number). See example usage below:

commander.exe device info
Reconfiguring debug connection with detected device part number: EFR32BG1B232F256GM48
Part Number    : EFR32BG1B232F256GM48
Die Revision   : A3
Production Ver : 147
Flash Size     : 256 kB
SRAM Size      : 32 kB
Unique ID      : 000b57fffe2574c9
DONE

The em_system.h header file contains a function to read the unique device number, System_GetUnique().

Practical use case example - Using BT address as the device name in OTA

Attached to this KBA is an example which reads out the default BT address, converts it into an ascii string and sets it as the device name in OTA. The example is for the BGM111 module and it’s based on the SDK2.3.1 using GCC toolchain.

The gecko_configuration_t structure is typically declared as constant but this is not a requirement. The advantage of this approach is that the structure will be placed in Flash instead of RAM. If the structure is declared without the const qualifier then the ota.device_name_ptr and ota.device_name_len can be modified in run-time before calling gecko_init() which takes this structure as the input parameter.

Getting the BT address as the device name in OTA requires essentially 4 steps:

1. Read the Unique Device Number
2. Extract BT address out of the unique device number
3. Convert to ascii characters
4. Assign the new name to the ota field of the gecko configuration structure

For this we need to declare 3 variables, one to hold the unique device number, one to hold the BT address that will be extracted from the unique device number and one to hold the BT address string.

  /* Variable for storing the 64-bit unique number */
  uint64_t uniqueDeviceNumber;
  /* BT address variable */
  bd_addr myBTA;
  /* Array to hold the BT address in string format - 12 characters + 5 ':' = 17 */
  char myBTAstring[17];

Reading the unique device number

The unique device number can be read using the System_GetUnique() function mentioned earlier.

  /* Get Unique Device Number */
  uniqueDeviceNumber = SYSTEM_GetUnique();

Extract the BT address

To extract the BT address we need to shift the bytes from the unique number according to which address byte we want to read and ignore the middle section (0xfffe).

  /* Extract BT address from Unique Device Number */
  myBTA.addr[0] = (uint8_t)(uniqueDeviceNumber>>56);
  myBTA.addr[1] = (uint8_t)(uniqueDeviceNumber>>48);
  myBTA.addr[2] = (uint8_t)(uniqueDeviceNumber>>40);
  myBTA.addr[3] = (uint8_t)(uniqueDeviceNumber>>16);
  myBTA.addr[4] = (uint8_t)(uniqueDeviceNumber>>8);
  myBTA.addr[5] = (uint8_t)uniqueDeviceNumber;

Convert to ascii string

Once the address has been extracted it can be converted into an ascii string.

  /* Convert to string format */
  for(uint8_t i=0; i<6; i++) {
	  /* Convert to hexadecimal (capital letters) with minimum width of 2 and '0' stuffing
	   * More info on the sprintf parameters here: https://www.tutorialspoint.com/c_standard_library/c_function_sprintf.htm
	   */
	  sprintf(&(myBTAstring[i*3]), "%02X", myBTA.addr[i]);

	  /* Add the ':' character to overwrite the null terminator added by sprintf (except on the last iteration */
	  if(i<5) {
		  myBTAstring[i*3+2] = ':';
	  }
  }

Assign string to OTA device name

The last part is to assign the new string pointer to the ota device name in the gecko configuration structure.

  /* Use the new BT address string as device name for OTA */
  config.ota.device_name_ptr = myBTAstring;
  config.ota.device_name_len = 17;

Testing the example

Using the Blue Gecko app you can scan for the device and set into OTA mode by writing ‘0’ to the OTA control characteristic which will force the connection to drop from the slave side as the device goes into OTA DFU mode. Once the app goes back into scanning you’ll be able to see the BT address as the OTA device name.

Introduction

This article provides a walkthrough on setting up the LCD screen on WSTK for a Bluetooth SDK project. This process may also suit projects which are using different SDKs under the Gecko SDK Suite but it has only been tested with the soc-empty from the Bluetooth SDK.

The process is slightly different depending on which Bluetooth SDK version you are using, 2.6.x or older and 2.7.x or newer. This relates to a change on SDK 2.7.0 where the SDK projects no longer link to files in the SDK but rather copy them onto the workspace project.

For the 2.7.x and newer SDKs you can use a script that automates the manual file copying making the process a lot faster and user friendly.

Adding LCD support for SDK 2.6.x or older

Attached you can find a soc-empty Bluetooth SDK example extended with LCD functionality. The example works on BRD4153A radio board, but the process of adding LCD support is very similar for every radio board.

To add LCD support to a project follow these steps:

1- Create lcd-graphics folder in your project.

2- Drag and drop the files below to lcd-graphics folder. It is wise to select the Link to files option and choose the STUDIO_SDK_LOC symbol as a root. This makes the project portable.

Files needed for LCD handling:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\hardware\kit\common\drivers\display.c

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\hardware\kit\common\drivers\ displayls013b7dh03.c

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\hardware\kit\common\drivers\displaypalemlib.c

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\platform\middleware\glib\dmd\display\dmd_display.c

c:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\util\silicon_labs\silabs_core\graphics\graphics.c

c:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\hardware\kit\common\drivers\udelay.c

Additionally, all the .c files needed from here:

*C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v1.0\platform\middleware\glib\glib*

Once every files added the lcd-graphics folder looks like this:

3- Add the following paths to the include paths

"${StudioSdkPath}/platform/middleware/glib"

"${StudioSdkPath}/platform/middleware/glib/glib"

"${StudioSdkPath}/platform/middleware/glib/dmd"

"${StudioSdkPath}/hardware/kit/ /config"

"${StudioSdkPath}/util/silicon_labs/silabs_core/graphics"

Include paths can be added on project properties dialog.

Adding LCD support for SDK 2.7.x or newer

1- Copy the attached script lcd_support.bat into your soc-empty project directory. The script assumes that the SDK is installed in the default studio path so make sure to change this in the script if the SDK path is different.

:: Note: This is the standard installation path for the GSDK, if it's different on your installation please update the variable below
SET SDKS_PATH=C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite

Run the script and you will find 2 additional folders in your project, lcd-graphics and dmd.

2- Add the following path to the include paths:

"${workspace_loc:/${ProjName}/lcd-graphics}"

Assuming you are using GCC this will be in project properties -> "C/C++ Build" -> Settings -> "GNU ARM C Compiler" -> Includes

3- Add this line to hal-config.h:

#define HAL_SPIDISPLAY_FREQUENCY                      (1000000)

Using the LCD

There is a set of basic LCD handling functions collected in graphics.h/.c . These are:

void GRAPHICS_Init(void);
void GRAPHICS_Sleep(void);
void GRAPHICS_Wakeup(void);
void GRAPHICS_Update(void);
void GRAPHICS_AppendString(char *str);
void GRAPHICS_Clear(void);
void GRAPHICS_InsertTriangle(uint32_t x, uint32_t y, uint32_t size, bool up, int8_t fillPercent);

To use these functions you need to include graphics.h.

LCD initialization

Before using the LCD it needs to be initialized by calling the GRAPHICS_Init function

Printing to the LCD

GRAPHICS_Clear();
GRAPHICS_AppendString("Hello World!\n");
GRAPHICS_Update();

Note: The graphics.h is limited but easy to use. If you need features that graphics.h does not support than use glib graphics library directly. You can find the glib reference here.

Introduction

This example shows how to implement transparent serial data connection between two radio boards or modules.

The goal of this example is to provide a simple template for users that want to use SPP-like communication in their projects. To keep the code as short and simple as possible the features are quite minimal. Users are expected to customize the code as needed to match their project requirements.

The associated sample code is a single application that implements both the server and client roles (in their own C-files). The role is selected dynamically at power-up using pushbuttons, details are found later in the section Running the demo.

The client part of this example (spp_client_main) can be also used as a starting point for any generic BLE central implementation that needs to scan for devices and automatically connect to those devices that advertise some specific service UUID. The client performs service discovery after connection establishment and this process works similarly for any GATT based services. With small modifications the spp_client_main code can be converted into e.g. a “heart rate client” or “thermometer client”.

Project setup

This section guides you through setting up an SPP example application on your kit.

To run this example you need:

• Two Wireless Starter Kits (WSTK)
• Two radio boards or modules
• Two terminal windows (such as TeraTerm or PuTTY) running on your PC

1. Create a new SoC - Empty application project with Bluetooth SDK using version 2.12 or newer.

The example sits on top of the basic SoC - Empty application. We will replace the app.c files with the files provided with this article.

2. Click on the .isc file in your project tree, select the Custom BLE GATT field on the right side of the configurator and finally select Import GATT from .bgproj file from the icons next to the field (the bottommost icon)

3. Select the provided gatt.xml, click Save and finally press Generate. You should now have a new SPP service and within it one characteristic.

4. Copy the following files to your project:

- app.c

- spp_utils.h

- spp_utils.c

- spp_client_main.c

- spp_server_main.c

5. Enable printing to console by setting DEBUG_LEVEL from 0 to 1 in app.h

That's it! When you program the application to your development kit, you should see this print at the serial output:

* SPP server mode *

Keeping button PB0 or PB1 pressed during reset will select client mode, in that case the print will be:

* SPP client mode * 

SPP server

There is no standard SPP service in Bluetooth Low Energy and therefore we need to implement this as a custom service. The custom service is about as minimal as possible. There is only one characteristic that is used for both incoming and outgoing data. The service is defined in the gatt.xml file associated with this article and shown below.

<!-- Our custom service is declared here -->	 
  <!-- UUID values generated with https://www.guidgenerator.com/ --> 
  <service uuid="4880c12c-fdcb-4077-8920-a450d7f9b907" advertise="true">
    <description>SPP Service</description>  
    <characteristic uuid="fec26ec4-6d71-4442-9f81-55bc21d658d6" id="xgatt_spp_data">
      <description>SPP Data</description>
      <properties write_no_response="true" notify="true" />
      <value variable_length="true" length="20" type="hex"></value>
    </characteristic>
</service>

At boot event the server is put into advertisement mode. This example uses advertising packets that are automatically filled by the stack. In our custom SPP service definition (see above) we have set advertise=true, meaning that the stack will automatically add the 128-bit UUID in advertisement packets. The SPP client will use this information to recognize the SPP server among other BLE peripherals.

For incoming data (data sent by the SPP client and written to UART in SPP server) we use unacknowledged write transfers (write_no_response). This will give better performance than normal acknowledged writes because several write operations can be fitted into one connection interval.

For outgoing data (data received from UART and sent to SPP client) we use notifications with the command gatt_server_send_characteristic_notification. Notifications are unacknowledged and this will again allow several notifications to be fitted into one connection interval.

Note that the data transfers are unacknowledged at GATT level. This means that at application level there are no acknowledgements. However, at the lower protocol layers each packet is still acknowledged and retransmissions are used when needed to ensure that all packets are delivered.

The core of this SPP example implementation is a 256-byte FIFO buffer (data[] in send_spp_data function) that is used to manage outgoing data. Data is received from UART and it is pushed to the SPP client using notifications. Incoming data from client raises the gatt_server_attribute_value event. The received data will then be copied to UART.

Some simple overflow checking can be optionally included. If the number of bytes exceeds 256 then FIFO overflow happens. Depending on application the overflow situation may be handled differently. For some applications it could be best to just drop the bytes that do not fit in buffer. For other applications it may be better to immediately stop all data transfer to avoid any further damage. See comments in spp_utils.h for more information.

SPP client

In terms of incoming/outgoing UART data, the SPP client works the same way as the SPP server. A similar 256-byte FIFO buffer is used as in the SPP server. The only differences are that:

Data is received over the air by notifications (event gatt_characteristic_value).

Data is sent by calling gatt_write_characteristic_value_without_response.

The client is a bit more complex than the server because the client needs to be able to detect the SPP server by looking at the advertisement packets. Additionally, the client needs to do service discovery after connecting to the client to get the needed information about the remote GATT database.

To be able to use the SPP service the client needs to know the characteristic handle values. The handles are discovered dynamically so that there is no need to use any hard-coded values. This is essential if the SPP server needs to be ported to some other BLE module and the handle values are not known in advance.

At startup, the client starts discovery by calling le_gap_start_discovery. For each received advertisement packet the stack will raise event le_gap_scan_response. In order to recognize the SPP server the client scans through each advertisement packet and searches for the 128-bit service UUID that we assigned for our custom SPP service.

Scanning of advertisement packets is done in function process_scan_response. The advertising packets include one or more advertising data elements that are encoded as defined in the BT specification. Each advertising element begins with a length byte that indicates the length of that field. This makes it easy to scan through all the elements in a while-loop.

The second byte in advertising element is the AD type. The predefined types are listed in Bluetooth SIG website

In this case, we are interested in types 0x06 and 0x07 that indicate incomplete/complete list of 128-bit service values. If such AD type is found, then the AD payload is compared against the known 128-bit UUID of our SPP service to see if there is a match.

After finding a match in the advertising data the client will open a connection by calling le_gap_connect. When connection is opened, the next task is to discover services and figure out what is the handle value that corresponds to the SPP_data characteristic (see XML definition of our custom service attached).

The service discovery is implemented as a simple state machine and the sequence of operations after connection is opened is summarized below:

1) Call gatt_discover_primary_services_by_uuid to start service discovery

2) Call gatt_discover_characteristics to find the characteristics in the SPP service (in FIND_SERVICE state)

3) Call gatt_set_characteristic_notification to enable notifications for spp_data characteristic (in FIND_CHAR state)

Note that in step 1) above we want to discover only services that match the specific UUID we are looking for. Another option would be to call cmd_gatt_discover_primary_services that will return list of all services in the remote GATT database.

After each procedure in the above sequence is completed, the stack will raise event gatt_procedure_completed. The client uses a variable main_state that is used to keep track what is the current state. The gatt_procedure_completed event will trigger the state machine to move on to the next logical state.

When notifications have been enabled the application is in transparent SPP mode. This is indicated by writing string "SPP Mode ON" to UART. After this point, any data that is received from UART is sent to server using non-acknowledged write transfer. Similarly, all data received via notifications (event gatt_characteristic_value) is copied to the local UART.

Note that on the server application there is also "SPP Mode ON" string that is printed to console. On server side this is done when the remote client has enabled notifications for the spp_data characteristic.

The data is handled transparently, meaning that the program does not care at all what values are transmitted. It can be either ASCII strings or binary data, or mixture of these. The connection can be closed by pressing either of the pushbuttons on the client.

Running the demo

Simplest way to run the demo is to use two WSTKs with the same radio board (for example two BGM13S radio boards). In this case you can use the same binary for both boards.

When the application boots, it checks the state of pushbuttons PB0, PB1. If buttons are not pressed, the application starts in SPP server role.

By keeping either PB0 or PB1 pressed during reboot the application starts in SPP client mode.

In server mode, the device advertises the custom SPP service and waits for incoming connections.

In client mode, the device starts scanning and searches for the custom SPP UUID in the scan responses. If match is found, the client connects to the target, discovers the SPP service and characteristics and then enables notifications for the SPP_data characteristic. At this point, any data that is input in the client side is sent over the air to the server and printed on the remote UART. Similarly, any data input to the server UART is transmitted back to the client.

To connect to the kit using terminal program use the following UART settings: baud rate 115200, 8N1, no flow control.

NOTE: Make sure that you are using the same baud rate and flow control settings in your starter kit and radio board or module firmware as well as your terminal program. For WSTK, this can be checked in

Debug Adapters->Launch Console->serial vcom (config speed/handshake)

The above screencapture illustrates what happens when the client and server boards are powered up. Client is on the left side and server on the right. Quickly after power up the client will find the server and open a connection automatically. When the connection is set up properly and notifications are enabled then both applications will output string "SPP Mode ON". This indicates that the transparent serial connection is open. From this point on, any data you type into the client terminal will appear on the server terminal and vice versa.

You can try pressing reset button on either of the boards and see what happens. The connection should be restored automatically when both units are back online. Pressing either of the buttons on the client board will close the connection and print the stats for the last session to the terminal.

Power management

USART peripheral is not accessible in EM2 sleep mode. For this reason, both the client and the server applications disable sleeping (EM2 mode) temporarily when the SPP mode is active. SPP mode in this context means that the client and server are connected and that the client has enabled notifications for the SPP_data characteristics.

When SPP mode is entered, the code calls SLEEP_SleepBlockBegin(sleepEM2) to temporarily disable sleeping. When connection is closed (or client disables notifications) then SLEEP_SleepBlockEnd(sleepEM2) is called to re-enable sleeping.

For more details on the power management details, see article here.

Known issues

This example implementation does not guarantee 100% reliable transfer. The implementation uses retargetserial driver for reading data from UART. The driver is found in <project_root>/hardware/kit/common/drivers/ . For incoming data, the driver uses a FIFO buffer whose size is defined using symbol RXBUFSIZE (default value 8).

To get more reliable operation, it is recommended to increase the RXBUFSIZE value. However, even with a large FIFO buffer, there is a chance that some data is lost if the data rate is very high. If the FIFO buffer in RAM becomes full, the driver will simply drop the bytes that do not fit in. More discussion about this topic is found in following forum thread: SPP-over-BLE C example for UART receive data is lost

Conclusion

This example is a simple C-based SPP implementation for BGMxxx / EFR32BG products. It is not optimized for performance or low power. The code has been kept as simple as possible.

UART input/output is handled using stdio retarget functions (see this article for details.)

This is not the most efficient way to handle UART input/output but the benefit is that it is portable and allows the sample code to be used easily on several radio boards without any modifications.

Bluetooth projects do not include Gecko Bootloader by default, so you have to add it separately!

In Bluetooth SDKs between v2.0 and v2.6:

• legacy OTA bootloader is included in Software Example projects created for EFR32BG1 devices
• no bootloader is included in Software Example projects created for other devices (EFR32xG12, EFR32xG13)

In Bluetooth SDK v2.7 or later

• no bootloader is included in any Software Exmaple projects
• however, when a Demo is flashed, both bootloader and application is flashed after each other
  • NCP - empty target Demo is flashed along with a BGAPI UART DFU type Gecko Bootloader
  • other Demos are flashed along with Bluetooth OTA type Gecko bootloader (config depends on part)

Devices are shipped with preprogrammed bootloaders:

• EFR32BG1 devices are preprogrammed with legacy bootloader. The legacy bootloader is a one stage simple bootloader that has very limited capabilities compared to Gecko Bootloader. There are two types of the legacy bootloader: UART DFU and OTA DFU. UART DFU is able to upgrade the firmware via UART, OTA DFU is able to upgrade the firmware via Bluetooth connection. Devices are preprogrammed with UART DFU bootloader, but the projects in SDK v2.6 and older contains OTA DFU bootloader by default. Legacy bootloader is not supported since SDK v2.7, so you have to add Gecko Bootloader to your project to overwrite the legacy bootloader. Gecko Bootloader also has UART and OTA configuration, which is compatible with the legacy bootloaders.
   
• Other devices are preprogrammed with dummy bootloader. This bootloader is only able to start the application, but cannot upgrade it, so it is essential to overwrite it with Gecko Bootloader.

To add a Gecko Bootloader to your Bluetooth project do the followings:

First method

1. Build your Bluetooth application
2. Flash your Bluetooth application (.s37 OR .hex OR .bin) to the device.
3. Create a new Gecko Bootloader project, e.g. Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader
   (click New Project button in Simplicity Studio, select Gecko Bootloader, select Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader)
4. Generate and build it
5. Flash the .s37 file that ends with „–combined” (e.g. bootloader-uart-bgapi-s37) file to the device. This will overwrite the legacy bootloader in EFR32BG1 devices or the dummy bootloader in EFR32BG12 devices.

Note: bootloader-uart-bgapi-combined.s37 contains the first+second stage of the Gecko Bootloader, while bootloader-uart-bgapi.* contains only the second stage. The first+second stage is needed when flashing the bootloader the first time, while the second stage is needed when upgrading the bootloader (either by flashing or by DFU).

Second method

1. If you use a EFR32BG1 device with SDK v2.6 or older, remove the legacy bootloader from the Bluetooth application project (If you have other device or later SDK, then skip this):
   1. Right click on your project -> properties
   2. C/C++ build > Settings > IAR Linker for ARM > Library
      or
      C/C++ build > Settings > GNU ARM C Linker > Miscellaneous > Other objects
   3. Remove binbootloader.o
2. Build your Bluetooth application
3. Create a new Gecko Bootloader project, e.g. Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader
   (click New Project button in Simplicity Studio, select Gecko Bootloader, select Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader)
4. Generate and build it
5. Merge the (combined) bootloader and the application image:

   commander convert bootloader-uart-bgapi-combined.s37 your_application.s37 -o app+bootloader.s37

    

6. Flash the merged image to the device

Third method

1. If you use a EFR32BG1 device with SDK v2.6 or older, remove the legacy bootloader from the Bluetooth application project (If you have other device or later SDK, then skip this):
   1. If the .isc file is open in your project, close it first.
   2. Open the .isc file in your project with text editor (right click -> Open With -> Text Editor)
   3. change appPlugin: gecko_bootloader=false to appPlugin: gecko_bootloader=true
   4. change appPlugin: legacy_ble_ota_bootloader=true to appPlugin: legacy_ble_ota_bootloader=false
   5. save and close the .isc file
   6. open the .isc file with App Builder (right click -> Open With -> App Builder)
   7. press Generate
2. Build your Bluetooth application
3. Create a new Gecko Bootloader project, e.g. Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader
   (click New Project button in Simplicity Studio, select Gecko Bootloader, select Bluetooth in-place OTA DFU Bootloader or BGAPI UART DFU Bootloader)
4. Generate and build it
5. Merge the (combined) bootloader and the application image:

   commander convert bootloader-uart-bgapi-combined.s37 your_application.s37 -o app+bootloader.s37

    

6. Flash the merged image to the device

Fourth method (If you have SDK v2.7 or later)

1. Flash a demo to your device
   • flash the SoC - Empty demo to your device first. This will flash SoC - Empty application with Bluetooth in-place OTA DFU type Gecko Bootloader
   • OR: flash NCP target - Empty demo to your device. This will flash NCP target - Empty application with BGAPI UART DFU type Gecko Bootloader
2. Build your Bluetooth application
3. Flash the .hex or the .s37 file to your device. This will not overwrite the bootloader (unlike .bin)

Note: commander.exe can be found in: C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander\

Warning: for SDKs before v2.4.0 the second and third methods work only if you are using IAR as compiler. GCC is fully supported from v2.4.0.

Warning: in SDK v2.3.3 the postbuild step of the bootloader project may fail, and -combined.s37 file may be missing. In this case open the bootloader project, go to "Project > Properties > C/C++ Build > Settings > Build steps", and put the script path between quotes. Rebuild the bootloader project.