Welcome to the next generation SimpleLink
CC26xx and CC13xx Arm® Cortex®-M4F and Arm Cortex-M3 based Bluetooth® Low Energy (BLE) microcontrollers (MCUs) from TI supporting Bluetooth versions 5.1, 5.2 and now Bluetooth mesh!
New to Bluetooth Low Energy or want more information about TI's System-on-Chip (SoC) BLE solutions? Please see www.ti.com/ble
This Guide and FAQ post will contain a list of the most common questions regarding the SimpleLink Bluetooth Low Energy ultra-low power enabled CC2642R, CC2652R, CC2652RB, CC2652P, CC2640R2F, CC2640R2L and multi-band CC1352R / CC1352P wireless MCUs, development kits and the BLE5-Stack Software Development Kit (SDK). Clicking on a device link will take you to the device's Product Folder where you will find data sheets, application notes, reference designs and software & tools specific to the device.
A troubleshooting section is provided below to help address common solutions. For more information regarding known issues and fixes, please visit Epic Post For Known Issues and Fixes for All SDKs
This guide is organized based on the sections listed below:
Getting Started: Selecting a development kit and understanding the BLE protocol
Sensor Controller - Frequently Asked Questions about the Sensor Controller Engine (SCE)
Troubleshooting - Common issues and solution
Q: What do I need to get started?
A: You need a development kit depending on the wireless SoC you intend to use in your product. Please select one of the following:
For Bluetooth 5.2 LE and Bluetooth mesh designs with an Arm Cortex-M4F and 256+ kB of flash memory for application development:
1) CC26x2R LaunchPad (LAUNCHXL-CC26x2R1). The CC26x2R LaunchPad is the recommended development kit for evaluating and developing Bluetooth 5 LE applications for the SimpleLink CC2642R Bluetooth Low Energy wireless MCU and SimpleLink CC2652R multiprotocol wireless MCU supporting IEEE 802.15.4 protocols such as Zigbee® and Thread.
2) CC2652RB LaunchPad (LP-CC2652RB) The LP-CC2652RB LaunchPad for evaluating and developing Bluetooth 5 LE applications on the SimpleLink crystal-less BAW CC2652RB multiprotocol 2.4GHz wireless MCU. More details on how BAW technology can simplify board layout with true crystal-less designs can be found here.
3) CC1352R LaunchPad SensorTag kit (LPSTK-CC1352R). Powered by 2xAAA batteries, this kit offers integrated environmental and motion sensors, single or multi band wireless connectivity and easy-to-use software for prototyping Bluetooth LE and mesh applications. Applications for this kit can seamlessly run on CC2642R or other CC26x2 2.4 GHz wireless MCUs.
4) CC1352P LaunchPad (LAUNCHXL-CC1352P). The LaunchPad for evaluating and developing Bluetooth 5 LE and/or IEEE 802.15.4 applications for the SimpleLink multiprotocol CC2652P wireless MCU with a configurable integrated power +20 dBm power amplifier (PA). Select the LAUNCHXL-CC1352P-2 option for evaluating the PA on the 2.4 GHz band. This kit family also supports the multi-band CC1352P wireless MCU with integrated PA.
5) 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, LP-CC2652RB, LAUNCHXL-CC1352R1 and LAUNCHXL-CC1352P LaunchPads feature an onboard XDS110 debugger / flash programmer, EnergyTrace power measurement technology and a a 32-bit Arm Cortex-M4F SimpleLink wireless MCU 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).
For CC2640R2F or CC2640R2L designs needing memory and cost-optimized Bluetooth 4.2 LE peripheral applications or Bluetooth 5 connectivity:
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 or CC2640R2L 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 Bluetooth Low Energy 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 Bluetooth v5.1 (using LE features defined by v4.2) and v5.0 based applications.
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 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.
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 (Qualified) |
Production / Evaluation |
|
CC2642R / CC2652R / CC1352R / CC2652P / |
SIMPLELINK-CC13XX-CC26XX-SDK |
v5.2: (High Speed + AE/Long Range), Direction Finding (AoA), LE Mesh |
Production |
| CC2640R2F / CC2640R2L |
SIMPLELINK-CC2640R2-SDK |
v5.1 , v5.0 (High Speed + AE/Long Range) |
Production |
| CC2640 / CC2650 | BLE-Stack v2.2.5 | v5.1 (using v4.2 LE features) | 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 are supported by Integrated Development Kits (IDEs) and toolchains: TI's free Code Composer Studio (CCS) and IAR Embedded Workbench for Arm (licensed by IAR). 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 LaunchPad development kits 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 CC2x62R and CC1352R / CC1352P, SimpleLink Academy is available in TI Resource Explorer via the SDK tool folder: SIMPLELINK-CC13X2-26X2-SDK Expanding the Labs tab shows available Bluetooth 5 training material, including Scanning, Advertising using the 2 Mbps PHY and working with Long Range (LE Coded PHY) Connections
- For CC2640R2F / CC2640R2L SimpleLink Academy is available at www.ti.com/simplelinkacademy and can be built in CCS Cloud as well as supported CCS desktop installations using the Resource Explorer.
- 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
SimpleLink Academy for CC13x2 / CC26x2 SDK
SimpleLink Academy for CC2640R2 SDK
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.
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 using Long Range Connections (LE Coded PHY), High Speed (2 Mbps) and Advertisement Extensions (AE)?
A: We recommend following the "Bluetooth 5 PHY" illustrative guides within SimpleLink Academy: SimpleLink Academy for CC13x2 / CC26x2 SDK or SimpleLink Academy for CC2640R2 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: Do you support Bluetooth Mesh Networks?
Yes! Bluetooth mesh v1.0.1 is enabled and qualified in SIMPLELINK-CC13X2-26X2-SDK v4.40 and later. TI's Bluetooth mesh solution is built upon the Zephyr Project Open Source Bluetooth mesh platform. Refer to the included BLE5 release notes in the SDK for further details and supported devices. Please see the "Bluetooth mesh fundementals" step-by-step guide in SimpleLink Academy for CC13x2 / CC26x2 SDK for getting up and running with TI's Bluetooth mesh solution.
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: Do you support HomeKit?
Support for HomeKit on CC26x2R is enabled by the SimpleLink software development kit (SDK) plug-in for HomeKit .
Q: Which debuggers are supported?
A:
- 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)
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) which you may use in your Bluetooth product. During production, TI provisions the device with a BDADDR generated from one of the TI-assigned 24-bit IEEE OUI blocks. There is no additional fee for using the TI-programmed IEEE address in your Bluetooth product. 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 identity 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 during the BLE stack initialization process. 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?
A: 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.3 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 2.6.3.2 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 / CC2640R2L, 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. 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. processors.wiki.ti.com/.../CC2640_Porting_Projects
Q: Do you have a response to Sweyntooth in regards to impacted TI devices?
A: Yes, you can find our response to Sweyntooth in the following two posts:
Bluetooth Low Energy – unexpected public key crash (SweynTooth)
Bluetooth Low Energy – invalid connection request (SweynTooth)
Q: Where can I found a step-by-step getting started guide for CC2650?
A: Here is one.
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 SensorTag tool folder.
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.
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.
The CC2640R2L, 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 (qualified to Bluetooth 5.1). 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.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 dev.ti.com.
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 5.1 protocol stack qualified design ID (QDID) is used on all SimpleLink CC26x0 & CC1350 BLE wireless MCUs. 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 in Bluetooth qualification application note SWRA601.
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.
System Configuration Tool (SysConfig)
SysConfig is a graphical tool for configuring your SimpleLink SDK project. To set up SysConfig please see the section Get started with SysConfig
Q: Which devices are supported by SysConfig?
A: All the devices compatible with SIMPLELINK-C13X2-26X2-SDK are supported by SysConfig
Q: Is it possible to edit the PIN names in the SysCfg tool?
A: Yes! Please consult this thread.
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 (http://processors.wiki.ti.com/index.php/CC26xx_HW_Checklist) 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: http://processors.wiki.ti.com/index.php/CC26xx_HW_Troubleshooting
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: 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.
IAR:
- Goto Tools->Configure Customer Argument Variables-->CC26xx TI-RTOS-->CC26XXWARE
Modify 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
CCS:
- 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
#ifdef CACHE_AS_RAM
0x00018063,
#endif //CACHE_AS_RAM
0xFFFFFFFF };
Q: I can't find BDS anymore, what happened?
A: Bluetooth SIG decided to discontinue the BDS, therefore you can't find BDS(also SLA BDS training section) anymore.
https://www.bluetooth.com/download-developer-studio
Q: How can I remove display and two buttons menu from the simple_peripheral_example? Is there more ways to decrease the FLASH consumption of the simple_peripheral example?
A:A few threads showing how to decrease the FLASH consumption of the simple_peripheral example exist. The guidance are provided here:
- Remove display CC26x2 / CC13x2: e2e.ti.com/.../879276
- Remove display CC2640R2: e2e.ti.com/.../3252666
- Remove #2 advertisement CC26x2 / CC13x2: e2e.ti.com/.../3255504
- Remove #2 advertisement CC2640R2: e2e.ti.com/.../88013
- Remove RSSI monitoring and auto PHY update CC26x2 / CC13x2: e2e.ti.com/.../880155
- Remove RSSI monitoring and auto PHY update CC2640R2: e2e.ti.com/.../880151
- Remove connection params updates CC26x2 / CC13x2: e2e.ti.com/.../880171
- Remove connection params updates CC2640R2: e2e.ti.com/.../880163
- Remove pairing CC26x2 / CC13x2: e2e.ti.com/.../880181
- Remove pairing CC2640R2: e2e.ti.com/.../880177
Q: How can I connect the debugger to a running target? (Also known as "Attach the debugger to a running target")
A: Please see the following thread.
— 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 or Cortex-M4F) 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: http://www.ti.com/lit/pdf/swra578
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: dev.ti.com/#/tirex
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:
https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/p/467128/1681248#1681248
At what clock frequency does the Sensor Controller run at?
Refer to section 17.5.2.1 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.
