This section will explain how to adapt a BLE application from the SimpleLink CC26x2 SDK to run on custom hardware. In general, the steps required to migrate a BLE application from a development kit to a custom board are minimal and involve changing the pin configuration as well as selecting the correct RF configuration. These steps, including a bring up guide, are detailed in the subsections below.

Creating a Custom Board File

TI-RTOS drivers rely on “board files” for their board-specific configuration parameters. The convention is to name these files based on the development kits provided by TI in addition to a generic Board.h with Board_* definitions to map the proper pins defined by ioc.h.

For example, for the simple_peripheral project, the following comprise the set of board files used by the CC26x2 LaunchPad development kit:

  • Board.h
  • CC26X2R1_LAUNCHXL.h
  • CC26X2R1_LAUNCHXL.c

Note

For the SimpleLink CC13x2 SDK, you would use the CC1352R1_LAUNCHXL.h and CC1352R1_LAUNCHXL.c board files.

TI recommends to start with these existing set of board files when porting a BLE application to custom development boards. When modifying or porting these board files, user should consult with TI Driver APIs.

Tip

Board files provided by TI include TI-RTOS driver configuration data structures for various drivers. If the application does not use the associated TI-RTOS drivers, the linker will simply omit them from the application image.

The following steps provide guidance on customizing board files for a BLE5-Stack 1.01.01.00 project.

  1. Duplicate existing board files from existing CC26X2R1_LAUNCHXL board files.

    • These files can be found at: <SDK_INSTALL_DIR>\source\ti\boards\CC26X2R1_LAUNCHXL
    • Create a copy of the CC26X2R1_LAUNCHXL directory and give it a unique meaningful name for your development platform. In this example, we call it MYBOARD.

    Caution

    The SimpleLink CC26x2 SDK also contains board files for TI-RTOS kernel and driver examples. These are not compatible with the BLE5-Stack 1.01.01.00 because of differences in RF driver SWI priorities and custom drivers (e.g. TRNG) requiired by BLE5-Stack 1.01.01.00. For BLE5-Stack projects, use the files specified above for reference from simple_peripheral.

    • In the MYBOARD directory, rename CC26X2R1_LAUNCHXL.c and CC26X2R1_LAUNCHXL.h to their MYBOARD.c and MYBOARD.h respectively.
    • Search and replace all references of CC26X2R1_LAUNCHXL with MYBOARD in Board.h, MYBOARD.c and MYBOARD.h.

  2. Add a new preprocessor define in your project’s board.c and board.h files.

    Continuing with the MYBOARD example, modify board.c and board.h in <SDK_INSTALL_DIR>\source\ti\target

    • Replace CC26X2R1_LAUNCHXL by MYBOARD in your project’s application predefined symbols (See Compiler Options)

    • In board.h, add a link to your Board.h file.

      1
2
3
4
      #elif defined(CC26X2R1_LAUNCHXL)
    #include "./cc26x2r1lp/cc26x2r1lp_board.h"
#elif defined(MYBOARD)
    #include "../../boards/MYBOARD/Board.h"

    • In board.c, add the highlighted lines shown below:

      1
2
3
4
5
      #elif defined(CC26X2R1_LAUNCHXL)
    #include "./cc26x2r1lp/cc26x2r1lp_board.c"
#elif defined(MYBOARD)
    #include "../../boards/MYBOARD/Board.h"
    #include "../../boards/MYBOARD/MYBOARD.c"

    • Explicit references to CC26X2R1_LAUNCHXL.h need to be replaced by MYBOARD.h

  3. Modify board files to match application requirements

    • PIN structure to match the layout of the board.
    • Add peripheral driver initialization objects according to the board design. The TI Drivers documentation for more information.
    • For RF driver configuration, see Configuring the RF Front-End for Custom Hardware

Board Level Middleware

There are also several board driver files which are a layer of abstraction on top of TI-RTOS drivers, to function for a specific board, for example Board_key.c, or ExtFlash.c If desired, these files can be adapted to work for a custom board.

Using 32-kHz Crystal-Less Mode

BLE5-Stack 1.01.01.00 includes support for operating the CC26x2 in a 32-kHz crystal-less mode for peripheral and broadcaster (beacon) role configurations. By using the internal low-frequency RC oscillator (RCOSC_LF), the 32-kHz crystal can be removed from the board layout.

