Introduction

The purpose of this exercise is to introduce the user to the coexistence feature, and familiarize the user with how it is configured for a Bluetooth LE device.

Task 0: Modify the Simple Peripheral Project

This task shows how to modify the Bluetooth LE device description to display a different name when advertising.

Task 1: Coexistence Configuration

This task will describe how the coexistence feature is enabled and configured.

Task 2: Validate Configuration

This task will describe how the coexistence configuration can be validated.

Prerequisites

Hardware

For this lab, you need two Bluetooth-enabled development boards. Supported development boards are:

• SimpleLink™ CC26x2R LaunchPad™
• SimpleLink™ CC2652RSIP LaunchPad™
• SimpleLink™ CC2652RB LaunchPad™
• SimpleLink™ CC1352R LaunchPad™
• SimpleLink™ CC1352P LaunchPad™
• SimpleLink™ CC2652R7 LaunchPad™
• SimpleLink™ CC1352P7 LaunchPad™

Software

• CCS 12.1 or IAR 8.50.9 installed with support for CC13xx/CC26xx devices.
• SimpleLink™ CC13XX and CC26XX SDK 6.40

For testing, a Bluetooth client application is required:

• BTool (located in the tools\ble5stack directory of the SimpleLink™ SDK installation) OR
• Bluetooth mobile apps:
  • Android: TI SimpleLink Starter - available on the Google Play store
  • iOS: TI SimpleLink Starter - available on the App Store

Recommended reading

• Coexistence Chapter of the TI BLE5-Stack User's Guide

Getting started – Desktop

To later verify the coexistence (Coex) configuration, we need to set up the LaunchPad as a Bluetooth LE peripheral device. We will use Simple Peripheral for this purpose. You can find Simple Peripheral in the SDK alongside other BLE5-Stack example projects.

Import the Simple Peripheral project into CCS. If you want to check that your peripheral device (board loaded with the Simple Peripheral code) is advertising, you can flash the device with the default project settings and use your phone with the the SimpleLink Starter app (link at the section Prerequisites above) or another Bluetooth LE Client app. Then, try to detect it in the list of available devices.

Task 0 – Modify the Simple Peripheral Project

When the Simple Peripheral project is imported into CCS, as described in Getting Started, open the system configuration tool by double-clicking the simple_peripheral.syscfg file.

The following describes how to change the name of the Simple Peripheral project, that is, how the advertisements are displayed in your Bluetooth LE Client app. This will make it easier to verify the configuration later, and also verify that your setup is correct up until this point. If you are okay with the default settings of the Simple Peripheral project, skip to Task 1 now.

Select the BLE module in the left panel of the SysConfig tool. Change the device name under General Configuration → Device Name. For this lab the device name Project Coex is used.

When modifying the device name as in the above, you should also make sure the advertisement data (at least when using Local Name) matches the device name. For this lab, to be sure of continuity, it is recommended to enable the use of Complete Local Name for the advertisement data sets. For this, navigate to Broadcaster Configuration → Advertisement Set [1,2] and under both Advertisement Data and Scan Response Data you can enable the Complete Local Name option and fill in the same name you chose for Device Name. In this lab we use Project Coex.

With the above modifications saved, built and flashed to the device, you can scan the device with your preferred Bluetooth LE Client application. You should see something similar to this:

Task 1 – Coexistence Configuration

If you are not familiar with wireless coexistence (Coex), or how the Coex feature is implemented for the SimpleLink™ CC13XX/CC26XX SDK, you should take a look at the Coexistence section of the TI BLE5-Stack User's Guide.

To make sure you remember what you read about the feature, take a minute to verify what you know.

The option to enable coexistence can either be found by accessing the RF Driver module in the left panel directly, or by navigating in the BLE module → Radio → BLE Radio Configuration → Other Dependencies → Radio Frequency (RF) Driver. Enable coexistence, and take note of the default options.

We are not going to change any of these default options, but notice that the Coex GRANT signal is defined with idle level High. This will be important later.

