BLE - FAQ

From Texas Instruments Wiki
Jump to: navigation, search

Bluetooth Low Energy Main Page


This is the FAQ (Frequently Asked Questions) list of TI's BLE (Bluetooth low energy) solution for CC254x wireless MCUs. For SimpleLink CC26xx and CC13xx wireless MCUs, please see our FAQ on E2E.


General Questions

Where do I learn more about the Bluetooth low energy (BLE) specification, profiles, Notifications, Pairing, etc?

There is a good intro to Bluetooth LE in the Software User's Guide included in the SDK. You can download the BT Core Specification for free from the Bluetooth Special Interest Group (SIG) website in addition to adopted Profiles & Services. Although the core specification is over 2,000 pages, only a few sections are typically referenced in the course of developing a Bluetooth LE application:

  • Generic Access Profile (GAP) - Specifies the role of the device (Peripheral, Central, Broadcaster, etc.): Volume 3, Part C
  • Attribute Protocol (ATT) - Defines discrete data types which are the 'building blocks' of Characteristics: Volume 3, Part F
  • Generic Attribute Profile (GATT) - Defines Characteristics, or an organized method of using Attributes. Volume 3, Part G
  • Security Manager Specification (SMP) - Defines the procedure for the generation and exchange of security keys, also known as Pairing. Volume 3, Part H. Also a good intro on the Bluetooth SIG LE Security page.
  • Link Layer Specification - Lowest layer that manages the connection between devices and defines channel data types. Volume 6, Part B

The vast majority of E2E inquiries related to the Bluetooth core specification are addressed by the above sections of the core specification. In some cases, the above sections cover classic as well as dual-mode operation. Refer to the respective introduction chapter for the LE-only sub sections.

Due to the popularity of the standard, there are also a number of technical books dedicated to understanding BLE. Search "Getting started with Bluetooth low energy" in your favorite book store's search engine.

What version of BLE does CC254x Support?

The CC254x family of BLE wireless MCUs supports the Bluetooth 4.0 LE specification (single mode LE). Newer versions of the Bluetooth specification are backwards compatible with devices supporting the original v4.0 LE specification.

How is a CC254x BLE wireless MCU different from a Bluetooth LE Controller?

In traditional Bluetooth systems, the Bluetooth Controller is a discrete piece of silicon that implements the Link Layer and Physical Layer (PHY) layers of the BT protocol stack (Classic and/or LE). When these Controllers also support a Wi-Fi radio such as on smartphones, they are often referred to as "combo controllers". These controllers are connected to an Application Processor (AP) or MCU over a USB or Serial (SPI or UART) bus using a protocol called HCI, or Host Controller Interface. The HCI protocol allows the external AP to send commands to the Controller when performing various BT functions. Likewise, the AP implements the Host layers of the BT stack, such as GAP, GATT, L2CAP, SMP, etc. The external AP also implements the Bluetooth application which interfaces to the BT Host. (The term Host is often confused with the Central role or master device. In BT/BLE, each peer device implements the Host and Controller functions of the protocol stack).

A "wireless MCU" is a microcontroller that implements the Bluetooth Host, Controller and Application on the same device. This allows for better cost, size and power saving since a single, discrete solution can be used. In the CC254x, the BLE protocol stack (Host & Controller inclusive) is implemented by the BLE-Stack. The application interfaces with the BLE-Stack using a set of prescribed APIs instead of sending HCI commands to the controller directly. In network processor configurations, the wireless MCU implements the BLE Host & Controller while the application resides on another processor. Communication to the wireless MCU occurs using TI Vendor Specific (VS) HCI commands for Host related functions. Details on these VS HCI APIs are in the TI VS API guide included in the SDK. The HostTest sample application in the BLE-Stack SDK implements the network processor configuration.

Note that external BT Host stacks, such as BlueZ, cannot interface to the wireless MCU as these stacks are designed to work with BT Controller-only devices.

BLE Hardware Questions

How can I access the CC254x GPIOs on a SmartRF05

Almost all CC2541 I/Os are available on jumper P1 and/or P10 on the SmartRF05 board:

