This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BLE Getting Started and FAQ [u: 2018 Aug 9]

Welcome to the next generation SimpleLink™ CC26xx and CC13xx ARM® Cortex®-M3 and ARM Corex-M4F based Bluetooth® Low Energy (BLE) microcontrollers (MCUs) from TI supporting Bluetooth version 4.2 and now Bluetooth 5!

New to BLE or want more information about TI's System-on-Chip (SoC) BLE solutions? Please see

This Guide and FAQ post will contain a list of the most common questions regarding the SimpleLink Bluetooth Low Energy ultra-low power enabled CC1352R, CC2642R/CC2652R, CC2640R2F and CC26x0 wireless MCUs, development kits and the BLE-Stack Software Development Kit (SDK). A troubleshooting section is provided below to help address common solutions.

This guide is organized based on the sections listed below:

Getting Started: Selecting a development kit and understanding the BLE protocol
CC2640R2F - Information about the new SimpleLink BLE wireless MCU supporting more available flash memory and Bluetooth 5
Sensor Controller -  Frequently Asked Questions about the Sensor Controller Engine (SCE)
Troubleshooting - Common issues and solution

Getting started

Q: What do I need to get started?

A: You need a development kit depending on the wireless MCU you intend to use. Please select one of the following:

For CC2640R2F designs needing up to 80kB of available flash for Bluetooth 4.2 LE peripheral applications or Bluetooth 5 High Speed support:

1) CC2640R2 LaunchPad™ (LAUNCHXL-CC2640R2). The CC2640R2 LaunchPad supporting Bluetooth 5 is TI's recommended complete production BLE embedded development kit for $29 offering an on board XDS110 debugger, a Bluetooth Low Energy CC2640R2F System on a Chip (SoC) wireless MCU in a 7x7 QFN package and access to GPIOs via the BoosterPack™ expansion connectors. This LaunchPad also supports development for the CC2640R2F-Q1 Automotive qualified BLE wireless MCU. New to LaunchPad? Check out the main site with more LaunchPad ecosystem details. This is the most economical development kit to prototype your embedded Bluetooth Low Energy system, develop software, measure power. The LaunchPad is the primary development kit for embedded BLE applications and is recommended by TI for starting your embedded (single-device) development of Production Bluetooth v4.2 and v5 (High Speed) as well as development of Bluetooth 5 Long Range connections.

For CC1352R and CC26x2R designs with a Cortex-M4F and 200+ kB of flash memory for Bluetooth 5 applications: NEW

1) CC26x2R LaunchPad (LAUNCHXL-CC26x2R1). The CC26x2R LaunchPad for evaluating and developing Bluetooth 5 LE applications for the SimpleLink CC2642R Bluetooth Low Energy wireless MCU and SimpleLink CC2652R Multi-Standard wireless MCU

2) CC1352R LaunchPad (LAUNCHXL-CC1352R1). The CC1352R LaunchPad for evaluating and developing Bluetooth 5 LE applications for the SimpleLink CC1352R Multi-Band wireless MCU

The LAUNCHXL-CC26x2R1 and LAUNCHXL-CC1352R1 LaunchPads feature an onboard XDS110 debugger, EnergyTrace™ measurement technology and a a 32-bit ARM Cortex-M4F processor running at 48 MHz as the main application processor, 352 kB of in-system programmable flash memory, 256kB of device ROM, 80 kB of low-leakage SRAM, a full complement of peripherals such as I2C, SPI and UART, advanced cryptography accelerators (ECC, AES256, SHA256, etc.) as well as a Sensor Controller Engine (SCE).

More information on pre-production availability of these CC1352R and CC26x2R devices and kits can be found in this post.

For CC26x0 designs with up to 40kB of flash memory for Bluetooth 4.2 applications:

1) CC2650 LaunchPad (LAUNCHXL-CC2650). The CC2650 LaunchPad is a complete BLE embedded development kit for $29 offering an on board XDS110 debugger, a multi-standard CC2650 System on a Chip (SoC) in the 7x7 QFN package and access to GPIOs via the BoosterPack connectors. New to LaunchPad? Check out the main site with more LaunchPad ecosystem details. This is the most economical development kit to prototype your embedded Bluetooth Low Energy system, develop software, measure power. The LaunchPad is the primary development kit for embedded BLE applications and is recommended by TI for starting your embedded (single-device) development.

2) CC2650 SensorTag (CC2650STK) + the XDS110 DevPack Debugger (CC-DEVPACK-DEBUG) development kit (bundle TI eStore price $44). This is the best platform for IoT application development as the SensorTag has 10 sensors (motion, temperature, humidity, etc.) and runs off a coin cell battery. See how the SensorTag be used to accelerate your IoT development here.

3) CC2650 Module BoosterPack (BOOSTXL-CC2650MA) development kit featuring the CC2650 Module from TI (CC2650MODA). This BoosterPack is the easiest way to develop wireless network processor BLE applications and prototype in the LaunchPad ecosystem. See the Simple Network Processor SimpleLink Academy module showing how to get started with BLE network processor development on the BoosterPack. Just want to do single-chip BLE development with the module? Although we recommend doing single-device BLE development on the LaunchPad, we've included 10-pin JTAG cable to connect with a supported XDS100v3 or XDS110 debugger (see details below) to program/debug the module BoosterPack. Other 3rd party CC2640 module options are available, see the TI BLE Wiki for details.

4) CC2650 Remote Control (CC2650RC) development kit. With the CC2650RC-BLEDEV BLE development bundle, evaluate TI's Voice over BLE (VoBLE) solution on a form-factor remote control using a PC. More details on the main Remote Control page including a quick start user guide.

Next, you'll need some software. Good news, it's free!

Bluetooth Low Energy Software Development Kit

Download the Bluetooth Low Energy software stack based on the selected device and Bluetooth LE version support:

Device Software Development Kit
Bluetooth LE Version Production / Evaluation


v4.2 , v5.0 (High Speed + AE/Long Range)

Production (v4.2) / Production (v5.0)
CC2642R / CC2652R


v5.0(High Speed + AE/Long Range)



v5.0(High Speed + AE/Long Range)

CC2650/CC2640 BLE-Stack v2.2.2 v4.2 Production

The SDK includes all the components needed develop applications for these devices, including the TI-RTOS, drivers, sample applications and the royalty-free BLE protocol stack. Refer to included release notes for instructions for setting up and building the sample applications in the SDK. These SDKs support project development with Code Composer Studio™ (CCS) and IAR Embedded Workbench for ARM. Refer to the release notes for required IDE and toolchain versions.

