Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

RemoTI-2.0.0-CC2650RC Developers Guide

From Texas Instruments Wiki
Jump to: navigation, search

Features

  • Voice over RF4CE
  • Compliance with ZigBee ZRC2.0 profile
  • Enhanced Security
  • Polling (Find my remote)
  • Buzzer and LED feedback
  • Automatic key remapping (data sent based on recipients profiles)
  • 3 x 16 key matrix scanning
  • Defaults with 3 pairing entries (can be increased)
  • Latency and FCC test modes
  • Over-the-air Download (OAD)

Pairing/Binding

The remote control sample application triggers validation based binding simply by calling RTI_BindReq() upon pressing the ‘Pair’ key. RTI and GDP, in turn, perform discovery, pairing and profile configuration in sequence. This will create a temporary pairing with the best pairing candidate, and then GDP validation based binding will require a button press on the target or entry of a pin code on the remote controller to validate the pairing. Once validated, the binding is considered complete.

When GDP performs discovery, it specifies the ZRC 1.x and 2.x profiles and searches for any device type. This behavior is defined in configParamTable in the RTI module, and is read at the time of generating a discovery request in the GDP profile gdpDo_StartDiscoveryProcedure() function.

GDP filters the discovered node descriptor by looking at the device type of the node descriptor. The device type list of a node descriptor is compared against the supported target device type list set by a RTI configuration parameter RTI_CP_ITEM_NODE_SUPPORTED_TGT_TYPES. Supported target types can be set up to six entries. In order to change this behavior, modify the gdpDoCheckNodeDeviceCapabilities() function. In order to simply increase the maximum number of supported target types, change RTI_MAX_NUM_SUPPORTED_TGT_TYPES constant in rti.h file and rebuild stack project.

Once discovery completes with an acceptable node descriptor, the rcnNlmePairReq_t structure is built and the RCN_NlmePairReq() function is called to move on with the network layer pairing procedure. See the gdpPo_SendPairRequest() function for details.

When binding successfully completes, the application is notified by the stack with a RTI_CMD_BIND_CNF event where it sets the destination target (rsaDestIndex, used for destination of any commands till next change) with the newly bound entry. This RTI_CMD_BIND_CNF event is triggered from the GDP profile when validation is successful.

Once the pairing table is full, the remote sample application won’t be able to pair with a new device any longer. Entries in the pairing table are removed by pressing the 'Pair' key while in test mode.

Key Code to Command Mapping

The key scanner module used by the CC2650RC is described in the CC2650RC user's guide. This section below describes how the keys are mapped on the CC2650RC remote control. From a software point-of-view, the key scanner reads a code combination of row and column, and notifies the remote control application that it needs to process a RSA_KEY_EVENT event. As a result, the remote control application calls kcb_ProcessKey() causing the key scanner to call the registered callback function, which in this case is RSA_ProcessKeys(rcKeyId_t keyId, rcKeyState_t keyState).

The arguments of RSA_ProcessKeys() contain keyID and a rsaKeyMap. Combined, these arguments are used to index into a table with desired key operations via rsaKeyMap. This rsaKeyMap, maps a key with an action, a CERC command and an HID command.

There are basically two types of actions; transmit action RSA_ACT_XMIT and special function action RSA_ACT_*. Transmit actions are passed to the function RSA_processXmitKey() whereas the RSA_ACT_* actions are mapped to different special functions. The rsaKeyMap is summarized below:

Key Scan Mapping Table
Button Name Key Scanner Button Command and Action Look Up Table
enum rcKeyId_t keyAction CERC CMD HID CMD
Power RC_SW_PWR RSA_ACT_XMIT RTI_CERC_POWER_TOGGLE_FUNCTION HID_NONE
Select TV RC_SW_TV RSA_ACT_SELECT_TV RTI_CERC_RESERVED_1 HID_NONE
Select STB RC_SW_STB RSA_ACT_SELECT_STB RTI_CERC_RESERVED_1 HID_NONE
Volume Up RC_SW_VOL_UP RSA_ACT_XMIT RTI_CERC_VOLUME_UP HID_NONE
Mute RC_SW_MUTE RSA_ACT_XMIT RTI_CERC_MUTE HID_NONE
Volume Down RC_SW_VOL_DN RSA_ACT_XMIT RTI_CERC_VOLUME_DOWN HID_NONE
Menu RC_SW_MENU RSA_ACT_XMIT RTI_CERC_ROOT_MENU HID_NONE
Home RC_SW_HOME RSA_ACT_XMIT RTI_CERC_SETUP_MENU HID_KEYBOARD_1
Back RC_SW_BACK RSA_ACT_XMIT RTI_CERC_BACKWARD HID_KEYBOARD_RETURN
Arrow Up RC_SW_UP_ARW RSA_ACT_XMIT RTI_CERC_UP HID_KEYBOARD_UP_ARROW
Enter RC_SW_ENTER RSA_ACT_XMIT RTI_CERC_SELECT HID_NONE
Arrow Left RC_SW_LF_ARW RSA_ACT_XMIT RTI_CERC_LEFT HID_KEYBOARD_LEFT_ARROW
Arrow Right RC_SW_RT_ARW RSA_ACT_XMIT RTI_CERC_RIGHT HID_KEYBOARD_RIGHT_ARROW
Arrow Down RC_SW_DN_ARW RSA_ACT_XMIT RTI_CERC_DOWN HID_KEYBOARD_DOWN_ARROW
Voice RC_SW_VOICE RSA_ACT_VOICE RTI_CERC_RESERVED_1 HID_NONE
Pair RC_SW_PAIR RSA_ACT_PAIR RTI_CERC_RESERVED_1 HID_NONE
Infinity RC_SW_INFINITY RSA_ACT_TEST_MODE RTI_CERC_RESERVED_1 HID_NONE
1 RC_SW_DIG_1 RSA_ACT_XMIT RTI_CERC_NUM_1 HID_KEYBOARD_1
3 RC_SW_DIG_3 RSA_ACT_XMIT RTI_CERC_NUM_3 HID_KEYBOARD_3
2 RC_SW_DIG_2 RSA_ACT_XMIT RTI_CERC_NUM_2 HID_KEYBOARD_2
4 RC_SW_DIG_4 RSA_ACT_XMIT RTI_CERC_NUM_4 HID_KEYBOARD_4
6 RC_SW_DIG_6 RSA_ACT_XMIT RTI_CERC_NUM_6 HID_KEYBOARD_6
5 RC_SW_DIG_5 RSA_ACT_XMIT RTI_CERC_NUM_5 HID_KEYBOARD_5
7 RC_SW_DIG_7 RSA_ACT_XMIT RTI_CERC_NUM_7 HID_KEYBOARD_7
9 RC_SW_DIG_9 RSA_ACT_XMIT RTI_CERC_NUM_9 HID_KEYBOARD_9
8 RC_SW_DIG_8 RSA_ACT_XMIT RTI_CERC_NUM_8 HID_KEYBOARD_8
AV RC_SW_AV RSA_ACT_KEY_EX RTI_CERC_RESERVED_1 HID_NONE
Record RC_SW_RECORD RSA_ACT_XMIT RTI_CERC_RECORD HID_NONE
0 RC_SW_DIG_0 RSA_ACT_XMIT RTI_CERC_NUM_0 HID_KEYBOARD_0
Previous RC_SW_PREV RSA_ACT_XMIT RTI_CERC_REWIND HID_NONE
Next RC_SW_NEXT RSA_ACT_XMIT RTI_CERC_FAST_FORWARD HID_NONE
Play RC_SW_PLAY RSA_ACT_XMIT RTI_CERC_PLAY HID_NONE

Transmit Actions

Depending of the current state different actions are actually taken based on the key. If bound/paired and ready to transmit then the currently paired node is checked. If the node supports ZRC2.0 then a ZRC2.0 formatted command is sent. If it also supports HID capabilities and the key has a valid HID command then an HID keyboard report is composed. If not then a normal CERC action is sent. If the node only supports ZRC1.1 or lower then a standard ZRC1.1 command is sent.

Mass Production Test Mode

See this page for details.

Certification Test Mode

See this page for details.

Latency Test Mode

See this page for details.

Enhanced Security

The CC2650RC supports and can demonstrate Enhanced Security as defined in the GDP2.0 specification. Since Enhanced Security is an optional GDP profile feature, please see the RF4CE Developer's Guide for details on how the stack is configured to enable this feature. Enhanced Security involves a Key Exchange procedure which may be invoked at anytime after the binding is completed. Thus the remote sets up rsaGdpCapabilities with the GDP_CAP_SUPPORT_ENHANCED_SECURITY_MASK and assigns the AV key to the action of initiating the Key Exchange procedure. At any time after the remote is bound with a recipient that supports Enhanced Security, the user may press the AV key on the remote which invokes RTI_KeyExchangeReq() and observe the Key exchange procedure take place, after which the remote and recipient should operate using the new network key. For details on the Key Exchange procedure, please see the GDP2.0 specification.

Voice over RF4CE

See SWRA506 for details.
Headers 1, 2, and 3 "IMA-ADPCM Data Frame" referenced by SWRA506 is generated by the TI-RTOS PDM driver's PDMCC26XX_metaData data structure's si and pv fields. See the PDM driver.