I/O Mapping
CC2541 SmartRF05
Alt. 1 Alt. 2
P0.0 P10.5 P1.33
P0.1 P10.17
P0.2 P1.7
P0.3 P1.5
P0.4 P1.3
P0.4 P1.1
P0.6 P10.3
P0.7 P10.33
P1.0 P10.21
P1.1 P10.25
P1.2 P10.7 P1.31
P1.3 P10.15
P1.4 P10.29 P1.23
P1.5 P10.13 P1.31
P1.6 P10.11 P1.27
P1.7 P10.9 P1.25
P2.0
P2.1 P1.21
P2.2 P1.19


Do I need a 32 kHz crystal to run BLE?

If you are implementing the POWER_SAVING (using the 1 uA PM2 sleep) in your CC254x design, an accurate 32 kHz clock is needed for the sleep timer to maintain the connection timing required by BLE. If you are mains powered, for example, and do not need to use the POWER_SAVING feature, the timing is maintained with the 32 MHz crystal and no 32 kHz crystal is needed.


Sleep crystal accuracy

According to the Bluetooth 4.0 Core Specifications, a peer device with up to 500 PPM frequency deviation on its sleep clock must be accepted. When selecting a 32.768kHz crystal for a custom board, therefore, you may choose one with up to 500 PPM spread in the production around the expected value.

In TI's BLE stacks, a default PPM value of 40 is used for peripheral- and 50 for central devices. If you select a more inaccurate crystal, this must be compensated in software.

To compensate for sleep clock inaccuracy you can use the command HCI_EXT_SetSCACmd(<ppm_val>); which must be executed during initialization of the device. For central devices, this value is used internally for compensation and also converted to a BLE Spec-defined ordinal which tells peripheral devices how much drift they can expect. For peripheral devices this value is used directly, as the central/initiating device always transmits first in a connection event. Read more about this command in the Vendor Specific HCI Guide included in the TI BLE stack.

The drawback of using a clock with a wider distribution is that the software compensation entails widening the RX-window. That is, the time the device spends listening before the 'real' beginning of a connection event in case either peer has drifted. This consumes more power.


Measuring power consumption

Power measurements over time can be carried out on e.g. a CC2540 KeyFob by following the instructions in our Application Note AN092 Measuring Bluetooth Low Energy Power Consumption.
The application note includes details on how to modify the board, an example measurement and an Excel spreadsheet template for inputting measured data and automatically compute average power consumption.

Some measurements

These measurements were carried out with a CC2541 with a TPS62730 DC-DC step-down converter. Battery life is based on an ideal 230 mAh battery.

  • SimpleBLEPeripheral - Advertising Spreadsheet
    • Time awake: 3.9 ms: 1.28 ms processing after Rx/Tx
    • Average current draw for event only: 8.6 mA
    • Average current draw with 1s interval: 0.035 mA / ~260 days continuously
  • SimpleBLEPeripheral - Empty connection event Spreadsheet
    • Time awake: 3.0 ms: 1.3 ms processing after Rx/Tx
    • Average current draw for event only: 8.9 mA
    • Average current draw with 1s interval: 0.028 mA / ~327 days continuously
  • SimpleBLEPeripheral - Read request to KeyFob, 1 characteristic Spreadsheet
    • Time awake: 5.7 ms: 3.9 ms processing after Rx/Tx
    • Average current draw for event only: 7.5 mA
    • Average current draw with 1s interval: 0.044 mA / ~208 days continuously
  • SimpleBLEPeripheral - Read response from KeyFob, 1 characteristic, 1 byte
    • Time awake: 2.8 ms: 1.3 ms processing after Rx/Tx
    • Average current draw for event only: 8.6 mA
    • Average current draw with 1s interval: 0.026 mA / ~352 days continuously
  • SimpleBLEPeripheral - Write request to KeyFob, 1 characteristic, 1 byte Spreadsheet
    • Time awake: 5.9 ms: 4.1 ms processing after Rx/Tx
    • Average current draw for event only: 7.5 mA
    • Average current draw with 1s interval: 0.045 mA / ~200 days continuously
  • SimpleBLEPeripheral - Write response from KeyFob, 1 characteristic
    • Time awake: 3.1 ms: 1.4 ms processing after Rx/Tx
    • Average current draw for event only: 8.8 mA
    • Average current draw with 1s interval: 0.028 mA / ~327 days continuously
  • SimpleBLEPeripheral - Notification from KeyFob, 1 byte Spreadsheet
    • Time awake: 3.2 ms: 1.4 ms processing after Rx/Tx
    • Average current draw for event only: 8.8 mA
    • Average current draw with 1s interval: 0.029 mA / ~316 days continuously
  • SimpleBLEPeripheral - Notification from KeyFob, 60 bytes looped Spreadsheet
    • Time awake: 8.8 ms: 5.8 ms processing after Rx/Tx
    • Average current draw for event only: 7.89 mA
    • Average current draw with 1s interval: 0.071 mA / ~135 days continuously