As for the option BLE Use Case Configuration, this provides the granularity to specify custom behavior for the different Bluetooth LE use cases; Connection establishment, Connected, Broadcaster and Observer. For this lab it should stay as it is.

Because Coex Mode is set to 3-Wire, three pins are dedicated for the Coex signaling. Which pins the REQUEST and PRIORITY signals are mapped to is not important for this lab, but make sure the GRANT pin is next to GND. In this case, for the CC26X2R, this will be DIO 23. To display the LaunchPad pin graphic, click on the Show Board View button in the top right corner of the SysConfig window.

Remember to save the changes you have done to the simple_peripheral.syscfg, build the project with the new changes, and flash the device.

Task 2 – Validate Configuration

The Coex configuration can be validated with the Bluetooth LE Client scanner approach used in Task 0. With the changes made in Task 1 built and flashed to the device, the Bluetooth LE Client scanner will show no evidence of the Bluetooth LE device advertising anything. That is, Project Coex (if you followed the steps of Task 0), is not visible in any scan list.

As stated in the Coexistence Chapter of the TI BLE5-Stack User's Guide, the Bluetooth LE device is expecting an active GRANT signal to advertise. Without such a confirmation signal, nothing will happen. This is because the Bluetooth LE device is configured for 3-Wire Coex, and the device pins are not wired to any Coex Central device. Notice that if we configure the Coex mode to be 1-Wire REQUEST, the GRANT signal would not be in use, and the Bluetooth LE device would be free to advertise regardless of any pin connection.

To validate the configuration, and overcome the issue with a missing Coex Central, we can hard-wire the GRANT pin to either the 3V3 or the GND header pin.

If you have configured the coexistence interface as specified in Task 1, the GRANT signal should be set to idle level high. This means that the GRANT pin can be connected to GND to provide the Bluetooth LE device with a static active GRANT signal. When the GRANT signal is mapped to a pin next to the GND pin, one of the LaunchPad jumpers not in use (e.g. one of the LED jumpers) can be used to bridge the gap between the GRANT pin and the GND pin. See the illustration image below.

By moving a jumper to hard-wire a static GRANT signal to the Bluetooth LE device, you can again check your Bluetooth LE Client application, and verify that the device is visible in the scan list.

Debugging

The coexistence feature relies on signal mapping to device pins. If you have a logic analyzer available, you can connect this to the Coex pins as you have mapped them in SysConfig (described in Task 1). With this you are able to validate your configuration, and analyze the signal behavior. The trace output from this will be similar to the timing diagram in the Coexistence Chapter of the TI BLE5-Stack User's Guide.

During debugging, it may be helpful to configure the coexistence feature in 1-Wire REQUEST mode. The 1-Wire REQUEST configuration will allow the developer to see when the device is going to perform any RF activity.

When the coexistence pins are configured, the rfDriverCallbackCoex() callback function is used. The function definition of rfDriverCallbackCoex() can be found in the ti_drivers_config.c file which is generated by SysConfig. This callback may be modified if desired for debugging purposes. The rfDriverCallbackCoex() function is defined as weak which means it can be overwritten elsewhere in the project.

It is possible for the application to take back control of the Coex pins from the radio core. This may be useful for debugging purposes. To do this, the rfDriverCallbackCoex() callback function within the ti_drivers_config.c file should be referenced. The Coex pins are configured within the rfDriverCallbackCoex() function. This logic can be repurposed in the application in order to assist debugging efforts. For example, to take control of the REQUEST pin, the CONFIG_RF_COEX_REQUEST constant should be used. The following code snippet will configure the REQUEST pin as a general output GPIO:

GPIO_setConfig(CONFIG_RF_COEX_REQUEST, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_HIGH); // Set to config to output GPIO

To yield back control of the GPIO, the following code snippet may be used:

GPIO_setMux(CONFIG_RF_COEX_REQUEST, IOC_PORT_RFC_GPO1); // Reset back to coex configuration

References

TI BLE5-Stack User's Guide

Bluetooth low energy Fundamentals

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.