Additional example projects & advanced demonstrations can be found on the TI SimpleLink GitHub page

Some kits have dedicated SW examples:

Project Zero

Project Zero is the primary example for the for the Bluetooth Low Energy LaunchPads and demonstrates a custom BLE peripheral device. Develop your first Bluetooth LE application and control the LaunchPad's LEDs, send character strings and monitor button presses with your iOS or Android app with Project Zero. These operations represent some of the most common functions used in BLE devices. Project Zero is available in SimpleLink Academy, a module based learning format that covers topics from getting started to advanced BLE development. See how to send simple strings of data to/from a smart phone and perform tasks over BLE such as for controlling a sensor or developing your own custom service.

  • For CC2640R2F SimpleLink Academy is available at and can be built in CCS Cloud™ as well as supported CCS desktop installations using the Resource Explorer.
  • For CC2x62R and CC1352R, SimpleLink Academy is available in TI Resource Explorer for each SDK: SIMPLELINK-CC26X2-SDK or SIMPLELINK-CC13X2-SDK Expanding the Labs tab shows available Bluetooth 5 training material, including Scanning, Advertising using the 2 Mbps PHY and working with Long Range Connections
  • For CC26x0, Project Zero is included with SimpleLink Academy as an add-on download to the BLE-Stack SDK. This version requires Desktop CCS installation and supports the CC2650 LaunchPad (LAUNCHXL-CC2650) as well as the CC2650 SensorTag + DevPack Debugger. Use of SimpleLink Academy and Project Zero for this platform is via the Resource Explorer Classic in the Desktop CCS installation only. Refer to the detailed setup and installation instructions on the download page.

See the getting started video for Project Zero and SimpleLink Academy

Additional Resources

Develop your own application on any development kit: Start with the simple_peripheral example in the SW Developer's Guide to gain an understanding of Bluetooth LE and the TI BLE SW Stack. TI BLE Wiki. Use the "Sample Applications" section of the BLE Software Developer’s Guide (SWRU393), TI Designs & CC2640 Examples on the TI BLE Wiki to create your Bluetooth Low Energy application!

Q: Where do I learn more about the Bluetooth Low Energy specification, profiles, Notifications, Pairing, etc?

A: 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 optional generation and exchange of security keys, also known as Pairing. Volume 3, Part H. Bluetooth SIG has some good blogs on this topic here.
  • Link Layer Specification - Lowest layer that manages the connection between devices, including encrypting the link when enabled, 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.

Q: How do I develop a Bluetooth 5 (BLE5) application for the CC2640R2F / CC26x2R and CC1352R, including Long Range Connections, High Speed (2 Mbps) and Advertisement Extensions (AE)?

A: First, make sure you download an SDK that contains the TI Bluetooth 5 protocol stack (BLE5-Stack). Each BLE5 enabled SDK contains documentation and sample applications that demonstrate BLE5 features supported by that SDK. Also, to help understand the Bluetooth 5 technology, please be sure to read our Bluetooth® 5 Is Here: Top Five Questions Answered post here in the BLE forum.

Q: How can I add the TI OAD Profile to my Smartphone App?

A: TI provides libraries that simplify adding the TI OAD profile to your smartphone app. The libraries contain functionality to implement the TI BLE profile, as illustrated in the Simplelink Starter Apps (Android)/(iOs).

For iOs, TI provides a cocoapod. It can be automatically installed by adding “ti_oad” to your pod file.

For Android, TI provides an Android Studio module.

Q: Where do I find more information on the CC2650 SensorTag, including sensor details, firmware, services/profiles, PC & Smartphone Apps, etc.?

A: Technical details on the SensorTag, sensors, schematics, BLE custom sensor profiles & how to access from a PC or smartphone can be found on the "Getting Started" & "Teardown" tabs of the SensorTag main page.

The SensorTag device firmware is provided in the TI BLE-Stack SDK, both in source & prebuilt hex format. It can be programmed with the SmartRF Flash Programmer 2 and a supported JTAG debugger.

Additional details on how to build/program the firmware, how to access the sensor data over BLE and more details including OAD are located in the SensorTag User's Guide on the TI BLE Wiki. Although any smart device app can be developed to interact with the SensorTag, TI does provide Android & iOS sample code.

Q: What is the difference between CC2650 & CC2640? How do I move from CC2650 to CC2640 or different package sizes?

A: The multi-standard CC2650 wireless MCU supports BLE as well as other wireless protocols, such as 802.15.4. The CC2640 supports Bluetooth Low Energy only and is recommended for designs that are entirely based on BLE. All code generated from the BLE-Stack v2.x SDK is binary compatible with both the CC2650 & CC2640 in the same QFN package size, so no porting is required when switching from a CC2650 based development kit to a CC2640 based custom board. Additionally, IDE project configuration settings in the BLE-Stack v2.x SDK for CC2650 & CC2640 are cross-compatible; however, it is strongly recommended to not change the CPU settings in the IDE. Although the CC2650 has the HW & ROM capability to support additional wireless protocols, a given SW build can only support one wireless protocol. Development kits that feature the multi-standard CC2650 wireless MCU are suitable for development of CC2640 based custom board designs. To develop with the CC2640R2F, the CC2640R2 LaunchPad is required, see kit description above.

The SW programming interface is the same for all package options. When changing from one package option to another, such as the 7x7 to the 4x4 QFN, only the number of DIOs defined in the board file and, if needed, RF layout need to be considered.

For a detailed overview of the new CC2640R2F, please see the dedicated section below. TI recommends that all new BLE designs use the CC2640R2F for increased application flash memory availability.

Q: Do you support Bluetooth Mesh Networks?

In July 2017 Bluetooth SIG released the first mesh network specification for Low Energy devices. This implementation uses a "flooding" approach to relay payloads of data (messages) across the mesh network. It is important to note that the mesh specification is external to the Bluetooth core specification and not part of the Bluetooth 5 or any previous Bluetooth 4 specification. More details on Bluetooth mesh can be found on the SIG website: TI intends to support mesh networking in a future SDK offering.

Q: Do you have a GitHub page?