BLE Software Questions

Where can i find example codes for the BLE host (PC/Smartphone)?

Please refer: here. There are also sample applications integrated in the BLE-Stack SDK.


Where can i find the example code for BLE SoC (CC2540/1) peripherals?

The BLE-Stack contains example code with HAL (Hardware Abstraction Layers) which can be used as the peripheral drivers. Since the CC254x shares the same hardware peripherals as the CC253x (Zigbee SoC), example codes for CC253x peripherals should also apply to CC254x.

Others can be found as follows:


How many slave devices can be connected to a BLE master simultaneously?

The Bluetooth specification does not really define the maximum number of devices (see here), but using the BLE-Stack (starting from v1.1) the master can support up to 3 simultaneous connections. When operating in the slave role (i.e., as a BLE peripheral), a maximum of one slave connection is permitted.

The following is taken from the Release Notes of BLE-Stack v1.1 and v1.2:


Version 1.2
Feb 13, 2012
- Multi-role and combo-role support has been enhanced. The BLE stack can now
  support simultaneously advertising and/or scanning while in a connection as
  either a master or a slave. This allows for a central device to perform
  device discovery while in a connection. All previous rules for multiple
  simultaneous connections as a central device still apply (see v1.1a release
  notes below).

Version 1.1
July 13, 2011

Changes and Enhancements:

- The stack now supports up to 3 simultaneous connection as a central / master
  device, with a few constraints:

       - All connection intervals must be a multiple of the minimum connection
         interval (i.e. the minimum connection interval is the greatest common
         denominator of all connection intervals).

       - The minimum connection interval allowed is 25ms when using more than
         one connection.

       - When more than one connection is active, only one data packet per
         connection event will be allowed in each direction.


How do I use the Whitelist with iOS and Android devices?

All current versions of Android and iOS use Resolvable Private Addresses (RPAs) when connecting to BLE peripheral devices. This allows the phone to periodically change its Bluetooth Address (BDADDR) without sharing its public BDADDR until it pairs and bonds with a peripheral. Since the use of RPAs in the Controller of privacy enabled Central devices was not defined in the Bluetooth 4.0 specification, using the Whitelist is not possible when connecting to these devices. To workaround this limitation, the BLE application can be updated to resolve these RPAs outside of the Whitelist. Refer to this E2E post for details.


How do I connect a Windows PC to the CC2540?

Starting with Windows 8.1, Microsoft added native support for BLE. However, Windows, similar to BlueZ on Linux, implements the BT/BLE Host layers of the protocol stack and expects to interface with a discrete BT/BLE Controller (Refer to the "How is a CC254x BLE wireless MCU different from a Bluetooth LE Controller?" above for more details). Therefore, for locally-connected (i.e. over USB) CC2540 devices, you must develop a Windows application that communicates using TI BLE VS HCI commands. An example Windows application built using these VS HCI APIs is BTool which is included in the BLE-Stack SDK.

To wirelessly connect to a CC2540/41 peer device from Windows using the PC's Bluetooth Controller, a Windows application is required. TI does not provide example applications using the in-box Windows BT stack.

Note: Bluetooth COM ports are for communicating with Bluetooth Classic devices using the Serial Port Profile (SPP) and thus cannot be used to connect to CC254x BLE wireless devices. The BLE specification does not define an adopted SPP profile for LE devices.


