No Matches

Support for the SimpleLink™ CC2650 sensor tag. More...

Detailed Description

Support for the SimpleLink™ CC2650 sensor tag.


The CC2650STK is an 'IoT kit' with 10 sensors, a fancy case, and a radio unit that is capable of irradiating IEEE802.15.4 and BLE (or SMART or whatever they call it now).

Use BOARD=cc2650stk for building RIOT for this platform.


MCU CC2650f128
Family ARM Cortex-M3
Vendor Texas Instruments
Flash 128KiB
Frequency - Standby 31.26kHz, 32kHz or 32.768kHz
Frequency - Active / Idle 48MHz
RF core ARM Cortex-M0 CPU, 4KiB RAM
Timers 4x 32-bit
ADCs 1x 12-bit (8 channels)
SPIs 2
I2C 1
I2S 1
Datasheet Datasheet
Reference Manual Reference Manual

Implementation Status

It's an ongoing process...

Module Status
Cortex-M3 Partial support Missing: energy saving features
Hardware buttons OK
Timers Unstable See #5631
RF core Work in progress See here.


The arm-none-eabi toolchain works fine. You can get it here.

Programming and Debugging

You'll need debugging hardware. So far, the XDS110 debug probe has been tested. That bugger requires you to load a firmware onto it each time it powers up. The tool is contained in the Uniflash utility or the CodeComposer Studio from TI. Look for a folder called uscif in the installation directory, go to the folder xds110 therein, and follow the instructions in the ReadMe.txt.

The process is relying on proprietary TI softsoftware. If you're on Windows you can use the stuff linked to on the product websites.