A: Yes! Additional example projects demonstrating the advanced BLE capabilities of the CC2640 / CC2640R2F, such as achieving maximum data throughput over BLE and Multi-Role - up to 8 simultaneous connections depending on configuration, can be found on the TI SimpleLink GitHub page. Refer to the 'ble_examples' repo for instructions on accessing examples associated with previous BLE Stack SDK releases.


Q: Which debuggers are supported?


  • XDS100v3 standalone (from 3rd party manufacturers)
  • XDS110 on supported LaunchPads, such as the CC2650 (LAUNCHXL-CC2650) & MSP432 (MSP-EXP432P401R) Red Edition LaunchPads. Other LaunchPads may feature a XDS110 with an exposed 10-pin JTAG connector for debugging external targets. Refer to the documentation of your LaunchPad. The XDS110 supports cJTAG 2-wire configurations
  • XDS200 (from 3rd part manufacturers)
  • SmartRF06EB using XDS100v3 (included on board)
  • DevPack Debugger (CC-DEVPACK-DEBUG) for the new SensorTag (see description below on usage with custom boards)

See the Tools wiki for more details on supported debuggers including compatible 3rd party ARM flash programmers suitable for mass production / factory environments. Note that XDS100v2 debuggers are not supported with CC26xx.

Q: Can I use the DevPack Debugger (CC-DEVPACK-DEBUG) to program / debug my custom CC26xx / CC13xx board?

A: Although the DevPack Debugger uses the same XDS110 JTAG debugger found on the CC2650 and CC2640R2F LaunchPads, the DevPack Debugger is designed to only work with the SensorTag (CC2650STK) evaluation kit. As opposed to the XDS110 on the LaunchPad, the DevPack Debugger is not designed to be used as a standalone debugger to custom boards since it has no level shifters, no vsense pin, etc. TI recommends using a supported standalone debugger listed above or the CC2650 or CC2640R2F LaunchPad's "XDS110 out" header along with a standard 10-pin ARM JTAG cable to program and debug custom boards. The procedure for using the LaunchPad as an external debugger to custom boards is described in the application note "Running Standalone BLE Applications on CC2650 Module" (SWRA534).

Q: How do I program firmware to the CC13xx/CC26xx device?

A: All development kits come pre-programmed with demonstration firmware, however, CC26xx devices purchased individually (e.g., on reels) have their internal memory contents blank / erased. These devices, including the CC2650MODA module, can be programmed using a supported JTAG programmer (see Debuggers section above) or via the CC26xx ROM serial bootloader. Refer to the Bootloader chapter of the CC26xx TRM (SWCU117) as well as application note SWRA466 for more details on how to use the ROM bootloader to program the CC26xx.

Q: Does each CC13xx / CC26xx BLE wireless MCU have a unique Bluetooth Device Address (BDADDR)?

A: Yes, all BLE wireless MCUs from TI come pre-programmed with a unique 48-bit IEEE BDADDR to the device's Factory Configuration area (FCFG). During production, TI provisions the device with a BDADDR generated from one of the TI-assigned 24-bit IEEE OUI blocks. A list of OUIs can be found on the IEEE site here. Please note that even within the same device lot, BDADDRs are only guaranteed to be unique and may not be successive or from the same Texas Instruments OUI block. The IEEE BDADDR is used as the device's public Bluetooth address unless a secondary address has been programmed to the Customer Configuration area (CCFG) or the application has specified an alternate address via a Vendor Specific HCI command. The device's BDADDR can be read using a JTAG programming tool, such as Flash Programmer 2 or Uniflash or from software by calling the HCI_ReadBDADDRCmd API.

Q: How do I implement power management in my application to achieve the lowest power consumption?

All standalone or embedded example applications in the SDK are configured by default to enter the standby (or "sleep") state when no application or radio activity is occurring. This configuration is controlled by the POWER_SAVING pre-processor define in the application project. This define configures the TI Power Driver to automatically control the device power state in response to RTOS and radio states/events such that the lowest power state is always achieved. For example, with POWER_SAVING defined, the MCU will enter standby in between advertisement or connection events, or when the idle task is running. No runtime application control is required to manage the power state. Network processor applications require additional signalling pins to be used for controlling the device wake up and standby states. If these pins are not available, the application must be built with POWER_SAVING removed/undefined. For more information on this topic, refer to the application note Measuring Bluetooth Low Energy Power Consumption (SWRA478) and the Power Management user's guide in the SDK (SPRUI18).

Q: Can I use the CC Debugger with CC26XX?

A: Unfortunately not. The CC26XX / CC13XX series uses cJTAG or 4-pin JTAG as its debug interface which is not supported by CC Debugger.


Q: Which IDE / Compilers are supported?

A: Refer to the release notes in the actual SDK for the required toolchain & IDE version. Generally, IAR >=7.70.2 or CCS 6.2.0 (Build 50 or later) is supported (updates applied). Both have equally good support for TI RTOS. Please see the "Setting up the Development Environment" section of the BLE Software User’s Guide located in the SDK. The actual IDE versions used for testing the BLE-Stack SDK can be found in the Release Notes of the SDK. Using a tool chain / IDE version lower than the specified version in the SDK release notes is not compatible.

Note: IAR 7.50 versions prior to 7.50.3 have linker issues with BLE-Stack 2.1.x. Please use IAR 7.50.3 or later. Opening a project with specific version of IAR will not allow that project to be opened with previous versions of IAR.

The BLE-Stack v 2.2.2 SDK release has been built and tested with TI ARM Compiler v16.9.4.LTS. Compatibility with other TI ARM Compiler versions in CCS has not been tested and use of other compiler versions may result in undefined behavior. Refer to Section of the BLE Software Developer’s Guide (SWRU393C) or the online SW User's Guide section for Installing a TI Compiler for the procedure to install  a specific TI ARM Compiler that is not bundled with CCS.

IAR has changed the definition of the wchar_t in EWARM 8.11.x IDE versions which results in warnings with BLE SDKs that have specified dependencies to IAR EWARM 7.80.3 and earlier versions. TI has not tested these SDKs for compatibility to 8.11.x EWARM and recommends using the toolchain version listed in the SDK release notes. IAR versions used by TI BLE SDKs can be found here.

Q: Can I use CCS 7.x with TI BLE-Stack v2.2.x?

A: Although testing was performed at the time of release with CCS v7.4, TI has not identified any incompatibility with CCS v8. Please be sure to install the TI ARM Compiler as specified in the SDK release notes by following the procedure described above and in the online SW Developer's Guide section Installing a Specific TI ARM Compiler.


