Note: BGScript is no longer supported since SDK 2.4.x. We encourage all customers still using BGScript to migrate their applications to C since GCC support was also added in 2.4.x.
This example demonstrates how to access the BMA280 accelerometer chip that is mounted on the expansion board that is delivered with the BGM111 development kit (SLWSTK6101A). The example is a BGScript application that uses just basic GPIO read/write operations (bit-banging) to implement the SPI transactions. The source files are included as one zip file at the end of this article.
The example will allow you to experiment with the accelerometer that is included in the kit. It also serves as an example on how to implement some simple serial interface protocols using bit-banging. At the time of writing this document, the SPI peripheral support is not yet included in the BGM111 SDK (v 0.9.2-446). This example does not require HW SPI support so it is not dependent on the SDK version.
A picture of the BGM111 development board with the expansion board attached is shown below.
To run this example, you need:
The accelerometer samples are printed via UART to the terminal program. The same values are also exposed through a simple GATT service using nofitications. You can use some generic BLE test application to read the accelerometer samples using a smartphone or tablet.
At boot, the script enables advertising and starts a soft timer that is running continuously. Most of the functionality is inside the timer handler.
First the program does an SPI self-test to check that the SPI interface between BGM111 and the sensor (BMA280) works as expected. The self-test writes some generic purpose registers in the sensor and reads the same values back to compare that the values match. The self-test will fail if for example the expansion board is not attached to the main board.
After the self-test is completed, the program will simply just read the accelerometer samples once per timer event. Three samples are read, one per each axis (X, Y, Z). The three accelerometer samples are printed in the terminal using hex notation.
If a remote client is connected then the accelerometer data is also pushed to client using notifications. (Note that to receive the notifications client must subscribe to the notifications by writing to the corresponding client characteristic configuration.)
The program also blinks a LED on the board (LED0) to indicate connection status. When the module is advertising and no connection is active then the LED is blinking slowly with a “heart beat” pattern, about once per second. If connection is open the LED will blink faster with a 50/50 duty cycle.
Running the demo
The following screenshot illustrates how the debug output will look like in a terminal program when the program is running. Debug output is handled using the on-board USB-to-UART converter in the development kit. When you connect the kit to your PC it will be visible as a virtual COM port and the name is “COMx: JLink CDC UART Port”.
The following screenshot is made using an Android phone and a 3rd party utility called BLE Tool. After enabling notifications the three accelerometer samples will be updated continuously.
If you change the orientation of the development kit or move it you can observe how the accelerometer data changes.
The project consists of following files:
This is a typical organization of a BGScript project. The *.bgproj file defines what files are included in the project and what is the target device. Application is in accm_bgscript.bgs. The procedures that implement SPI write and read are separated into spi_bitbang.bgs.
The HW configuration is in file accm_hardware.xml. This file configures the GPIO pins needed for SPI and LED output and also the UART interface.
The GATT is defined in accm_gatt.xml. This project implements a custom GATT service so that remote client can access the accelerometer data by subscribing to notifications. The accelerometer data is visible through a custom characteristic with UUID ed3d929d-aaa7-4bf7-b222-bcff617d272d. Data length is three bytes, one byte for each sample (axis).
SPI interface details
To access the BMA280 accelerometer we need to support read and write operations. The details are described in the BMA280 manual that is available online.
For both write and read, the basic structure is the same. The SPI frame consists of 16 bits and the first bit is a read/write selector (1=read, 0 = write). The R/W bit is followed by a 7-bit address field.
The lower 8 bits are used for data. In case of write operation, the data is written by host (i.e. BGM111). In case of read, the data is written by the sensor (BMA280).
SPI uses separate lines for write and read and in principle it is possible to both send and receive data simultaneously. However, in this case the interface is such that data is transferred only in one direction at a time.
The SPI bitbang used in this project is accessible through two procedures:
* procedure spi_write(address, value)
* procedure spi_read(address)
When calling SPI write, the register address and value are simply passed as parameters. The SPI write procedure is in this project used only for the self-test part.
When calling spi_read() the register address is given as argument. The read result is stored in a global variable named spi_data_in (declared in file spi_bitbang.bgs). This variable is declared with the “export” keyword so that it is also accessible from the main program.
The logic analyzer screenshot below illustrates a single SPI transaction (read operation). The duration of one clock cycle is 280 microseconds which corresponds to 3,6 kHz. One 16-bit transaction takes about 4.6 milliseconds to complete. This means that the maximum number of samples that can be read with this implementation is in the order of 200 samples per second.
To get the raw sensor values from BMA280 it is enough just to read three registers at addresses 0x03, 0x05 and 0x07. For details, see the register map in BMA280 manual. These three registers actually contain just the most significant part of the acceleration values. The samples are 14-bit wide but this demo only reads the most significant 8 bits for simplicity.
The source files are included in one archive named accm_slave.zip, see download link below.
How to program an external BGM111, which not mounted to the radio board, using the WSTK?
First thing to make sure is that the target board, on which the BGM111 is placed, has the programming pins exposed. For programming a BGM111 you need to have the serial wire pins SWCLK and SWDIO, RESET, VCC and ground exposed from the design to connect those the WSTK debug header. The WSTK will not power the module from the debug connector, but the VCC is used to adjust the voltage levels on the programmer's level-shifters.
The WSTK debug connector is a ARM 20-pin debug connector, the pin mapping of the connector can be found below:
Please refer to UG122: SLWSTK6101A User's Guide ( https://www.silabs.com/Support%20Documents/RegisteredDocs/UG122.pdf pp.7) for more information on the pin mappings.
The schematics for the programming header connections and the minimal BGM111 reference design can be found from this Knowledgebase article:
The EACommander software can be used program devices connected to the WSTK. It can be also used to change the programming interface between options exposed by the WSTK. The software is located in the \bin\-folder of the BGM111 SDK.
Once the program is running first connect to a WSTK kit, the Debug source should be changed to 'Out' to be able to program an external module.
Once the debug mode has been changed to 'Out', a LED next to the debug connector will be lit.
The firmware binary can be then flashed to the module from the "Flash" tab. Before applying the 'Flash EFM32' command, a binary file of the project has to be build using the BGBuild.exe in the SDK. How to create and build a project is explained in the software getting started guide.
2] Command line tool
The Bgbuild.exe itself can also be used to program the binary to the module. With the command line parameter '-f' the project gets build and flashed. However, if an external device is to be programmed, the debug connector needs to be activated by using eACommander and take the steps above.
For more information on the programming header on the WSTK, please refer to the app note AN958: Debugging and Programming Interfaces for Custom Designs (http://www.silabs.com/support%20documents/technicaldocs/an958-mcu-stk-wstk-guide.pdf)