an983: bluetooth® 4.0 heart rate sensor

AN983: BLUETOOTH® 4.0 HEART RATE
SENSOR
APPLICATION NOTE
Thursday, 23 May 2013
Version 1.4
VERSION HISTORY
Version
Comment
1.0
First version
1.1
Services added
1.2
Updated BGscript code examples
1.3
Changed broadcast=”true” to advertise=”true”
1.4
Updated compile and installation instructions
Silicon Labs
TABLE OF CONTENTS
Contents
1
Introduction ..................................................................................................................................................... 5
3
Heart Rate Profile v1.0 .................................................................................................................................... 7
3.1 Description..................................................................................................................................7
3.2 Service requirements .................................................................................................................7
3.3 Heart Rate Service requirements ...............................................................................................8
3.4 Device Information Service requirements .................................................................................8
3.5 Other requirements ....................................................................................................................8
3.6 Connection establishment requirement ....................................................................................9
3.6.1
Un-bonded devices ................................................................................................................................ 9
3.6.2
Bonded devices ...................................................................................................................................... 9
3.6.3
Link loss procedure ................................................................................................................................ 9
3.7 Security requirements .............................................................................................................10
4
Implementing a Heart Rate Sensor ............................................................................................................... 11
4.1 Creating a project .....................................................................................................................12
4.2 Hardware configuration............................................................................................................13
4.3 Heart Rate Profile GATT database ...........................................................................................14
4.3.1
Generic Access Profile service ............................................................................................................. 14
4.3.2
Heart Rate Service ............................................................................................................................... 15
4.3.3
Device Information Service .................................................................................................................. 16
4.3.4
Summary.............................................................................................................................................. 18
4.4 Writing BGScript application ...................................................................................................19
4.5 Compiling and installing the firmware ....................................................................................23
5
4.5.1
Using BLE Update tool ......................................................................................................................... 23
4.5.2
Compiling using the bgbuild.exe........................................................................................................... 25
4.5.3
Installing the firmware with TI’s flash tool ............................................................................................. 26
Testing the Heart Rate Sensor ...................................................................................................................... 27
5.1 Testing with BLEGUI ................................................................................................................27
5.1.1
Discovering the Heart Rate Sensor ...................................................................................................... 27
5.1.2
Establishing a connection ..................................................................................................................... 28
5.1.3
Making a service discovery .................................................................................................................. 29
5.1.4
Making a descriptors discovery ............................................................................................................ 30
5.1.5
Reading a characteristics value ........................................................................................................... 31
5.1.6
Starting notifications for HR measurement ........................................................................................... 32
5.1.7
Terminating the connection .................................................................................................................. 33
6
Debugging Heart Rate sensor code .............................................................................................................. 34
7
Appendixes ................................................................................................................................................... 37
Silicon Labs
7.3 BGAPI protocol .........................................................................................................................38
7.4 BGLib library.............................................................................................................................39
7.5 BGScript
TM
scripting language ..............................................................................................40
7.6 Profile toolkit ............................................................................................................................41
7.7 External resources ...................................................................................................................42
Silicon Labs
1 Introduction
This application note discusses how to build Bluetooth 4.0 Heart Rate Profile (HRP) sensor using Bluegiga’s
Bluetooth 4.0 software and DKBLE112 hardware development kits. The application note contains a practical
example of how to build GATT based Heart Rate Profile and how to make a standalone sensor device using
BGScript scripting language.
Notice that this application note only focuses on the Heart Rate Profile sensor implementation, not the Heart
Rate Profile Collector implementation.
Silicon Labs
Page 5 of 43
2 What is Bluetooth low energy technology?
Bluetooth low energy (Bluetooth 4.0) is a new, open standard developed by the Bluetooth SIG. It’s targeted to
address the needs of new modern wireless applications such as ultra-low power consumption, fast connection
times, reliability and security. Bluetooth low energy consumes 10-20 times less power and is able to transmit
data 50 times quicker than classical Bluetooth solutions.
Link: How Bluetooth low energy technology works?
Bluetooth low energy is designed for new emerging applications and markets, but it still embraces the very
same benefits we already know from the classical, well established Bluetooth technology:
•
Robustness and reliability - The adaptive frequency hopping technology used by Bluetooth low
energy allows the device to quickly hop within a wide frequency band, not just to reduce interference
but also to identify crowded frequencies and avoid them. On addition to broadcasting Bluetooth low
energy also provides a reliable, connection oriented way of transmitting data.
•
Security - Data privacy and integrity is always a concern is wireless, mission critical applications.
Therefore Bluetooth low energy technology is designed to incorporate high level of security including
authentication, authorization, encryption and man-in-the-middle protection.
•
Interoperability - Bluetooth low energy technology is an open standard maintained and developed by
the Bluetooth SIG. Strong qualification and interoperability testing processes are included in the
development of technology so that wireless device manufacturers can enjoy the benefit of many
solution providers and consumers can feel confident that equipment will communicate with other
devices regardless of manufacturer.
•
Global availability - Based on the open, license free 2.4GHz frequency band, Bluetooth low energy
technology can be used in world wide applications.
There are two types of Bluetooth 4.0 devices:
•
Bluetooth 4.0 single-mode devices that only support Bluetooth low energy and are optimized for
low-power, low-cost and small size solutions.
•
Bluetooth
4.0
dual-mode
devices
that
support Bluetooth low
energy
and
classical Bluetooth technologies and are interoperable with all the previously Bluetooth specification
versions.
Key features of Bluetooth low energy wireless technology include:
•
Ultra-low peak, average and idle mode power consumption
•
Ability to run for years on standard, coin-cell batteries
•
Low cost
•
Multi-vendor interoperability
•
Enhanced range
Bluetooth low energy is also meant for markets and applications, such as:
•
•
•
•
•
•
•
Automotive
Consumer electronics
Smart energy
Entertainment
Home automation
Security & proximity
Sports & fitness
Silicon Labs
Page 6 of 43
3 Heart Rate Profile v1.0
3.1 Description
Heart Rate Profile enables a Heart Rate Collector to connect and exchange data with a Heart Rate Sensor in
sports and fitness applications.
Heart Rate Profile defines two roles:
•
The Heart Rate Sensor
The Heart Rate Sensor measures the heart rate and exposes it via the Heart Rate Service. The
sensor also contains the Device Information Service, which contains information for example about
the manufacturer of the device. The Heart Rate Sensor is the GATT server.
•
The Heart Rate Collector
The Heart Rate Collector accesses the information exposed by the Heart Rate Sensor and can for
example display it to the end user or store it on non-volatile memory for later analysis. The Heart Rate
Collector is the GATT client.
The figure below shows the relationship of these two roles.
Heart Rate Collector
Heart Rate Sensor
Device Information
Service
Heart Rate Service
Figure 1: Heart Rate profile roles
3.2 Service requirements
The table below describes the service requirements.
Service
UUID
Heart Rate Sensor
Heart Rate Service
180A
Mandatory
Device Information Service
180D
Mandatory
Table 1: Service requirements
The Heart Rate Sensor implements one and only one instance of Heart Rate Service.
The Heart Rate Sensor implements one instance of Device Information Service.
Silicon Labs
Page 7 of 43
3.3 Heart Rate Service requirements
The table below describes the structure and requirements for the Heart Rate Service
Characteristic
UUID
Type
Support
Security
Properties
Heart rate measurement
2A37
8bit
Mandatory
none
Notify
Body sensor location
2A38
8bit
Optional
none
Read
Heart rate control point
2A39
8bit
Conditional
none
Write
Table 2: Heart Rate Service structure
3.4 Device Information Service requirements
The table below describes the structure and requirements for the Device Information Service when used in the
context of Heart Rate Service.
Characteristic
UUID
Type
Support
Security
Properties
Manufacturer name string
2A29
UTF-8
Mandatory
none
Read
Table 3: Device Information Service structure
3.5 Other requirements
The Heart Rate Sensor should include the Heart Rate Service UUID in the advertisement data.
The Heart Rate Sensor should include the device name in the advertisement or scan response data.
The Heart Rate Sensor may support write property for the local name for the device name characteristic so
the Collector can write its value.
Silicon Labs
Page 8 of 43
3.6 Connection establishment requirement
3.6.1 Un-bonded devices
Advertisement duration
Parameter
Value
First 30 seconds
Advertising interval
20ms to 30ms
After 30 seconds
Advertising interval
1000ms to 2500ms
Table 4: Advertising parameters for un-bonded Heart Rate Sensor
1. The Heart Rate Sensor shall accept any valid values for connection interval and slave latency set by
the Collector until service discovery, bonding and/or encryption have are complete. After this the
sensor may request the change of connection parameters.
2. If the connection is not established within a time limit, the sensor may exit GAP Connectable mode.
3. If bonded the Heart Rate Sensor should write the address of the Collector to the white list and should
set the filtering policy so that scan and connection requests are only accepted from devices on the
white list.
4. When the Heart Rate Sensor no longer senses the heart rate it should terminate the connection for
example within 10 or 20 seconds.
5. When Heart Rate Sensor is disconnected by the Collector and ready to receive a connection (i.e.
senses the heart rate) it should initiate the connection procedure.
3.6.2 Bonded devices
The following produce is uses for bonded devices:
1. The Heart Rate Sensor should use GAP General discoverable mode with connectable undirected
advertisement events.
2. For the first 10 seconds the white list should be used to allow only connections from bonded devices.
After 10 seconds the white list should not be used to allow connections from other devices.
3. The advertisement parameters should be as in Table 4.
4. The Heart Rate Sensor shall accept any valid values for connection interval and slave latency set by
the Collector until service discovery, bonding and/or encryption have are complete. After this the
sensor may request the change of connection parameters.
5. If the connection is not established within a time limit, the sensor may exit GAP Connectable mode.
6. When the Heart Rate Sensor no longer senses the heart rate it should terminate the connection for
example within 10 or 20 seconds.
7. When Heart Rate Sensor is disconnected by the Collector and ready to receive a connection (i.e.
senses the heart rate) it should initiate the connection procedure.
3.6.3 Link loss procedure
When connection is terminated due to link loss the sensor should attempt reconnection with the Collector by
entering the GAP connectable mode using the recommended parameters from Table 4.
Silicon Labs
Page 9 of 43
3.7 Security requirements
1
The Heart Rate Sensor may bond with the Collector.
2
When bonding is not used:
2.1
3
The Heart Rate Sensor should use the Slave Security Request procedure to inform the Collector of its
security requirements.
When bonding is used:
3.1
The Heart Rate Sensor shall use LE security Mode 1 and either Security Level 2 or 3.
3.2
The Heart Rate Sensor shall use the Slave Security Request procedure.
3.3
All supported characteristics specified by the Heart Rate Service shall be set to Security Mode 1 and
either Security Level 2 or 3.
All supported characteristics specified by the Device Information Service should be set to the same security
mode and level as the characteristics in the Heart Rate Service.
Silicon Labs
Page 10 of 43
4 Implementing a Heart Rate Sensor
The chapter contains step by step instructions how to implement a stand-alone Heart Rate Sensor with
Bluegiga’s Bluetooth 4.0 Software Development Kit. The chapter is split into following steps:
1. Creating a project
2. Defining hardware configuration
3. Building Heart Rate and Device Information Services with Profile Toolkit
4. Writing a BGScript code
5. Compiling the GATT database and BGScript into a binary firmware
6. Installing the firmware into BLE112 or DKBLE112 hardware
The actual project comes as an example with the Bluegiga’s Bluetooth low energy Software Development Kit.
Note: This application note is written for firmware version 0.2.0 build 30.
Silicon Labs
Page 11 of 43
4.1 Creating a project
The Heart Rate Sensor implementation is started by first creating a project file (project.xml), which defines
the resources use by the project and the firmware output file.
Figure 2: Project file
•
<gatt>
Defines the XML-file containing the GATT database.
•
<hardware>
Defines the XML-file containing the hardware configuration.
•
<script>
Defines the BGScript-file which contains the BGScript code.
•
<image>
Defines the output HEX file containing the firmware image.
WARNING:
This example MUST only be installed on BLE112 module or DKBLE112 development kit. The example does
not use USB or UART interfaces, so the firmware can be installed only via the debug interface using CC
debugger. Installing the example into BLED112 USB dongle will brock the device.
Silicon Labs
Page 12 of 43
4.2 Hardware configuration
The hardware.xml file contains the hardware configuration for BLE112 device. It describes which interfaces
and functions are in used and their properties.
Figure 3: Hardware configuration for Heart Rate Sensor
•
<sleeposc>
Sleep oscillator is enabled to allow the device to enter low power modes like
Power mode 3. If this configuration is not used, the BLE112 device will not go to power mode 3. 30
refers to the crystal accuracy used in BLE112. Do not modify the value.
•
<usb>
modes.
•
<txpower>
TX power is set to +3dBm value. Every step represents 1 dBm change. Range is
15 to 0, corresponding TX power values from +3 dBm to -12 dBm.
USB interface is disabled to save power and allow the device to go to low power
This example uses a single ADC to read the heart rate value. DKBL112 development kit contains a
potentiometer, which can be read with the ADC.
Typically in a real heart rate sensor a GPIO would be used to indicate the heartbeat and a GPIO pin would be
used to detect it. This requires that one GPIO pin is configured as an input.
Silicon Labs
Page 13 of 43
4.3 Heart Rate Profile GATT database
This section describes how to define the Heart Rate Profile services using Bluegiga’s Profile Toolkit.
The Heart Rate Profile contains three services:
•
Generic Access Profile (GAP) service
•
Device Information Service (DIS)
•
Heart Rate Service (HRS)
This example contains a minimum implementation of the above services, so only mandatory characteristics
are used. You may also implement the optional characteristics.
4.3.1 Generic Access Profile service
Every Bluetooth low energy device needs to implement a GAP service. The GAP service is very simple and
consists of only two characteristics. An example implementation of GAP service is show below.
The service has two characteristics, which are explained in Table 5. In this example the characteristics are
read-only, so they are also marked as const. Constant values are stored on the flash of BLE112 and the
value is defined in the GATT database. Constant values cannot be changed.
Figure 4: GAP service
Characteristic
UUID
Type
Support
Security
Properties
Device name
2a00
UTF8
Mandatory
none
Read
(optionally write)
Appearance
2A01
16bit
Mandatory
none
Read
Table 5: GAP (UUID: 1800) service description
Silicon Labs
Page 14 of 43
4.3.2 Heart Rate Service
The Heart Rate Sensor must also implement the Heart Rate Service. The example implementation uses a
simplified Heart Rate Service with just the mandatory characteristics, but optionally you may implement the full
Hear Rate Service with the optional characteristics also.
Heart Rate Service is described below:
Characteristic
UUID
Type
Support
Security
Properties
Heart Rate Measurement
2a37
16 bits to 56 bits
Mandatory
none
Notify
Body Sensor location
2a38
8 bit
Optional
none
Read
Heart Rate Control Point
2a39
8 bit
Conditional
none
Write
Table 6: Heart Rate Service (UUID: 180D) description
Hear rate service specification: Hear Rate Service specification: Hear rate service specification
Hear Rate service at Bluetooth developer web site: Heart Rate Service
The example implementation of the minimum Heart Rate Service is shown below:
Figure 5: Minimal Heart Rate Service
A few explanations are needed:
•
First of all the advertise=”true” option is needed for the Hear Rate Service UUID to be broadcasted
in the advertisement packets. For example the Apple iPhone 4S is not able to discover devices, if the
service UUIDs are not broadcasted.
•
The id=”xgatt_HRS_2a37” defines the attribute ID, which the BGScript application can use to update
the Heart Rate measurement values.
•
The length of the Heart Rate measurement is 16-bits in this example. The first 8 bits define the flags
for the Heart Rate measurement value and the next 8 bits contain the actual measurement value.
•
Body Sensor location and Heart Rate Control Point characteristics are not used in this example as
they are not mandatory.
Silicon Labs
Page 15 of 43
4.3.3 Device Information Service
The third mandatory service the Heart Rate Sensor must implement is the Device Information Service. This
service exposes information about the manufacturer of the device and optionally other information about the
device, which is for example device model number and software version. The example implementation uses a
simplified Device Information Service with just the mandatory characteristics, but optionally you may
implement the full Device Information Service with the optional characteristics also.
Device Information Service is described below:
Characteristic
UUID
Type
Support
Security
Properties
Manufacturer name string
2a29
UTF-8s
Conditional
none
Read
Model number string
2a24
UTF-8s
Conditional
none
Read
Serial number string
2a25
UTF-8s
Conditional
none
Read
Hardware revision string
2a27
UTF-8s
Conditional
none
Read
Firmware revision string
2a26
UTF-8s
Conditional
none
Read
Software revision string
2a28
UTF-8s
Conditional
none
Read
System ID
2a35
uint40 or
uint64
Conditional
none
Read
IEEE 11073-20601 Regulatory Certification
Data List
2a36
reg-cert-datalist
Conditional
none
Read
Table 7: Device Information Service (UUID: 180A) description
Device Information Service specification: Hear Rate Service specification: Device Information Service
specification
Device Information Service at Bluetooth developer web site: Device Information Service
Silicon Labs
Page 16 of 43
The example implementation of the minimum Device Information Service is shown below:
Figure 6: Minimal Device Information Service
A few explanations are needed:
•
The Heart Rate Profile service only mandates that Manufacturer Name String characteristic is
implemented, but the example also implements the Model Number String characteristic.
Silicon Labs
Page 17 of 43
4.3.4 Summary
The full GATT database implementation is shown below.
Figure 7: Heart Rate Profile GATT database
Silicon Labs
Page 18 of 43
4.4 Writing BGScript application
The example implements a standalone Heart Rate Sensor device where no external host processor is
needed. The Heart Rate Sensor application is created as a BGScript script application and the BGScript code
explained in this chapter.
BGScript uses an event based programming approach. The script is executed when an event takes place, and
the programmer may register listeners for various events.
The Heart Rate Sensor BGScript uses the following event listeners:
1. system_boot(…) event listener
When the system is started a boot event is generated and this event listener should be the entry point
for all the BGScript applications. In the example above, when the system is started, the unit starts to
advertise, enables bonding mode, and starts a timer.
Figure 8: system_boot(...) event listener
Silicon Labs
Page 19 of 43
2. hardware_soft_timer(…)event
listener
When the timer expires this event is generated. In the Heart Rate Sensor example the timers are used
to alter the advertising intervals and read HR sensor.
Figure 9: hardware_soft_timer(…) event listener
Silicon Labs
Page 20 of 43
3. hardware_adc_result(…)event
listener
The ADC read function generates an ADC event, which this event listener captures. The ADC result
event is used to read the HR value and write it to GATT database.
Figure 10: hardware_adc_result(…) event listener
4. connection_status(…)event listener
This event takes place when the device is connected. The code changes the connection status
parameter and starts the HR measurement timer.
Figure 11: connection_status(…) event listener
Silicon Labs
Page 21 of 43
5. connection_disconnected(…)event
listener
The last event handler is executed when the Bluetooth is lost or closed by the remote device. The
event listener restarts the advertisement procedure.
Figure 12: connection_disconnected(…) event listener
Silicon Labs
Page 22 of 43
4.5 Compiling and installing the firmware
4.5.1 Using BLE Update tool
When you want to test your project, you need to compile the hardware settings, the GATT data base and
BGScript code into a firmware binary file. The easiest way to do this is with the BLE Update tool that can be
used to compile the project and install the firmware to a BLE112 module using a CC debugger.
In order to compile and install the project:
1. Connect CC debugger to the PC via USB
2. Connect the CC debugger to the debug interface on the BLE112
3. Press the button on CC debugger and make sure the led turns green
4. Start BLE Update tool
5. Make sure the CC debugger is shown in the Port drop down list
6. Use Browse to locate your project.xml file
7. Press Update
BLE Update tool will compile the project and install it into the target device.
Figure 13: Compile and install with BLE Update tool
Silicon Labs
Page 23 of 43
The View Build Log opens up a dialog that shows the bgbuild compilere output and the RAM and Flash
memory allocations.
Figure 14: BLE Update build log
Silicon Labs
Page 24 of 43
4.5.2 Compiling using the bgbuild.exe
The project can also be compiled with the bgbuild.exe command line compiler. The BGBuild compiler simply
generates the firmware image file, which can be installed to the BLE112.
In order to compile the project using BGBuild:
1. Open Windows Command Prompt (cmd.exe)
2. Navigate to the directory where your project is
3. Execute BGbuild.exe compiler
Syntax: bgbuild.exe <project file>
Figure 15: Compiling with BGBuild.exe
If the compilation is successful a .HEX file is generated, which can be installed into a BLE112 module.
On the other hand if the compilation fails due to syntax errors in the BGScript or GATT files, and error
message is printed.
Silicon Labs
Page 25 of 43
4.5.3 Installing the firmware with TI’s flash tool
Texas Instruments flash tool can also be used to install the firmware into the target device using the CC
debugger.
In order to install the firmware with TI flash tool:
1. Connect CC debugger to the PC via USB
2. Connect the CC debugger to the debug interface on the BLE112
3. Press the button on CC debugger and make sure the led turns green
4. Start TI flash tool tool
5. Select program CCxxxx SoC or MSP430
6. Make sure the target device is recognized and displayed in the System-on-Chip field
7. Make sure Retain IEEE address.. field is checked
8. Select the .HEX file you want to program to the target device
9. Select Erase, Program and Verify
10. Finally press Perform actions and make sure the installation is successful
Figure 16: TI’s flash programmer tool
Note:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK v.1.1 or newer, but BLE Update tool
should be used instead. The BLE112 and BLED112 devices contain a security key, which is needed for the
firmware to operate and if the device is programmed with TI flash tool, this security key will be erased.
Silicon Labs
Page 26 of 43
5 Testing the Heart Rate Sensor
5.1 Testing with BLEGUI
This section describes how to test the Heart Rate Sensor application with BLEGUI software.
5.1.1 Discovering the Heart Rate Sensor
As soon as the Heart Rate Sensor is powered on it starts to advertise itself. A BLED112 USB dongle can for
example be used to scan for the sensor together with BLEGUI software.
Start Generic Scan to discover the device.
Figure 17: Scanning with BLEGUI
Silicon Labs
Page 27 of 43
5.1.2 Establishing a connection
Simply select the DKBLE112 heart rate device and press the Connect button in the BLEGUI user interface.
Figure 18: Establishing connection with BLEGUI
Silicon Labs
Page 28 of 43
5.1.3 Making a service discovery
1. Press the GATT button to start GATT tool
2. Press Service Discover button to start a GATT primary service discovery procedure
Figure 19: GATT service discovery
The three services defined in the GATT database are visible in the device.
Silicon Labs
Page 29 of 43
5.1.4 Making a descriptors discovery
1. In order to discover the characteristics of the Device Information Service, select the service and press
Descriptors Discover button
2. A list of service descriptors are shown
Figure 20: GATT descriptors discovery
Silicon Labs
Page 30 of 43
5.1.5 Reading a characteristics value
1. To read a characteristic value, select the characteristic you are interested in and press the Read
button. For example the Manufacturer Name String has a read property, so the value can be read by
a GATT client.
Figure 21: Reading Manufacturer Name String
Silicon Labs
Page 31 of 43
5.1.6 Starting notifications for HR measurement
1. Heart Rate Measurement characteristic has a notify property
2. This means the Heart Rate Sensor notifies the characteristic value changes to the Heart Rate
Collector, instead of the collector having to read it constantly.
3. To enable notifications:
o Perform descriptors discovery to the Heart Rate Service
o Write “0x01” to the Client Characteristic Configuration
The Heart Rate Sensor starts to notify the HR measurements at 1 second interval
Figure 22: Enabling HR measurement notifications
Silicon Labs
Page 32 of 43
5.1.7 Terminating the connection
To terminate the connection:
1. Press the Disconnect button
The Heart Rate Sensor restarts the advertisement procedure for the next 60 seconds, until it stops
advertisements and goes to Power Mode 3.
After 60 seconds you need to reset the device to restart the advertisements.
Figure 23: Terminating the connection
Silicon Labs
Page 33 of 43
6 Debugging Heart Rate sensor code
Debugging BGScript is easiest achieved over the USB interface. You can add debug prints to the BGScript
code and then monitor them via the USB interface for example with terminal software.
The enable debugging a few modifications are needed.
First you need to enable USB interface and give the access to it to BGScript. This can be done with the
following modifications to the hardware.xml file.
Figure 24: Hardware configuration with USB enabled and access give to BGScript
Silicon Labs
Page 34 of 43
To print the actual debug messages modifications to the BGScript code is needed. The debug messages are
printed to USB with system_endpoint_tx(…) command and a few examples are shown below.
Figure 25: BGscript code with debug prints
call system_endpoint_tx(3,5,”BOOT\n”) prints the actual debug messages. 3 refers to endpoint USB, 5
means that 5 bytes are written. “BOOT\n” is the actual message.
NOTE:
The “BOOT\n” message is actually never received by a terminal software when USB interface is used,
because the operating system enumerates the USB when the message is being printed. Other messages will
however be visible. If UART interface is used, the also the “BOOT\n” message can also be received.
Silicon Labs
Page 35 of 43
Monitoring debug messages can be done with a standard terminal software.
Figure 26: Monitoring debug messages
Silicon Labs
Page 36 of 43
7 Appendixes
7.1 Bluegiga’s Bluetooth 4.0 single mode stack suite
Bluegiga’s Bluetooth 4.0 single mode stack suite provides a complete development framework for Bluetooth
low energy application implementers.
The Bluetooth 4.0 single mode stack suite framework supports two architectural modes:
•
All software including: Bluetooth 4.0 single mode stack, profiles and end user application all run on the
Bluegiga's Bluetooth 4.0 single mode hardware
•
The Bluetooth 4.0 single mode stack and profiles run on the Bluegiga 4.0 single mode hardware but
the end user application runs on a separate host (a micro controller for example)
The benefits of the development suite in either of the use cases is that it provides a complete Bluetooth 4.0
single mode stack so that no Bluetooth development is required, a well-defined transport protocol exists
between the host and the Bluetooth hardware and also simple development tools are available for embedding
the end user applications on the Bluetooth 4.0 single mode hardware.
The Bluetooth 4.0 single mode development suite consists of several components:
•
A Bluetooth 4.0 single mode stack
•
Binary based communication protocol (called BGAPI) between the host and the Bluetooth stack
•
A C library (called BGLib) for the host that implements the BGAPI protocol
•
BGScript scripting language and interpreter for implementing applications on the Bluetooth 4.0
single mode hardware
•
A Profile Toolkit for quick and easy development of GATT based Bluetooth services
TM
7.2 Bluetooth 4.0 single mode stack
The Bluetooth 4.0 single mode stack is a full, embedded implementation of Bluetooth v.4.0 compatible stack
software and it’s dedicated for Bluegiga’s Bluetooth 4.0 single mode modules. The stack implements all
mandatory functionality for a single mode device. The structure and layers of the stack are illustrated in the
figure below.
Figure 27: Bluetooth 4.0 single mode stack
Silicon Labs
Page 37 of 43
7.3 BGAPI protocol
For applications where a separate host is used to implement the end user application, a transport protocol is
needed between the host and the Bluetooth stack. The transport protocol is used to communicate with the
Bluetooth stack as well to transmit and receive data packets. his protocol is called BGAPI and it's a binary
based communication protocol designed specifically for ease of implementation within host devices with
limited resources.
The BGAPI provides access to the following layers:
•
Generic Access Profile - GAP allows the management of discoverability and connetability modes
and open connections
•
Security manager - Provides access the Bluetooth low energy security functions
•
Attribute database - An class to access the local attribute database
•
Attribute client - Provides an interface to discover, read and write remote attributes
•
Connection - Provides an interface to manage Bluetooth low energy connections
•
Hardware - An interface to access the various hardware layers such as timers, ADC and other
hardware interfaces
•
Persistent Store - User to access the parameters of the radio hardware and read/write data to nonvolatile memory
•
System - Various system functions, such as querying the hardware status or reset it
The BGAPI protocol is intended to be used with:
•
a serial UART link or
•
a USB connection
Silicon Labs
Page 38 of 43
7.4 BGLib library
For easy implementation of BGAPI protocol an ANSI C host library is available. The library is easily portable
ANSI C code delivered within the Bluetooth 4.0 single mode energy development suite. The purpose is to
simplify the application development to various host environments.
Figure 28: BGLib host library
Silicon Labs
Page 39 of 43
7.5 BGScriptTM scripting language
Bluegiga's Bluetooth 4.0 single mode energy products allow application developers to create standalone
devices without the need of a separate host. The Bluetooth low energy modules can run simple applications
along the Bluetooth 4.0 single mode stack and this provides a benefit when one needs to minimize the end
product size, cost and current consumption. For developing standalone Bluetooth low energy applications the
development suite provides a simple BGScript scripting language. With BGScript provides access to the same
software and hardware interfaces as the BGAPI protocol. The BGScript code can be developed and compiled
with free tools provided by Bluegiga.
Figure 29: BGScript application model
BGScript code example:
# System Started
event system_boot(major, minor, patch, build, ll_version, protocol_version,hw)
#Enable advertising mode
call
gap_set_mode(gap_general_discoverable,gap_undirected_connectable)
#Enable bondable mode
call sm_set_bondable_mode(1)
#Start timer at 1 second interval (32768 = crystal frequency)
call hardware_set_soft_timer(32768)
end
Silicon Labs
Page 40 of 43
7.6 Profile toolkit
The Bluetooth low energy profile toolkit a simple set of tools, which can used to create GATT based Bluetooth
services. The profile toolkit consists of a simple XML based service description language template, which
describes the devices local GATT database as a set of services. The profile toolkit also contains a compiler,
which converts the XML to binary format and generates API to access the characteristic values.
Figure 30: A profile toolkit example of GAP service
Silicon Labs
Page 41 of 43
7.7 External resources
•
Bluetooth 4.0 software development kit is available at : http://techforum.bluegiga.com
•
BLE112 and DKBLE112 hardware documentation is available at : http://techforum.bluegiga.com
•
Heart Rate Profile can be downloaded from: Heart Rate Profile
•
Bluetooth SIG’s developer portal: https://developer.Bluetooth.org/
Silicon Labs
Page 42 of 43
Simplicity Studio
One-click access to MCU and
wireless tools, documentation,
software, source code libraries &
more. Available for Windows,
Mac and Linux!
IoT Portfolio
www.silabs.com/IoT
SW/HW
www.silabs.com/simplicity
Quality
www.silabs.com/quality
Support and Community
community.silabs.com
Disclaimer
Silicon Laboratories 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 Laboratories 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 Laboratories reserves the right to
make changes without further notice and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the
included information. Silicon Laboratories shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses
granted hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System without the specific written consent
of Silicon Laboratories. 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 Laboratories products are not designed or authorized for military applications. Silicon Laboratories 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.
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®,
ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress® and others are trademarks or registered trademarks of Silicon Laboratories Inc. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. 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
Download PDF