Q: Do you have an BLE-Stack SDK installer for Linux or Mac?

A: The BLE-Stack SDK installer for CC2640/CC2650 is for Windows® 7 and later Windows PC host systems. Some community users have provided and shared their tips for installing on non-windows systems. See this thread for tips on installing on Linux systems. Starting with BLE-Stack v2.2, the python source for the lib_search.exe and frontier.exe tools are provided in the SDK 'tools' folder. This source should help with running these tools on non-Windows host systems.

As of SimpleLink SDK 2.20 for the CC2640R2F, CC2642R, CC2652R and CC1352R devices, host machine build support is enabled on supported Windows, Linux and macOS platforms. Refer to the the respective device SDK release notes for platform-specific build dependencies.


Q: When I download my code, where is it programmed? Internal or external flash memory?

A: The CC13xx/CC26xx is a flash based wireless MCU with 128kB or 352kB of in-system programmable flash memory. All code downloaded / programmed by a supported IDE or SmartRF Flash Programmer 2 (CC26x0 only) or the Uniflash Standalone Flash Programmer (all CC13xx/CC26xx devices) resides in and executes from internal flash memory. Some development kits feature an optional serial flash memory component connected via SPI. This external flash is to support firmware upgrade using TI's custom Over-the-Air Download (OAD) profile, which, when used with a software boot image manager, allows for updating the internal memory contents. It is not possible to execute firmware from external memory devices. For more details on the OAD profile, please see the CC2640 BLE OAD User's Guide article on the TI BLE Wiki. Please note that the MCU cannot directly execute code from external memory.


Q: How do I migrate my CC254x application to CC26xx

A: Most reference projects in the CC254x SDK have been ported to CC2640. Please refer to CC2640 BLE SW Developer’s Guide porting section for additional information on porting. Although most of the BLE-Stack APIs have remained the same, the amount of porting effort required will vary depending on the complexity of the existing application.

Q: How do I port my CC26xx CCS or IAR BLE project to the latest BLE-Stack SDK?

A: A v2.x project porting guide is available on the BLE Wiki. For CC2640R2F and CC26x2R/CC1352R based projects, the migration and porting guide is included in the SDK.

Q: How do I add UART or SPI to my application

A: Multiple options are available for adding serial communication to your Bluetooth Low Energy application. Refer to the TI BLE Wiki article: "CC2640 Serial Communication".

Q: How do I implement Device Firmware Upgrade (DFU) or Over the Air Download (OAD) firmware upgrade for CC2640 / CC2640R2F?

A: Upgrading the firmware over a BLE wireless connection is achieved by using TI's custom OAD ( a/k/a  DFU ) service, PC tools and external serial flash memory. For more details on how to implement the OAD on CC2640, please see the CC2640 BLE OAD User's Guide article on the TI BLE Wiki. Currently, OAD to internal flash is supported with limitations on the size of the Application, refer to the OAD guide for more details. The CC2650 LaunchPad features external flash memory and is used for the example.

For CC2640R2F, the OAD Guide can be found in the SW Developer's Guide. CC2640R2F with BLE-Stack v3.x can support both on-chip (internal) and off-chip (external) OAD options. Starting with CC2640R2 SDK v1.40 BLE-Stack v3.1.0, the OAD profile has been enhanced to allow for faster downloads as well as on-chip stack upgrades. Refer to the guide for a detailed description of benefits and associated limitations.

For non-wireless DFU or applications that use a host MCU, the CC2640 firmware can be upgraded over a UART or SPI interface using the ROM Serial Bootloader. Refer to the CC26xx TRM (SWCU117), Bootloader Chapter, for more details.

Q: How do I do a simultaneous Master & Slave (i.e., Peripheral & Central role) connection?

A: Please see the multi-role example application on the SimpleLink GitHub page under the 'ble_examples' repo. With the multi-role sample application multiple, simultaneous connections can be established in any GAP role (Central or Peripheral). For the CC2640R2, CC13x2 and CC26x2 SDKs, the multi-role sample application is included in the SDK.

Q: How do I enable more functionality with the Invensense MPU-9250 motion sensor on the CC2650 SensorTag?

A: TI provides a reference implementation, along with source code, for enabling the control and export of data from the MPU9250 motion sensor in the SensorTag sample application within the BLE-Stack v2.2.x SDK. Since the motion sensor is not manufactured by TI, we are therefore unable to provide additional support through our E2E forums for modification of the reference implementation. Developers who want to enable additional functionality or features are encouraged to review the MPU9250 data sheet and connect with Invensense for additional support. Refer to the SensorTag online user guide for the related source code files.

Q: Where can I find the original Out of Box demo for the CC2650DK?

A: The hex file for the PER Test demo can be found in this post. A standalone source PER project is also available in the TI-RTOS 2.21 SDK
and the TI Resource Explorer. 

Q: Are newer TI-RTOS releases compatible with an existing BLE-Stack SDK?

A: A particular TI BLE-Stack release is tested with the TI-RTOS release packaged with the BLE-Stack SDK installer as described in the release notes. Occasionally, TI may provide a porting guide to a newer TI-RTOS release for specific functionality enhancements (e.g., to use an updated driver), however, compatibly can only be assured for the TI-RTOS version listed in the release notes of the TI BLE-Stack. Therefore, use of a different TI-RTOS release should be considered experimental even when a porting guide is available. See the Porting Guide on the TI BLE Wiki for details on the latest TI-RTOS support.

Due to the tight integration of the coreSDK in the SimpleLink SDK, it is not possible to use different coreSDK components in another SDK.

Q: Can I use drivers that come with a newer CC26x0 TI-RTOS SDK ( >=TI-RTOS 2.20)?

A: Yes, you can back port the drivers from newer TI-RTOS version to the one that is used together with BLE stack 2.2. We have created a porting guide for your convenience.



The CC2640R2F and CC2640R2F-Q1 are TI's first generation Bluetooth 5 wireless MCUs supporting configurations for higher throughput and longer range as well as providing more flash memory for application development in Bluetooth 4.2 configurations. Software development for CC2640R2F is enabled today by the SIMPLELINK-CC2640R2-SDK supporting Bluetooth 5 LE. The CC2640R2F-Q1 is AEC-Q100 certified for Automotive Applications and has all features and software support as the CC2640R2F in a 7x7 QFN package .

