Custom Hardware

This section will explain how to adapt a BLE5-Stack application from the SimpleLink Low Power F3 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.

Note

A similar app note will be produced for the CC23xx devices. In the meantime, we recommend leveraging the reference designs available in the MSR folder.

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 as described here.

Clock accuracies and Bluetooth LE

The Bluetooth Core Specifications Version 5.3 defines two clock accuracies, the “Active clock accuracy” (Bluetooth Core Specifications Version 5.3 Vol 6, Part B, §4.2.1) and the “Sleep clock accuracy” (Bluetooth Core Specifications Version 5.3 Vol 6, Part B, §4.2.1). In general, the HF XTAL (high frequency crystal oscillator) is used as active clock and the LF XTAL (low frequency crystal oscillator) is used as sleep clock. Tuning of the HF XTAL and LF XTAL is discussed in the HW Configuration Guide.

The Bluetooth Core Specifications Version 5.3 require the active clock to have a drift less than or equal to ±50 ppm and there is no way (nor need) to specify its accuracy to the TI BLE5-Stack.

The Bluetooth Core Specifications Version 5.3 require the sleep clock to have a drift less than or equal to ±500 ppm. The accuracy of this clock has a real impact on the timing of the radio operations. This is why its accuracy should be communicated to the TI BLE5-Stack using the function HCI_EXT_SetSCACmd().

As mentioned before, the accuracy of the sleep clock has an impact on the timing of the radio operations. This effect is called window widening and is described in details in the Bluetooth Core Specifications Version 5.3 Vol 6, Part B, §4.2.4.

The Link Layer is expecting to receive a packet within a certain window (extending from receiveWindowStart to receiveWindowEnd) or at a certain time (in which case receiveWindowStart and receiveWindowEnd are both that time) but, because of active clock accuracies and sleep clock accuracies there is uncertainty as to the exact timing of that window at the sending Link Layer. The recipient should therefore adjust its listening time to allow for this uncertainty. The increase in listening time is called the window widening. Assuming the clock inaccuracies are purely given in parts per million (ppm), it is calculated as follows:

where J shall be 2 when the active clock applies and 16 when the sleep clock applies and the other parameters are specified in Table 4.1. of Bluetooth Core Specifications Version 5.3 Vol 6, Part B, §4.2.4.

The connection parameters can be chosen independently of the clock accuracy – absolutely all the combinations of clock accuracy and connection parameters are allowed. As can be observed in the formula, for a given clock accuracy, the listening window length is proportional to the effective connection interval. At a certain point this might have a significant impact on the energy consumption.

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 CC23xx SimpleLink Wireless MCU Technical Reference Manual.

Initial Board Bring Up

When powering up a custom board with the CC23xx 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 SWD tool, programming the device with a minimal SW application to verify stability is also suggested.

TI recommends using the basic_ble 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)

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.

Using the RGE QFN24 package variant

The CC23xx is also available with a 4-mm x 4-mm RGE QFN24 (12 GPIOs) package variant. See the CC23xx Datasheet for all the package options and IO descriptions.

In order to build SimpleLink Low Power F3 SDK project using the RGE package, a few changes must be made.

• First, open ble_rf_config.syscfg.js, located in the SimpleLink Low Power F3 SDK → source → ti → ble5stack → .meta → rfconfig. This file needs to be modified to add a case for CC2340R5RGE in ble_rf_config.syscfg.js → getRfDesignOptions() as below:

  /***add this code, located around line 317***/
  else if(deviceId === "CC2340R5RGE")
  {
      newRfDesignOptions = [{name: "LP_EM_CC2340R5"}]
  }
  /***end***/
  return(newRfDesignOptions);
  

• Import the desired SimpleLink Low Power F3 SDK project

• Open the .syscfg file with the SysConfig Editor and go to Show Board View -> Use Custom Board -> Confirm.

• Save the changes after applying and close .syscfg

• Open .syscfg in a Text Editor and revise argument list to use RGE instead of RKP

• Save the changes after applying and close .syscfg

• Open .syscfg with the SysConfig Editor and resolve any PinMux issues caused by the limited number of GPIOs

• Build the project