Custom Hardware

This section will explain how to adapt a BLE5-Stack application from the SimpleLink CC13x2 / 26x2 SDK to run on custom hardware. In general, the steps required to migrate a BLE5-Stack 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.

Designing a Custom Board

Design guidelines for CC13x2 and CC26x2 boards can be found in the CC13xx/CC26xx Hardware Configuration and PCB Design Considerations app note. This app note includes RF front-end, schematic, PCB, and antenna design considerations. The report also covers crystal oscillator tuning, optimum load impedance as well as a brief explanation of the different power supply configurations.

Creating a Custom Board File

Board files are used by TI drivers to store device specific settings and I/O mapping. The board file abstraction allows one TI-drivers implementation to support many hardware implementations by just setting up new board files. Examples utilize SysConfig to generate these board files. The generated structures are placed in the ti_drivers_config.c and ti_drivers_config.h files. The SysConfig user interface can be utilized to determine pins and resources used. Information on pins and resources used is also present in both of these generated files. It is recommended to use SysConfig to generate the board files for custom hardware.

Using 32-kHz Crystal-Less Mode

BLE5-Stack 2.01.03.00 includes support for operating the CC13x2 or 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. When using SysConfig to generate a board file, be sure to select Calibrate RCOSC_LF in the TI Drivers -> Power settings menu in SysConfig.

  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 98. 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.

Change Device Configuration

If you need to change the device definition in your IDE, you can find instruction below.

Note

In most cases it is not necessary to change the IDE device configuration. However, if you have been testing software on a different device than your final product will use, it can be useful. Example situations are:

Changing Device in CCS

Go to Project → Properties → General → Project → Variant and select your device.

Attention

There is a known issue in CCS where, when changing the Variant, the Target may also change. This will cause build errors. To avoid this, go to Project → Properties → General → Products and check the Target and after you change the Variant.

Changing Device in IAR

Go to Project → Options → General Options → Target and select your device.

Configuring Device Parameters for Custom Hardware

  1. Set parameters, such as the sleep clock accuracy of the 32.768-kHz crystal.
  2. Define the CCFG parameters in Device Configuration in SysConfig.

Note

For a description of CCFG configuration parameters, see the CC13x2 CC26x2 SimpleLink Wireless MCU Technical Reference Manual.

Configuring the RF Front-End for Custom Hardware

The CC13x2 or 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 BLE5-Stack 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 RF front end is done by SysConfig for BLE5-Stack projects in the RF Stacks -> BLE5-Stack -> Radio menu.

For information on front ends, antenna configurations and other hardware considerations, please see CC13xx/CC26xx Hardware Configuration and PCB Design Considerations.

Set-up SysConfig When Using a Custom Board

The following only applies when using a CC1352P device.

When using a CC1352P device, you need to configure SysConfig in order to meet your design’s needs. This must be done by selecting the correct option for “Based On RF Design” inside the RF Design and the stack modules of SysConfig (only the stack modules used by your project needs your attention).

../_images/SysConfig_CustomBoard.png

Figure 113. Select the correct option for “Based On RF Design” inside the RF Design and the stack modules of SysConfig [here an example for BLE]

The allowable TX power range with High PA enabled (programmmable by up to 6 dB) for the 2.4 GHz band is dependent on the RF design chosen. The LAUNCHXL-CC1352P-2 maximizes output from 14 to 20 dBm, whereas the LAUNCHXL-CC1352P-4 is optimized to support power levels from 6 to 10 dBm.

Note

There exist unexpected build or runtime behaviors caused by using the “Custom Board” SysConfig button in the 3.30 or 3.40 versions of the SimpleLink SDK. Please consult this E2E post for further instructions on how to resolve the issue.

Initial Board Bring Up

When powering up a custom board with the CC13x2 or CC26x2 for the first time, it is recommended to follow the Board Bring-Up section on CC13xx/CC26xx Hardware Configuration and PCB Design Considerations. 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 ti_drivers_config.c file to:

  1. Disable all GPIO pin access
  2. Select the correct RF front end setting (done by SysConfig)

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.

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.