Q: What is the difference between the CC2640R2F and existing SimpleLink CC2640/CC2650/CC1350 wireless MCUs that support BLE?

A: In addition to support for the new Bluetooth 5 Low Energy PHY features, CC2640R2F has an updated non-volatile (NV) memory map layout with the latest Bluetooth 4.2 LE Host and Controller protocol stack placed in ROM. These updates move protocol stack code that resided in flash on previous CC26xx wireless MCUs to ROM, thus allowing for larger customer application use of the flash memory. With CC2640R2F, up to 80kB of additional free flash is available for Bluetooth 4.2 peripheral applications. Aside from these changes, most system & performance specifications remain the same as the CC2640/CC2650 wireless MCUs, including the Cortex-M3 application CPU, size of RAM, RF Core and Sensor Controller Engine interfaces.

Q: Is the CC2640R2F compatible with existing CC2640/CC2650 wireless MCUs?

A: The CC2640R2F is pin-for-pin compatible with equivalent CC2650/CC2640 QFN packages and reference designs. This means you can drop-in a CC2640R2F to an existing board layout that currently uses a CC2640 or CC2650 in the same QFN package size. In addition, the CC240R2F can be substituted in existing CC26xx BLE reference designs. Aside from updates to the NV memory layout which enable larger customer applications, most device specifications remain the same as the CC2640/CC2650. Refer to the CC2640R2F data sheet for details. Note that CC2640R2F supports Bluetooth Low Energy (BLE) only.

Q: Is my CC2640/CC2650 BLE firmware application compatible with CC2640R2F?

A: In general, the BLE-Stack v2 APIs and application framework are mostly the same, including GAP/GATT and TI-RTOS interfaces. However, due to updates to the NV memory map layout, you cannot use the same binary firmware image between CC2640/CC2650 and CC2640R2F wireless MCUs. A migration guide is available in the CC2640R2 SDK with instructions to port your existing BLE-Stack v2.2 application to CC2640R2F.

Q: How do I develop my CC2640R2F application to use Bluetooth 5?

A: TI has now updated SIMPLELINK-CC2640R2-SDK v2.30.00.28 with a Bluetooth 5 production certified stack component (ble5stack) supporting the new BLE 5 2Mbps High Speed, LE Coded PHY (Long Range) and Advertisement Extensions (AE) features. The included simple_peripheral and simple_central example applications have been updated with sample code for utilizing these features.

In many cases, updating an existing BLE application to take advantage of the new Bluetooth 5 features requires minimal application changes since they are automatically managed by the TI BLE protocol stack. We've created a separate Bluetooth 5 post describing how to take advantage of the features using the new Bluetooth 5 protocol stack ( BLE5-Stack ).

Q: What is the difference between the BLE-Stack v3.x and BLE5-Stack v1.x protocol stack?

A:Many devices today still use features from Bluetooth 4.0 - 4.2 so TI has included our memory-optimized Bluetooth 4.2 protocol stack (BLE-Stack) in the SIMPLELINK-CC2640R2-SDK. This protocol stack supports all Bluetooth 4.x devices and is memory-optimized to provide up to 80 kB of flash memory for the application. To take advantage of the cutting-edge performance of Bluetooth 5, TI has added a new protocol stack, BLE5-Stack, which includes all existing features from Bluetooth 4.x as well as added support for Bluetooth 5 High Speed, Long Range and Advertisement Extension modes.

Q: What is the difference between the CC2640R2 SDK and BLE-Stack SDK?

A: The CC2640R2 SDK uses TI’s new SDK layout which is common for SimpleLink MCUs. This SDK format adds value to customers who are developing on SimpleLink MCUs by using a consistent directory and naming convention, installation procedure and core RTOS interface. The BLE-Stack v3.0.1 is now incorporated as a component in the CC2640R2 SDK. All functionality previously provided by the BLE-Stack SDK, including the TI-RTOS, is now incorporated in the CC2640R2 SDK. The CC2640R2 SDK can also be accessed via the TI Resource Explorer at

Q: Does the CC2640R2F SDK support CC2640/CC2650/CC1350 wireless MCUs?

A: No, only the CC2640R2F device is supported with the CC2640R2 SDK. For BLE-Stack support on other Bluetooth Low Energy enabled SimpleLink wireless MCU, please use the BLE-Stack v2.2.x SDK.

Q: Do I need to requalify or re-certify my product if I change to CC2640R2F?

A: The CC2640R2F has no changes to the frequency determining circuitry relative to the CC2640/CC2650 devices. As such, it will have the same RF PHY performance as the CC2640/CC2650. TI recommends contacting a certified test lab for all questions and topics related to regulatory compliance, including how to upgrade an existing, certified, design to CC2640R2F.

For Bluetooth SIG qualification, the same Bluetooth 4.2 protocol stack qualified design ID (QDID) is used on all SimpleLink CC26xx & CC13xx BLE devices. Note that changing the protocol stack configuration used by your application (e.g., going from BT 4.1 to 4.2) or any board layout changes may necessitate a requalification and/or regulatory re-certification. Please check with Bluetooth SIG’s website for qualification requirements. Additional qualification details can be found on the TI BLE Wiki under “Test & Certification”.

TI has created an app note Hardware Migration From CC2640F128 to CC2640R2F (SWRA535) which can be referenced for additional hardware-related details when transitioning from CC2640 to CC2640R2F.

Q: What development kits are available for the CC2640R2F?

A: The CC2640R2 Bluetooth Low Energy LaunchPad (LAUNCHXL-CC2640R2) is available from the TI eStore. The CC2640R2 LaunchPad is a complete, low-cost BLE development and prototyping kit featuring an XDS110 JTAG debugger/programmer, onboard serial flash for firmware updates, expansion with BooserPack™ accessories, LEDs and accesses to IOs. The CC2640R2 LaunchPad uses a 7x7 QFN package with 31 IOs.

Q: What development environments are supported for developing BLE applications?

A: The CC2640R2 SDK supports IAR Embedded Workbench for ARM and Code Composer Studio v7. Refer to the release notes in the CC2640R2F SDK for the required toolchain and IDE version.

Q: Will the SensorTag be updated with the CC2640R2F?

A: TI has not announced any plans to release a SensorTag with CC2640R2F. The CC2650 SensorTag (CC2650STK) can still be used for IoT application prototyping as well as multi-standard (e.g., ZigBee) development. For sensor based application development, the Sensor BoosterPack™ can be used with the CC2640R2 LaunchPad. We have created a SimpleLInk Academy module demonstrating how to easily add an I2C sensor to your CC2640R2F BLE application using the Sensor BoosterPack.