There are a few steps that must be taken to enable this feature. For any peripheral project, the following change is required for IAR. For CCS user, please see the Running Bluetooth Low Energy on CC2640 Without 32 kHz Crystal for the needed steps to enable RCOSC_LF in your project. You will find more detail regarding this feature in the aforementioned application note.

  1. Include `rcosc_calibration.c, rcosc_calibration.h and ccfg_app_ble_rcosc.c files which locate at <SDK_INSTALL_DIR>\source\ti\ble5stack\common\cc26xx\rcosc

  2. Exclude ccfg_app_ble.c from build.

  3. Add USE_RCOSC to the .opt file containing the application defines.

  4. Add the following code to your peripheral project.c

    Listing 96. RCOSC calibration include
    #ifdef USE_RCOSC
#include "rcosc_calibration.h"
#endif //USE_RCOSC

  5. Add the following code to your peripheralproject_init function in peripheral project.c

    Listing 97. RCOSC calibration enable
    #ifdef USE_RCOSC
RCOSC_enableCalibration();
#endif // USE_RCOSC

  6. If using a custom board file, enable the RCOSC in the power policy. The board files included with the BLE5-Stack:

    Listing 98. Power driver configuration
    PowerCC26X2_Config PowerCC26X2_config = {
  .policyInitFxn     = NULL,
  .policyFxn         = &PowerCC26XX_standbyPolicy,
  .calibrateFxn      = &PowerCC26XX_calibrate,
  .enablePolicy      = TRUE,
  .calibrateRCOSC_LF = TRUE,
  .calibrateRCOSC_HF = TRUE,
};

  7. Constrain the temperature variation to be less than 1°C/sec. If the temperature is to change faster than 1°C/sec, then a short calibration interval must be used. Calibration interval can be tuned in rcosc_calibration.h

    Listing 99. RCOSCLF calibration interval
    // 1000 ms
#define RCOSC_CALIBRATION_PERIOD   1000

Note

Use of the internal RCOSC_LF requires a sleep clock accuracy (SCA) of 500 ppm.

Configuring the RF Front-End for Custom Hardware

The CC26x2 supports multiple RF front end options to optimize performance or cost. Reference designs are available for multiple RF front end options to aid in decoupling and RF layout. In order to achieve optimal sensitivity, it is important to configure the BLE application with the correct RF front end setting used on the custom board. An incorrectly configured RF front end may result in substantially degraded RF performance such as the inability to maintain a connection with a peer device. Configuration of the Front-EndRF front end is done within the board file.

For example, within the simple_peripheral project, the RF front end configuration is specified by defining CC26X2 via the .opt file.

The defined symbol is used in ble_user_config.h and ble_user_config.c to set the correct RF Front end mode, and the select the appropriate PA table for that configuration. In ble_user_config.h, CC26X2 is processed to define RF_FE_MODE_AND_BIAS:

1
2
3
4
#elif defined( CC26X2 )

  #define RF_FE_MODE_AND_BIAS           ( RF_FE_DIFFERENTIAL | \
                                          RF_FE_INT_BIAS)

Note

For the SimpleLink CC13x2 SDK, you would use “-DCC13X2”.

This configures the project to use a differential RF with internal bias. Other configurations can also be found in ble_user_config.h, select the configuration appropriate to your project.

Note

There are several other parameters being configured in ble_user_config. For CC26x2 it is only the RF front end mode and PA table that have to be changed for different boards.

For information on front ends and antenna configurations, see CC26xx RF FrontEnds and Antennas.

For information on other hardware considerations, see TI Bluetooth Low Energy Wiki.

Configuring Device Parameters for Custom Hardware

  1. Set parameters, such as the sleep clock accuracy of the 32.768-kHz crystal. See HCI_EXT_SetSCACmd()
  2. Define the CCFG parameters in ccfg_app_ble.c to enable or disable the ROM serial bootloader, JTAG access (DAP), flash protection, and so forth.

Note

For a description of CCFG configuration parameters, see the CC26x2 Technical Reference Manual.

Initial Board Bring Up

When powering up a custom board with the CC26x2 for the first time, it is recommended to complete the HW checklist items on the TI BLE Wiki. After confirming that the board is being powered correctly by the battery or power supply and can be identified by the JTAG tool, programming the device with a minimal SW application to verify stability is also suggested.

TI recommends using the simple_peripheral sample application for initial board bring up with modifications to the board file to:

  1. Disable all GPIO pin access
  2. Select the correct RF front end setting.

To disable all GPIO pin configuration, set the BoardGpioInitTable in the board file to PIN_TERMINATE:

1
2
3
4
const PIN_Config BoardGpioInitTable[] = {

    PIN_TERMINATE
};

The TI BLE5-Stack does not require any GPIO pins to be configured in order to establish and maintain a BLE connection. Ensure that Display_DISABLE_ALL is defined in the application Predefined Symbols so that diagnostic logging data is not routed to any GPIO pin. If your custom board uses a different device configuration, such as the 32 kHz crystal-less RCOSC_LF configuration, be sure to make these device changes to the project. With this minimal application configuration you should be able to establish a BLE connection (e.g., with a smart phone or BTool) to your board at the expected range. If you are not able to complete this step, then it is likely there is a misconfiguration of the RF front end or you have other board related or layout issues. Refer to the hardware troubleshooting tips on the TI BLE Wiki.

After confirming that your board can maintain a BLE connection, you can now validate that your BLE application functions as expected on the custom board. Again, it is suggested to enable your GPIO pins one at a time in the board file and comment-out access to other GPIO pins in your application. If you do encounter a CPU exception (HWI abort) during this phase it is likely that a GPIO pin is incorrectly mapped in your custom board file or your application is attempting to access a GPIO pin that does not exist in your device package type.