There's been a change in v1.3 of the stack to the max timeout for limited advertising, it's now 180 seconds instead of 30.72. This to follow Bluetooth spec addendum. See Thread #1 and Thread #2 for more information on how to change this.


How can I change the output Power on CC254x?

With the Vendor Specific HCI command HCI_EXT_SetTxPowerCmd(). Allowed parameters that have been characterized by TI:

  • HCI_EXT_TX_POWER_MINUS_23_DBM
  • HCI_EXT_TX_POWER_MINUS_6_DBM
  • HCI_EXT_TX_POWER_0_DBM
  • HCI_EXT_TX_POWER_4_DBM (CC2540 Only)


Using TXPOWER values not listed above may result in undefined power output.

Parameter update request

Sometimes you want to change the connection interval and slave latency from the peripheral side to conserve power, especially when connection to an iOS or Android device. To do this, you can call the function

bStatus_t GAPRole_SendUpdateParam( uint16 minConnInterval, uint16 maxConnInterval, uint16 latency, uint16 connTimeout, uint8 handleFailure )

which is defined and documented in peripheral.c and will send an L2CAP request for parameter update.

Alternatively, see example in simpleBLEperipheral.c, change #define DEFAULT_ENABLE_UPDATE_REQUEST to TRUE near the top and fiddle with the desired parameters. This will cause peripheral.c to issue an update request on the GAP_LINK_ESTABLISHED_EVENT of its gapRole_ProcessGAPMsg(). See simpleBLEperipheral's task init to see how this GAPRole data is communicated to peripheral.c.

Be sure to follow Apple's Bluetooth design guidelines when doing this, as there are limitations on acceptable parameters.



IAR 8.20 Linker error

For BLE-Stack v.1.3, TI recommends to use IAR 8051 EWB 8.10.4 or 8.11.4. For downloading the specific IAR 8051 EWB please refer here.

For a workaround for the SLEEP_CODE segment error, use this workaround.


Which IDE can be used for working with BLE-Stack

Please use the version of IAR that is specified in the SDK's release notes or User Guide. Using another version of IAR is not supported. Note that the full, non-size restricted version of IAR is required. A 30 day trial may be offered from IAR.


How big is the memory footprint of the BLE-Stack?

The answer varies depending on the stack configurations. The size is reported in the map file that is generated during the build process. To give some numbers, the following memory footprint is acquired from the current BLE-Stack examples (as is) compiled using IAR 8051 EWB v8.11.1:

Project Name Memory Footprint
SimpleBLECentral-CC2540EM
118 379 bytes of CODE  memory
     29 bytes of DATA  memory (+ 81 absolute )
  7 246 bytes of XDATA memory
    194 bytes of IDATA memory
      8 bits  of BIT   memory
  4 360 bytes of CONST memory
SimpleBLECentral-CC2541EM
121 188 bytes of CODE  memory
     29 bytes of DATA  memory (+ 81 absolute )
  7 246 bytes of XDATA memory
    194 bytes of IDATA memory
      8 bits  of BIT   memory
    792 bytes of CONST memory
SimpleBLEObserver-CC2540EM
38 926 bytes of CODE  memory
    29 bytes of DATA  memory (+ 81 absolute )
 3 272 bytes of XDATA memory
   194 bytes of IDATA memory
     8 bits  of BIT   memory
 3 847 bytes of CONST memory
SimpleBLEPeripheral-CC2541DK-MINI Keyfob
108 502 bytes of CODE  memory
     35 bytes of DATA  memory (+ 72 absolute )
  6 270 bytes of XDATA memory
    194 bytes of IDATA memory
      8 bits  of BIT   memory
  4 145 bytes of CONST memory
SimpleBLEPeripheral-CC2540EM
110 648 bytes of CODE  memory
     35 bytes of DATA  memory (+ 72 absolute )
  6 270 bytes of XDATA memory
    194 bytes of IDATA memory
      8 bits  of BIT   memory
    581 bytes of CONST memory
Heartrate-CC2540DK-MINI Keyfob Slave
108 110 bytes of CODE  memory
     35 bytes of DATA  memory (+ 74 absolute )
  6 113 bytes of XDATA memory
    194 bytes of IDATA memory
      8 bits  of BIT   memory
  4 151 bytes of CONST memory