Q: Will a CC2640R2F module be available?

A: TI has not announced any plans for a CC2640R2F based module, although a list of 3rd party module manufacturers can be found here. In many cases the module manufactuer offers regulatory (e.g., FCC, ETSI) and Bluetooth RF-PHY pre-certifications which can substantially reduce the time, effort and cost needed to certify an end product. Customers wishing to do their own "chip down" designs can utilize all existing CC26xx reference designs for board layouts incorporating the CC2640R2F in a QFN package.

Q: Will CC2640/CC2650 still be available and supported?

A: Just as with the first generation CC254x BLE MCUs, TI has not announced any plans to discontinue the CC2640/CC2650 wireless MCUs. Product support will continue to be offered through E2E. Customers who want upgradability to Bluetooth 5 or need additional flash memory for their applications are encouraged to start new designs with CC2640R2F.


Q: When switching sample applications on my board or LaunchPad, my iOS or Android device is not able to "see" new Characteristics or Services

A: This condition occurs since the smart device caches GATT attribute handles in order to speed up the re-connection process. For example, when reprogramming the device with Project Zero after it was previously running SimplePeripheral will show the "old" Simple GATT Profile characteristics in a BLE app such as Light Blue or BLE Scanner. To force the phone to re-discover the attributes the phone's BT GATT cache must be cleared.  If the device was previously paired/bonded, tap the device name in the Bluetooth settings menu and select Forget this Device or Unpair depending on your phone OS version. Next, complete the following procedure based on iOS or Android:
In iOS 10 and earlier, toggle Aeroplane mode ON then OFF in the Settings or Control Center menu (this also switches the Bluetooth radio off then on). For iOS 11 and later, you must toggle Bluetooth OFF then ON from the Settings > Bluetooth menu due to changes on how the Bluetooth radio is manged in these iOS versions
On Android, the procedure can vary by make and model, but most recent versions can choose Settings > Apps > Scroll over to All > Choose Bluetooth Share and tap on Clear Cache. Just as with iOS, un-pair the device if it was previously bonded.

Q: My Project Zero builds and flashes ok but does not Advertise and/or encounters a CPU abort

A: Please make sure you are using the correct CCS Development environment. For the latest Project Zero example using BLE-Stack v2.2.2, this is CCS v7.4 with TI Compiler v16.9.4.LTS. Please see the BLE-Stack release notes and  "Setting up the Development Environment" section of the CC26x0 BLE Software Developer’s Guide (SWRU393) located in the Documents folder of the BLE-Stack SDK. Use of non-recommended compilers may result in increased task stack utilization which can cause undefined behaviour.

Q: Why am seeing poor RF performance and range issues on my custom CC26xx board when everything works fine on the TI Reference HW?