Remote Finder

The CC2650RC supports a remote finder feature where, if the remote control is physically lost such as under the couch or in the toy box, the user can initiate an action on the target to cause the remote to identify itself via a buzzer ring. This feature is made possible through the poll based transmission scheme and client notification command of the GDP2.0 profile.

The feature can easily be demonstrated using the Target Emulator and CC2650RC. To do so, open the Target Emulator and bind the CC2650RC to it. After binding is complete, the GDP Poll Negotiation Procedure should execute automatically after which the CC2650RC should start polling the Target. The interval at which the CC2650RC will poll is specified by the Target Emulator and is defaulted to 3 seconds. The poll interval can be changed by selecting Options->Polling Time Interval. Once the CC2650RC is polling the target, you can exercise the remote finder feature by selecting Options->Find My Remote. Choose the Identify Time, which is how long the remote will identify itself, and the form of identification you want the remote to perform. Press the Find My Remote button, and upon next poll, the CC2650RC should receive the Client Notification command to Identify itself by buzzing for the specified time. The processing of this notification occurs in RSA_processClientNotification().

The remote finder feature is made possible by configuring the Target Emulator as a Poll Server and the CC2650RC as Poll Client. For more details on the GDP Polling scheme and Client Notifications including the Identify command, please see the GDP2.0 Profile. It should be noted the remote finder can be a very powerful feature, but polling scheme could have adverse effects on the remote control battery life. Careful consideration should be given to a specific remote control's application to find the best balance between polling frequency and battery life.

Flash Page Map and Memory Map

Both application and stack require flash and RAM. To help with the effort to split these resources between the application and stack images, RemoTI 2.0 includes a frontier (French for "Boundary") tool. Frontier adjusts a .bdef and linker files which are shared between the application and stack projects. The intent is to allow frontier to allocate just enough flash and RAM resources for the stack to operate correctly while allocating the remaining resources to the application.

The following are sample frontier boundary files for CCS and IAR:

Toolchain .bdef file .linker file
CCS ccs_boundary_linker.bdef ccs_boundary_linker.cmd
--define=ICALL_STACK0_ADDR=0x1cfc1
--define=ICALL_STACK0_START=0x13000
--define=ICALL_RAM0_START=0x20004288
IAR iar_boundary_linker.bdef iar_boundary_linker.icf
-D=ICALL_STACK0_ADDR=0x1cfc1
-D=ICALL_STACK0_START=0x13000
-D=ICALL_RAM0_START=0x20004288
  • ICALL_STACK0_ADDR: Entry point for the stack (flash)
  • ICALL_STACK0_START: Starting flash address for the stack
  • ICALL_RAM0_START: Starting RAM address for the the stack

Non-volatile Memory

The CC2650RC has two types of non-volatile memory; on-chip (flash) and off-chip (external SPI flash). The on-chip flash is uesd by the RF4CE protocol stack and by the application, while the external flash is only used by the application for over-the-air downloads (OAD).

IEEE Address

The CC26xx has its own IEEE address built into the chip (information page IEEE address). This is the IEEE you get when reading back the primary IEEE address using SmartRF Flash Programmer2. The Network Layer uses this address unless an address other than 0xFFFFFFFFFFFFFFFF has been set by upper layers. Upon reset the RTI module will check with the RCN layer for an IEEE address. This location is always in the last page of the flash, which is a read-only page when the chip is not running in debug mode. It is the last 8 bytes just before the lock bits, and also what you get when reading/writing the secondary IEEE address using SmartRF Flash Programmer2.

The upper layer can overwrite the IEEE address other than via the secondary IEEE address. This is writable via:

   RTI_WriteItem()
  Add code snippet here...

RTI_WriteItem() is routed down to the Network Layer and updates the IEEE address correctly.

Note that the order of when it is updated matters. To explain better please consider the following initialization sequence

1. RCN_Init() - Reads IEEE from NV. If it doesn't exist, which is the case on first boot, or if it matches 0xFFFFFFFFFFFFFFFF, then the primary IEEE address is used. The updated address is written to NV.
2. RTI_Init() - Calls RTI_ProgramIeeeAddr(). This routine reads the secondary IEEE and compares it with 0xFFFFFFFFFFFFFFFF. If it does not match 0xFFFFFFFFFFFFFFFF then it routed to the Network Layer. This will also update the IEEE address in NV.

Stack project

C source files and library files are explained in table below in the order that appears in the IAR and CCS projects. Note that there are more files than those listed in the table, such as C header files that define constants and function prototypes and also note that project itself does not list all header files referenced by the C files.