On Linux, there's an application called Uniflash. Sadly, you'll have to install the whole IDE just to get the scripting interface :-[

No idea about macOS.

In order to flash the CC2650STK you need to plug the XDS110 probe through the JTAG and so-called "DevPack" connectors. Note that the back of the SensorTag case has a removable plastic cut-out: as a result the XDS110 can be used while the CC2650STK is still protected in its case. For the flashing process to be successful, the CC2650STK needs to be powered by a working battery.

Once your application code has compiled, you need to indicate the path to your UniFlash tool. You can do it in two ways:

  1. Add export UNIFLASH_PATH = your_path to boards/cc2650stk/Makefile.include and then run make BOARD=cc2650stk flash
  2. Use the command make BOARD=cc2650stk UNIFLASH_PATH=your_path flash to flash the board. If you're lazy you can create an alias to do it with the following command: ‘alias cc2650stkmake='make BOARD=cc2650stk UNIFLASH_PATH=your_path flash’`

In both cases you can add term at the end of the make command to enter the pyterm console directly. After the board has been flashed, it needs to be manually reset using the reset button on the XDS110 probe.


<strong>Bluetooth Low Energy on the CC2650STK</strong>

This section is meant to provide information regarding the BLE specifications as well as their implementation on the CC2650.

BLE support two main data format: one for advertising channels packets and the other for data channels packets. Both formats will be described in details in the first half of the guide. The second half will provide guidance on how to implement the most common roles of a BLE network.

References: BlueTooth Core Specification v4.2, Core Specification Supplement v6, BLE Becons by TI

BLE packet format for advertising channels


Field Size Definition Description
Preamble 1 byte BLE specification Always 10101010b for advertising channel packets
Access Address 4 bytes BLE specification Always 0x8E89BED6 for advertising channel packets
Payload Data Unit (PDU) 2 to 257 bytes User defined Advertising Channel PDU
CRC 3 bytes BLE specification Result of a polynomial calculated based on the PDU

PDU for advertising channels

The RF Core will automatically build the PDU based on the content of the radio operation command. The following table describes the format of the PDU for advertising channels, as well as the corresponding variables in the RIOT command.

typedef struct __attribute__ ((aligned(4))) {
radio_op_command_t ropCmd;
uint8_t channel;
struct {
uint8_t init:7;
uint8_t bOverride:1;
} whitening;
void *pParams; //points toward a structure of type
void *pOutput;
} ble_rop_cmd_t;
Field Size RIOT variable Description
PDU Type 4 bits ropCmd.commandNo PDU Type is solely dependent on the command type. See below.
RFU 2 bits - Reserved for Future Use (RFU): You can't touch this. Assumed to be 0.
TxAdd 1 bit pParams->advConfig.deviceAddrType The field value is specific to the PDU type.
RxAdd 1 bit - The field value is specific to the PDU type. According to the TI documentation (, this field is not available to configure and thus assumed to be 0.
Length 6 bits pParams->advLen + 6 Indicates the length of the payload field in bytes. 6 is added to account for the advertiser address. The payload length ranges from 6 to 37 bytes.
RFU 2 bits - Reserved for Future Use (RFU): You can't touch this. Assumed to be 0
Advertiser address 6 bytes pParams->pDeviceAddress First element of the payload. The different formats of address types are illustrated here.
Advertising data (AD) 0-31 bytes pParams->pAdvData Second element of the payload. Warning: if pParams->advLen=0 the advertiser data are disregarded.

As mentioned in the table above, the content of some of the PDU fields are intertwined. These relationships are established in the following tables. Please note that the configuration of the RxAdd is not possible on the CC2650 (RxAdd=0 ∀ Command No) and thus displayed for information purposes only.

Command No Denomination in BLE specs Value of PDU Type Value of TxAdd and RxAdd Description
CMD_BLE_ADV ADV_IND 0000b TxAdd: advertiser's address is public (0) or random (1). RxAdd: not defined. Connectable undirected advertising event
CMD_BLE_ADV_DIR ADV_DIRECT_IND 0001b TxAdd: advertiser's address is public (0) or random (1). RxAdd: initiator's address is public (0) or random (1). Connectable directed advertising event
CMD_BLE_ADV_NC ADV_NONCONN_IND 0010b TxAdd: advertiser's address is public (0) or random (1). RxAdd: not defined. Non-connectable undirected advertising event
CMD_BLE_ADV_SCAN ADV_SCAN_IND 0110b TxAdd: advertiser's address is public (0) or random (1). RxAdd: not defined. Scannable undirected advertising event

The Advertising Data (AD) field can be populated with a set of basic data types described in chapter 1 of the BLE core specification supplement, e.g. service UUID, flags or manufacturer specific data.

BLE packet format for data channels

Field Size Definition Description
Preamble 1 byte BLE specification Equal to 10101010b (LSB of Access Address is 0) or 01010101b (LSB of Access Address is 1) for data channel.
Access Address 4 bytes BLE specification Randomly generated under constraints.
Payload Data Unit (PDU) 2 to 257 bytes User defined Data Channel PDU
CRC 3 bytes BLE specification Result of a polynomial calculated based on the PDU

Configuring a BLE beacon

In order to configure a BLE beacon, a radio operation command cmd of type ble_rop_cmd_t must be sent to the RF core.

  1. Define the parameters of the command by filling a structure of type rfc_ble_param_advertiser_t. Minimum requirements are as follows:
    1. Set params->endTime = 0 and params->endTrigger.triggerType = 0 unless you want to do something fancy timewise.
    2. Set params->pDeviceAddress to an unsigned char array containing the 48-bit MAC address of the MCU. The MAC-48 identifier can be obtained from the function ble_mac48_get() defined in cpu/cc26x0/periph/cpuid.c. This function returns a public device address, defined in the factory config data (FCFG->MAC_BLE_n): bits 0-24 contain a serial number unique to the MCU, while the bits 24-48 contain the Organizationally Unique Identifier (OUI) for Texas Instrument, i.e. b0:b4:48.
    3. Set params->pAdvData to a byte array containing the data to be broadcasted. The size of the array must be written as params->advLen. Since the advertising packet is non-connectable, the Flag data type (described in Core Specification Supplement v6) may be omitted from the advertising payload.
  2. Configure the command itself by filling a structure of type ble_rop_cmd_t. Minimum requirements are as follows:
    1. Set cmd.ropCmd.commandNo = CMDR_CMDID_BLE_ADV_NC. The PDU type will be set accordingly by the RF core.
    2. Set cmd.condition.rule = R_OP_CONDITION_RULE_NEVER unless you plan on executing an additional command via cmd.pNextOp.
    3. Set cmd.whitening.bOverride = 0 and cmd.whitening.init = 0 unless you understand how to use it.
    4. Set cmd.pParams to the address of the rfc_ble_param_advertiser_t structure defined in 1).
    5. Set the advertising channel via cmd.channel. There are 3 possible channels, each identified by a uint8_t: 37, 38 or 39. If you want to broadcast on all three channels you can create three ble_rop_cmd_t commands and chain them via cmd.pNextOp.
  3. Send the command to be executed to the RF core via the rfc_send_cmd() function


file  board.h
 Board configuration for the CC2650STK.
file  gpio_params.h
 Board specific configuration of direct mapped GPIOs.
file  periph_conf.h
 Peripheral MCU configuration for the CC2650STK board.