Simplicity Studio includes a program called Simplicity Commander. You can find it in the studio installation directory, default location is:
If you launch the program without any options you will see a GUI that is quite intuitive to use. In some cases, users prefer to do the flashing from command line instead of using the GUI. This may more effective if you for example want to create some scripts that will flash one or more devices automatically.
Simplicity Commander can be also run from command line, without the GUI. If you start with option "--help" you will see the options that are available:
The first argument passed to the program is the name of the command to be executed. When flashing a new firmware, the right command is obviously flash.
In the simplest for, you only need to give command name (flash) and name of the binary file to be programmed. Below is an example how to flash a binary named "scanner.bin" into a BGM111 module.
With commander you can also easily read data back from the device flash and dump it into a file. For example, to dump the content of the User Data page in flash (located at offset 0x0FE00000) the usage is as follows:
commander readmem --range 0x0FE00000:0x0FE00800 -o dump_UserData_page.bin
Detailed description of Simplicity Commander features is found in the user guide UG162:
Note: This example is using BGScript which is no longer supported, starting from BLE SDK version 2.4.0, and therefore this KBA has been marked as deprecated. A C-based example showing how to detect button presses with GPIO interrupts is available in following article:
(Following is valid only up to BLE SDK 2.3.3.)
This example project demonstrates how to use interrupts to detect button presses. The example is written for BGM111 development kit.
The features of the example project are:
The key points in the implementation are summarized below.
When a short press is detected, the script will call following procedure:
This is placeholder for user code, it can be mapped to any functions required by your application. The button number is given as parameter. The code can be easily extended to support more than two buttons.
When a long press is detected, the script will call procedure:
In this example, sending of notifications is controlled by the long button presses.
Custom GATT service for testing
This example uses very simple but generic custom GATT service for testing purposes. The service has two characteristics:
1) control_byte: length 1 byte, write and read supported
2) status_vector: variable length, up to 20 bytes. Notifications supported.
The control_byte is used to change behavior of the script somehow. In this example, we use it to set the number of notifications that is sent after PB1 long press. (Default is 30 but a client can change the value by writing to control_byte).
The status vector is used to send notifications to client. In this example, only one byte is used. If PB0 is pressed, then value 0x01 is sent. If PB1 is pressed, then ascending values 0,1,2.. etc are sent using notifications, until the given limit (30 by default) is reached.
How to test it?
Program the application into a BGM111 development kit. If you have a terminal program connected you can see useful debug prints that are sent to the virtual COM port.
Connect to the device (it is named "BGM111 ButtonDemo") and enable notifications for the status_vector characteristic. Try pressing PB1 and PB0 on the development kit for short (< 1 sec) or longer duration and see what happens. It is useful to have a terminal program open to see in more detail what is going on in the script.
Note: This KBA has been marked deprecated. For CTUNE information please refer to UG136: Silicon Labs Bluetooth ® C Application Developer's Guide
The ctune can be used to configure the crystal (XTAL) frequency tuning value.
The crystal tuning value must be set correctly for every design, which is especially important when making your own EFR32 based hardware.
For the official Silicon Labs radio boards which uses Blue Gecko module and SoCs based the ctune setting is the following:
This article aims to explain the difference between acknowledged and unacknowledged GATT operations in Bluetooth Low Energy.
The two following figures show how the data flows between the GATT client and GATT server for a write operation both without and with response (unacknowledged and acknowledged).
It's good to emphasize that the terms acknowledged and unacknowledged apply to GATT operations. This is not just about the data being transmitted across the radio link but also about the data actually reaching the GATT/Application layer. On both acknowledged and unacknowledged GATT operations the data is reliably transported across the radio link. The difference between the two transfer types is in knowing if and when the data sent has actually been received by the application on the other side.
Taking 'user' type characteristics as an example: the response to write operations on these characteristics must be managed by the application. If for some reason the application is not capable of processing the write request then no response will be sent and a timeout will occur after 30 seconds, indicating to the client that it wasn't possible to accept the write request. In applications which need synchronous operation and availability of other resources, such as UART in a cable replacement application, using acknowledged operations is mandatory.
Another example is notifications and indications. Notifications are unacknowledged and indications are acknowledged. The data flow is again depicted below.
To summarize, in both unacknowledged and acknowledged data transfers the data is reliably transported across the radio link but in the former there is no guarantee of delivery at the GATT/Application layer.