File Description
application
rcn_config.c This file contains configurable variables of RF4CE network layer.
hal
mb_patch.c This patch file contains the data structures and APIs for CC26xx doorbell.
hal_appasrt.c
hal_assert.c
This module contains the application assert functions.
hal_flash_wrapper.c This file implements the hal_flash interface for the flash driver.
hal_rtc_wrapper.c This file provides various wrapper routines for the Always On (AON) Real Time Clock (RTC).
hal_trng_wrapper.c This file contains an API for returning a True Random Number Generator.
icall_remoti
rti_stack_icall.c RTI stack-side interface to ICall
osal
osal_bufmgr.c
osal_clock.c
osal_memory_icall.c
osal_pwrmgnr.c
osal_snv_octp.c
osal_timers.c
osal.c
A legacy OSAL wrapper used by the stack
profiles
gdp
gdp.c Implements GDP profile
gdp_binding_originator.c Module for handling the binding procedure for a GDP 2.0 originator node
gdp_common.c Module containing code and data that is used by both GDP 2.0 Originator and Recipient devices
gdp_configuration_originator.c Originator node implementation of the configuration state of the GDP 2.0 binding procedure
gdp_discovery_originator.c Originator node implementation of the discovery state of the GDP 2.0 binding procedure
gdp_enhanced_security.c Implementation of the Enhanced Security feature
gdp_identification_client.c Definitions for a GDP Identification Client
gdp_originator_task.c GDP Originator task definitions
gdp_pairing_originator.c Originator node implementation of the pairing state of the GDP 2.0 binding procedure
gdp_poll_client.c Definitions for a GDP Polling Client
gdp_recipient_task.c GDP Recipient task definitions
gdp_validation_originator.c Originator node implementation of the validation state of the GDP 2.0 binding procedure
zrc
zrc.c Definitions for a ZRC2.0 Profile
zrc_action_mapping_client.c Definitions for an Action Mapping client
zrc_binding_originator.c Handles the binding procedure for a ZRC 2.0 Originator node
zrc_configuration_originator.c Originator node implementation of the ZRC configuration state of the GDP 2.0 binding procedure
zrc_home_automation_client.c Home Automation Client implementation
rti
rti.c
rti_internal.c
rti_version.c
This file contains the the RemoTI (RTI) API.
rti_testmode.c RemoTI Certification API function implementation
startup
common_rom_init.c ROM initialization
icall_startup.c ICall initialization and entry point
osaltasks.c OSAL initialization
rom_init.c Entry point code for ROM functions
tools
cc26xx_stack.cmd/icf Stack linker command file

Application project

C source files and library files are explained in table below in the order that appears in the IAR and CCS projects. Note that there are more files than those listed in the table, such as C header files that define constants and function prototypes and also note that project itself does not list all header files referenced by the C files.

File Description
Application
remote_control_test.c
remote_control.c
Remote control sample application (RSA)
rsa_snvOctp.c This module contains the RSA simple non-volatile memory functions.
util.c This file contains utility functions commonly used by BLE applications for CC26xx with TIRTOS.
Drivers
ExtFlash.c External flash storage abstraction
key_scan.c This file contains the key scanner for a key matrix.
SensorI2C.c
SensorMpu9250.c
Middleware to interface with the onboard MPU9250
WatchdogCC26XX.c TI-RTOS doesn't have a Watchdog driver for the CC26XX, therefore one is provided in the project.
Buzzer.c PWM-based buzzer interface.
Pwrmon.c Implementation for CC26xx Vdd monitoring subsystem
ICall
crypto_board.c TI-RTOS and *Ware implementation of Crypto board service
icall_cc2650.c
icall.c
CC2650 specific ICall function implementation
ICall_RemoTI
rti_app_icall.c RTI stack C interface implementation on top of dispatcher messaging interface.
OAD
oad_client.c This file contains implementation OAD downloadable image utilities to make downloadable image function as OAD client.
oad_crc.c CRC mechanism for the RemoTI OAD. Modified to support CC26xx Remote Control
Services
appasrt.c Application assert handler functions
kcb.c Key Callback Services
nvoctp.c NV driver for CC26xx devices - On-Chip Two-Page Flash Memory
Startup
CC2650RC.c TI-RTOS CC2650RC board file
ccfg.c Customer Configuration CC26xx device family
main.c Application starting point
TOOLS
cc26xx_app.cmd
cc26xx_app_oad.cmd
Application linker command file
ccs_boundary_linker.cmd/icf Linker command file used by the Frontier tool
app_rf4ce.cfg
app_rf4ce_oad.cfg
TI-RTOS RTSC .cfg file configured for OAD
ccs_boundary_compiler.bdef Frontier boundary definition file