A: When the TI reference design guidelines ( are followed, the most common reason for poor RF performance or range issues is an incorrect/mismatched RF Front End & Bias setting in SW vs. the actual front-end configuration on the custom HW. This mismatch usually happens when the custom board uses a different package (i.e, 5x5) and includes one of the TI CC2650EM eval module board files which does not match the custom board's front-end configuration. To achieve maximum RF performance, it is critical to have the correct SW setting that matches the actual board layout.

For example, the CC2650EM_5XD board file is for a 5x5 package using a Differential front-end configuration with eXternal bias. If the custom board uses a layout with Internal bias, using the 5XD board file will will result in a mismatched Bias setting and thus severely degrade RX sensitivity. The same principle applies for mismatched Single-ended vs Differential front-end configurations.

Make sure the board file is updated with the correct front-end configuration settings. The setting is defined by RF_FE_MODE_AND_BIAS in bleUserConfig.h. See this header file for the available SW definitions. It is recommended to confirm that the preprocessor is including the correct board file and RF_FE_MODE_AND_BIAS setting. If needed, create a new board file with the correct RF setting. See "10 Creating a Custom BLE Application" in the CC2640 BLE Software Developer’s Guide (SWRU393) for more details.

For more CC26xx HW troubleshooting, refer to the following wiki:


Q: Why is my device in an infinite loop with "No source available for 0x1001bbd6" (CPU abort)

A: This means you have encountered a CPU abort / exception, such as from accessing a non-existent memory address, side effect of a stack overflow, etc. For debugging this condition, i.e., finding what caused the CPU abort, see the "Deciphering CPU Exceptions" section in Ch 9 of the CC2640 BLE SW Developer’s Guide (SWRU393). This can also happen when trying to access an IO pin from your application that is not available on your device, such as from porting your application from a LaunchPad that uses a 7x7. For example, trying to access IO's higher than IOID_14 on a 5x5 QFN device will result in an hardware abort since this pin is only available on 7x7 QFN package devices.

Q: How do I enable the TI-RTOS Object Viewer (ROV) in IAR?

A: The ROV can be enabled under the application's Project Options -> Debugger -> Plugins tab. Select "TI-RTOS" in the scroll list.

Q: Why does my CC2650STK SensorTag only work when I debug in CCS?

A: The SensorTag requires the use of a Boot Image Manager (BIM) which needs to be programmed in addition to the App & Stack projects. The BIM is included in the prebuilt firmware hex image. Refer to the Firmware Build Procedure in the SensorTag User Guide on the TI BLE Wiki.

Q: My "out-of-the-box" BLE examples does not compile in IAR and I get an error saying "Variable expansion failed". What is wrong?

A: IAR sometimes fail to include the path variables for TI RTOS and CC26XXWARE and you need to import them again manually. 

Goto Project->Configure Custom Argument Variables, Select Import and choose the corresponding variables file. Example location: Projects\ble\SimpleBLEPeripheral\CC26xx\IAR\SimpleBlePeripheral.custom_argvars

Q: I encounter a pre-build error indicating that lib_search.exe is not recognized in BLE-Stack v3.0 / CC2640R2 SDK v1.0.0.22

A: The lib_search.exe executable used during the Stack pre-build steap in this SDK requires a Windows 64-bit installation. For 32-bit Windows installations, please use this 32-bit version of lib_search.exe (zip). Starting with CC2640R2 SDK v1.30.00.25 a 32-bit compatible version is provided.

Q: My CC-DEVPACK-DEBUGGER (DevPack Debugger / XDS110) does not detect the SensorTag in SmartRF Flash Programmer 2 v1.7.x+?

A: A firmware update may be required. Please install CCS according to the CC2640 BLE Software Developer’s Guide (SWRU393). CCS will detect if a firmware update is required when a Debug session is started. Open and build the SensorTag project, then program the SensorTag via the CCS Debugger. Remember to close SmartRF Flash Programmer 2.

Q: I’m getting a linker or post-build error with Boundary.exe when building the Stack project.

A: (Applies to BLE-Stack v2.1.1 and earlier SDK releases) The Boundary tool is used to adjust the Stack flash / RAM boundary to the optimal value. These errors typically occur when the Stack configuration is modified such that RAM/Flash usage has changed.

  1. Verify that your argument variables / path point to the location where Boundary.exe is installed. The default location: C:\Program Files (x86)\Texas Instruments\Boundary. If the tool is installed to a different path, the IDE will need to be updated:
    1. IAR: Tools-> Configure Custom Argument Variables ->”CC26xx TI-RTOS” -> BOUNDARY
    2. CCS: Stack Project Properties -> Build, “Steps” tab, “Post-build steps”.
    3. Refer to Section “3.12 Configuration of RAM & Flash boundary using the Boundary Tool” in the CC2640 BLE Software Developer’s Guide (SWRU393) for details on how to resolve build errors generated by the Boundary tool or Linker.

      For BLE-Stack v2.2.0+: the Frontier tool is used and a rebuild of the Stack project is not required. Details are provided in the CC2640 BLE Software Developer’s Guide, but the process is to build the Stack, then build the App. A rebuild of the Stack is only required if changing the Stack project.

Q: I get pre-build errors in IAR, and after clicking Tools->Options->Messages->Show all build messages, it looks something like this
gmake[1]: Entering directory `C:/ti/simplelink/ble_cc26xx_2_00_00_42893/Projects/ble/SimpleBLEPeripheral/CC26xx/IAR/Config/src/sysbios'
Preprocessing library source files ...
C:/Users/<user>/AppData/Local/Temp/ 1: Syntax error: "(" unexpected
C:/Users/<user>/AppData/Local/Temp/ 1: Syntax error: "(" unexpected

A: Your system has for whatever reason disabled 8.3 pathname aliases (e.g. PROGRA~2) for the path IAR is installed to. The only known working solution is currently to install IAR at e.g. C:\IAR\EWARM7401 or some other path without spaces or long names.

Q: I get "Resource temporarily unavailable" pre-build errors in the application project similar to this:

Creating the SYS/BIOS library that contains the APIs not included in the ROM ...
0 [main] sh 6420 sync_with_child: child 6332(0x19C) died before initialization with status code 0xC0000142
23 [main] sh 6420 sync_with_child: *** child state waiting for longjmp
C:/Users/username/AppData/Local/Temp/ fork: Resource temporarily unavailable

A: Most likely there is a conflict with sh.exe in the XDCTools installation with some other package you have installed. Please search for sh.exe in your system and disable the conflicting package(s). Additionally, file system tools, such as cygwin may cause conflicts with the XDCTools; these installation(s) should be disabled as well.

Q: When switching to the 5x5 package, UART crashes in my BLE-Stack v2.1.x project, such as when initializing NPI.

A: An issue exists in the TI-RTOS 2.13 CC2650EM_5XD board file with the placement of the uartCC26XXHWAttrs structure. Please make the following change in the 5XD board file, usually located at C:\ti\tirtos_simplelink_2_13_00_06\packages\ti\boards\SRF06EB\CC2650EM_5XD:

#pragma DATA_SECTION(uartCC26XXObjects, ".const:uartCC26XXObjects")
#pragma DATA_SECTION(uartCC26XXHWAttrs, ".const:uartCC26XXHWAttrs")

This issue has been corrected in subsequent TI-RTOS SDK releases for CC26xx and is fully fixed in the BLE-Stack v2.2 SDK.

Q: My CCS project fails to build.

A: First verify you are using the required minimum CCS IDE version and TI Compiler version specified in the Release Notes for the respective SDK. Also, do not use a space in the BLE-Stack SDK path and your CCS workspace or Windows %APPDATA% path. Using a white space in these paths will result in a build error. It is also advisable to install the SDK to the default location to confirm your setup is working correctly. In addition, the pre-build steps may fail if there is a version of Cygwin in your Windows PATH before XDCTools. It is recommended to adjust your PATH such that no other versions of Cygwin are found before XDCTools.

Q: I’m still getting build errors of some kind.

A: Please use the E2E "Insert Code, Attach Files and more" option and attach your IAR or CCS build log (paperclip icon). Note that for IAR, you must enable the build log: Tools -> Options -> Messages -> Log build messages to file. Please compress the file as needed. Attaching the build file, and not just the snippet showing the error, is critical to determine the build environment and other factors needed to diagnose your build error.

Q: When debugging or loading the Stack FlashROM project, I get errors saying the vector table can’t be found or can’t run to main.

A: The Stack project is not an executable, thus it can’t be debugged directly from the IDE. The Stack must be debugged from the Application project workspace. In IAR, you should not encounter these warnings if “Download Active Application” is used to download (program) the Stack image. In CCS, you will see these warnings, however they can be ignored so long as the flash memory was successfully programmed. After the Stack is downloaded, switch to the Application workspace/project and start the debug session. More details are in the CC2640 BLE Software Developer’s Guide (SWRU393).

Q: My CC-DEVPACK-DEBUG (DevPack Debugger / XDS110) always reports "Firmware Upgrade Mode" in the Windows Device Manager?

A: Please make sure you have a battery inserted in the SensorTag and follow the procedure on the wiki:

Q: How do I unbrick the device?

A: Use SmartRF Flash Programmer 2. Under the wrench icon (top right), select “CC26xx/CC13xx Forced Mass Erase”. Note that the flash programming tool will always report "success" when performing a mass erase. If the CC26xx Device Configuration (CCFG) has been set to disable the Mass Erase function, the operation will not succeed despite the flash programming tool reporting "success".

Q: I am using simplelink_cc2640r2_sdk_1_00_00_22 TI-RTOS driver examples, but the out of box project gives the following error msg("..\CC2640R2_LAUNCHXL.h", line 54: fatal error #1965: cannot open source file "ti/devices/cc26x0/driverlib/ioc.h"). What should I do? 

A: Change #include <ti/devices/cc26x0/driverlib/ioc.h>  to <ti/devices/cc26x0r2/driverlib/ioc.h> in CC2640R2_LAUNCHXL.h which can be found in C:\ti\simplelink_cc2640r2_sdk_1_00_00_22\source\ti\boards\CC2640R2_LAUNCHXL and re-import the project. 

The default CC26XXWARE path to setup files / drivers is set to support release material (Rev2.2). To run the software on older material this variable needs to be changed.


  • Goto Tools->Configure Customer Argument Variables-->CC26xx TI-RTOS-->CC26XXWARE


  • From: C:\ti\tirtos_simplelink_2_11_01_09\products\cc26xxware_2_20_06_14829
  • To  C:\ti\tirtos_simplelink_2_11_01_09\products\cc26xxware_2_00_06_14829

  • Delete OS kernel libraries folder: IAR\Application\CC2640\configPkg [IAR builds only]
  • Delete OS kernel source build folder: IAR\Config\src [IAR builds only]
  • Close workspace and re-open for changes to take effect


  • Right-click the Application project, Select Properties
  • Goto Resource->Linked Resources, "Path Variables" tab
  • Follow the above instructions to modify CC26XXWARE
  • Goto Build->ARM compiler->Advanced Options->Predefined symbols
    Look for CC2650F128RGZ and replace it with CC2650F128RGZ_R21 or CC2650F128RGZ_R20.
  • Rebuild the Application project

Q: When I enable CACHE_AS_RAM feature, my project compiles ok but it does not run. What happen?

A: Open memory browser to the location of rfRegTbl. If you see that the rfRegTbl start address is not 4.byte aligned, thus the whole rfRegTbl is skewed. The radio core (M0) needs all addresses to be 4-byte aligned or else the RF Core will crash. To fix this, add "  #pragma DATA_ALIGN(rfRegTbl, 4)" in front of the rf override table which can be found in ble_user_config.c.

Code example: 

#elif defined( CC26XX_R2 )
  #pragma DATA_ALIGN(rfRegTbl, 4)
  regOverride_t rfRegTbl[] = {
    HW_REG_OVERRIDE(0x6084, 0x05F8), // RFC_RFE:SPARE0. Select R1-style gain table
    0x04280243,  //10 us added to the RF SYNTH calibration
    0x00FF8A43,  // set advLenMask to 0xFF to avoid ROM patch
#endif //CACHE_AS_RAM
    0xFFFFFFFF };

Q: In simplelink_cc2640r2_sdk_1_50_00_58, when I added CC2640R2DK_5XD in predefined symbol, the project won't compile.How do I fix this?

A: You can copy cc2650em folder from simplelink_cc2640r2_sdk_1_40_00_45 -->source -->ti -->blestack -->target to the corresponding structure in the simplelink_cc2640r2_sdk_1_50_00_58.

Q: In simplelink_cc2640r2_sdk_2_20_00_49, when I use CC2640R2DK_5XD /CC2640R2DK_4XS in predefined symbol, the project won't compile.How do I fix this? [NEW Aug 8]

A: The board files for 5XD/4XS did not get updated accordingly unfortunately and will be fixed for the next release. This can be fixed by replacing the RFCC26XX_hwAttrs section in simplelink_cc2640r2_sdk_2_20_00_49\source\ti\blestack\boards\CC2640R2DK_4XS(5XD)\CC2640R2DK_4XS(5XD).c with the following code.

const RFCC26XX_HWAttrsV2 RFCC26XX_hwAttrs = {
    .hwiPriority        = ~0,       /* Lowest HWI priority */
    .swiPriority        = 0,        /* Lowest SWI priority */
    .xoscHfAlwaysNeeded = true,     /* Keep XOSC dependency while in stanby */
    .globalCallback     = NULL,     /* No board specific callback */
    .globalEventMask    = 0         /* No events subscribed to */

Q: I can't find BDS anymore, what happened?  [NEW Aug 9]

A: Bluetooth SIG decided to discontinue the BDS, therefore you can't find BDS(also SLA BDS training section) anymore.

— Sensor Controller Engine FAQ —

What is the Sensor Controller and what is Sensor Controller Studio (SCS)?

The Sensor Controller is the terminology used to describe the sensor module in the CC26xx and CC13xx family of devices. This is in a separate power domain (AUX_PD) which contains a dedicated low power 16-bits processor, 2 KB RAM, Peripherals (ADC, Comparator, timers, TDC, etc). This module is designed for ultra low power and high flexibility. The sensor controller has the ability to do its own power and clock management of AUX_PD, independently of the MCU domain. Sensor Controller Studio (SCS) is a GUI tool used to write, test and debug code for the CC26xx/CC13xx Sensor Controller. This GUI tool generates a Sensor Controller Interface driver, which is a set of C source files that are compiled into the System CPU (ARM Cortex-M3) application. These source files contain the Sensor Controller firmware image and allow the System CPU application to control and exchange data with the Sensor Controller.

How do I get started using SCS and where can I find documentation?

Read this application note:

Download and install SCS. Check out the “Getting Started Guide/Tutorial” found in the top right corner of the Start Page.

Do the SimpleLink Academy trainings for the Sensor Controller found in Resource Explorer:

You can press F1 (Help Menu) in SCS or go to the “Help->Sensor Controller Studio Help” menu item in Sensor Controller Studio (SCS) to open the comprehensive help documentation. This covers almost everything except for for the generated driver API documentation which is found directly in the driver source files (scif.c, scif_framework.c, scif_osal_tirtos.c/scif_osal_none.c).

How much power does the sensor controller use?

In short, very little. Look at this thread post for some details. An even more detailed description will be written in the future:

At what clock frequency does the Sensor Controller run at?

Refer to section Active Mode in the TRM. The sensor controller, which is in the AUX power domain, has power modes which is independent upon the device power mode. In active mode the SCS framework will enable the 24 MHz clock source (derived from SCLK_HF). In standby mode the SCS framework will either turn off the clock or switch to the low speed 32 kHz clock if TIMER or GPIO event trigger is enabled. This is also the speed at which the sensor controller processor is running at. The maximum frequency is 24 MHz, and the configuration of clock division is controlled by the system CPU by configuring the AON_WUC:AUXCLK.SCLK_HF_DIV register.

If the question is answered, please press the  Verify Answer button below the answer to help other users find the correct answer easily.

1 Reply

  • This is really helpful.  Thanks Svend!

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.