CC2640: TI-RTOS Migration 2 15

General TI-RTOS changes

• TI-RTOS drivers and board files have moved to a new TI-DRIVERS component. Refer to the TI-DRIVERS section below for more details.
• Deprecated driver XDC modules have been removed. Configuration files using driver modules (i.e. xdc.useModule('ti.drivers.Driver');) will fail during the configuration phase of the build. These statements should be removed from the configuration file.
• Driver ROV support has been removed. Configuration files which enable ROV for a driver (i.e. TIRTOS.useUART = true; statements) will generate warnings during the configuration phase. While these will not terminate the build process, they should be removed if a warning-less build is desired.
• The GPIO driver callback function signature has changed & now has an integer parameter. Refer to the GPIO Driver Callbacks section below for more details.
• The Power management module for CC13xx/CC26xx devices has moved from the TI-RTOS kernel to exist as a TI-RTOS driver in TI-DRIVERS. Refer to the Power management section below for more details.
• A new middleware package has been created in the TI-DRIVERS component to store device & board independent libraries & software stacks. Content featured must not any dependencies other than TI-RTOS drivers. Refer to the TI Middleware sections below for more details.
• The FatFs module has been updated & moved from the TI-RTOS kernel to the middleware package. Refer to the FatFs module section below for more details.
• The CC13xx/CC26xx LCD driver has moved from TI-RTOS drivers to the middleware package. Refer to the CC13xx/CC26XX LCD driver section below for more details.
• The SimpleLink WiFi host driver for CC3100 & CC3200 devices has been updated & moved from TI-RTOS drivers to the middleware package in the TI-DRIVERS component. The TI-RTOS WiFi drivers (WIFICC3100.c/.h & WIFICC3200.c/.h) still remain with the other TI-RTOS drivers. Refer to the SimpleLink WiFi host driver section below for more details.

TI-DRIVERS

• Driver sources & libraries have moved into a separately versioned TI-DRIVERS component. Driver sources can be found in: <tirtos_install_dir>/products/tidrivers_<product_type>_M_mm_pp_bb (where product_type refers to the device family the TI-RTOS installation supports i.e. CC3200, MSP43x, etc).
• A new Config module was created for the TI-DRIVERS component with the purpose of providing (instrumented or non-instrumented) driver libraries. Existing configuration files must add the Config module by adding the following:

/* ================ TI-RTOS drivers' configuration ================ */
var driversConfig = xdc.useModule('ti.drivers.Config');

/*
 * Include TI-RTOS drivers
 *
 * Pick one:
 *  - driversConfig.LibType_NonInstrumented (default)
 *      Use TI-RTOS drivers library optimized for footprint and performance
 *      without asserts or logs.
 *  - driversConfig.LibType_Instrumented
 *      Use TI-RTOS drivers library for debugging with asserts and logs enabled.
 */
driversConfig.libType = driversConfig.LibType_NonInstrumented;
//driversConfig.libType = driversConfig.LibType_Instrumented;

• TI-RTOS driver documentation can now be found in the docs directory in the TI-DRIVERS component (<tirtos_install_dir>/products/tidrivers_<product_type>_M_mm_pp_bb/docs).
• Board files for TI-RTOS supported evaluation kits & launchpads have moved to the TI-DRIVERS component (moved from <tirtos_install_dir>/packages/examples/boards to <tirtos_install_dir>/products/tidrivers_<product_type>_M_mm_pp_bb/packages/ti/boards).
• Examples for all CC13xx & CC26xx variants (i.e. CC2650_4XS/5XD/7ID, CC1310_7XD, etc.) are now explicitly provided. Example board files in prior TI-RTOS releases would have include statements for device variant board files. This level of indirection has been removed & existing board files have been renamed & moved to the evaluation kit with the device variant (i.e. board files for the CC2650_4XS variant are in the CC2650DK_4XS/ directory).

TI Middleware

• A new TI Middleware module has been added to the TI-DRIVERS component (located in <tirtos_install_dir>/products/tidrivers_<product_type>_M_mm_pp_bb/packages/ti/mw). The purpose of this package is to provide device & board independent libraries & software stacks which only have dependencies on TI-RTOS drivers.
• A new Config module was created for the TI Middleware package to automatically provide middleware libraries to TI-RTOS applications. Existing configuration files must add the Config module by adding the following:

/* ================ TI-RTOS middleware configuration ================ */
var mwConfig = xdc.useModule('ti.mw.Config');

• The content in TI Middleware varies depending on whether it is supported by device family (i.e. some libraries maybe supported on CC13xx/CC26xx devices but not on CC3200). All libraries provided by TI Middleware are non-instrumented.

GPIO Driver Callbacks

• The GPIO driver callback function signature has changed & now has an integer parameter. When the callback is executed, the GPIO index of the pin which triggered the interrupt/callback is passed in through the integer parameter.
• The new API is as follows:

typedef void (*GPIO_CallbackFxn)(unsigned int index);

• Existing callback functions should be updated to take this parameter and ignore it if unnecessary.

FatFs module

• The FatFs module has moved from the TI-RTOS kernel to the middleware package. Existing projects which include FatFs headers need to update include paths to point to ti/mw/fatfs. Additionally, the configuration files must also be updated to point to the module in the middleware package. Source changes are as follows:

/* C source files */
#include <ti/sysbios/fatfs/ff.h>

/* Configuration files */
var FatFS = xdc.useModule('ti.sysbios.fatfs.FatFS');

Changes to:

/* C source files */
#include <ti/mw/fatfs/ff.h>

/* Configuration files */
var FatFS = xdc.useModule('ti.mw.fatfs.FatFS');

• FatFs has been updated to the R0.11a release.
• FatFs libraries are automatically added to applications via the middleware configuration module.

CC13xx/CC26XX LCD driver

• The CC13xx/CC26xx LCD driver has moved from TI-RTOS drivers to the middleware package. LCD libraries are automatically added to applications via the middleware configuration module, thus the middleware module must be added to the project's configuration file.
• Existing projects must update include paths to point to ti/mw/lcd. Source changes are as follows:

/* C source files */
#include <ti/drivers/lcd/LCDDogm1286.h>

Changes to:

/* C source files */
#include <ti/mw/lcd/LCDDogm1286.h>

Power management

CC32xx

• Support for DEEPSLEEP has been removed. Consequently, the “PowerCC3200_DISALLOW_DEEPSLEEP” constraint has been removed, the “PowerCC3200_DEEPSLEEP” state has been removed, and the “PowerCC3200_ENTERING_DEEPSLEEP” and “PowerCC3200_AWAKE_DEEPSLEEP” notification events have been removed.

• The reference power policy PowerCC3200_sleepPolicy() has been rewritten. The new policy uses the SYSTICK timer (ti.sysbios.family.arm.m3.Timer) while the CPU is active, and will re-sync and restart this timer upon wakeup from LPDS. The RTC timer (ti.sysbios.family.arm.cc32xx.Timer) is no longer used, and is no longer selected when the Power driver (ti.drivers.Power) is used.

CC13xx/CC26xx

• The TI-RTOS Power management module for CC13xx/CC26xx devices has moved from the TI-RTOS kernel (ti.sysbios.family.arm.cc26xx) to exist as a TI-RTOS driver in the TI-DRIVERS component. This relocation requires configuration, include path, & runtime API changes for existing projects.

Configuration changes

Previously Power was statically configured as other kernel modules are, via the application configuration (.cfg) file. Now that Power exists as a TI-RTOS driver module, configuration follows the same approach as for other drivers. This is accomplished via a structure definition in TI-RTOS board files. Board files in the new TI-RTOS release (e.g., “CC2650DK_7ID.c”) include a PowerCC26XX_config structure, with these default values:

const PowerCC26XX_Config PowerCC26XX_config = {
    .policyInitFxn      = NULL,
    .policyFxn          = &PowerCC26XX_standbyPolicy,
    .calibrateFxn       = &PowerCC26XX_calibrate,
    .enablePolicy       = TRUE,
    .calibrateRCOSC_LF  = TRUE,
    .calibrateRCOSC_HF  = TRUE,
};

The default settings choose the aggressive standby policy & enable it via .policyFxn & .enablePolicy respectively (as shown above). RCOSC calibration is enabled by default, due to setting .calibrateFxn to PowerCC26XX_calibrate() & setting .calibrateRCOSC_LF & .calibrateRCOSC_HF to TRUE.

To disable calibration the following changes should be made to the structure:

API changes

The Power APIs are very similar to those previously available in the kernel module, most changes relate to using standard C types. There are two new header files that must be used & some API signature changes as summarized in the following table. Yellow indicates a function signature change & gray highlights changes from enumerated types to standard C types:

Note: Return values for the following APIs have changed:

• Power_getTransitionLatency() return value is in microseconds.
• Power_setDependency() now has a void return.

Following the model set by other Power drivers, the ti/drivers/Power.h header file contains the standard interfaces for all devices (CC26xx, MSP432 & CC3200) & device-specific headers & implementations are found in the power subdirectory (e.g., ti/drivers/power/PowerCC26XX.h & ti/drivers/power/PowerCC26XX.c). Peripheral & domain resource identifiers now have a "PowerCC26XX_" prefix, as shown below:

Similarly, constraints & power event identifiers now have a "PowerCC26XX_" prefix, as shown below (a snip from the new header file):

SimpleLink WiFi host driver

• In prior TI-RTOS releases, the WiFi host driver was compiled with the TI-RTOS WiFi driver into a single library. These have been split, the TI-RTOS WiFi driver (WIFICC3100.c/.h) remains with the drivers while the SimpleLink WiFi host driver has moved to the middleware package. WiFi host driver libraries are automatically added to application via the middleware configuration module, the middleware module must be added to the project's configuration file.
• Existing projects must update include paths to point to ti/mw/wifi/cc3x00. Source changes are as follows:

/* C source files */
#include <simplelink.h>

Changes to:

/* C source files */
#include <ti/mw/wifi/cc3x00/include/simplelink.h>

• The WiFi host driver has been updated to the 1.1.0 SDK release. This SDK requires the network processor to be updated to 1.0.0.10.0 firmware.
• Applications are no longer required to call the VStartSimpleLinkSpawnTask() API as the spawn task is now created when calling the WiFi_open() API. A spawnTaskPri field was added to the WiFi_params structure so as to allow the spawn task priority to be changed in the project board file.

'configPkg' placement issue for IAR workbench users

• When using IAR workbench, the generated 'configPkg' directory has moved in some project environments. Some IAR projects will have to be modified.
• The 'configPkg' directory is now created in the same directory as the generated 'src' directory that is used to rebuild the kernel. The 'src' & 'configPkg' directories are placed next to the RTOS .cfg file.
• This was inconsistent in the earlier releases. If the path to the .cfg file was specified using Linux forward slashes, the 'configPkg' directory was created correctly (in the same directory as the .cfg file). But, if the path to the .cfg file used DOS backward slashes, the 'configPkg' directory was created in the project directory $PROJ_DIR$.
• This problem only occurs if the .cfg file is in a different directory than the project directory $PROJ_DIR$. This change should not be a problem for the common use case where the .cfg file is placed in the project directory $PROJ_DIR$.
  • Note that the examples provided with earlier releases of the project placed the .cfg file in project directory $PROJ_DIR$
• If you are affected by this change, you will need to make 3 changes to your IAR project. You need to change '$PROJ_DIR$/configPkg' to '<path to RTOS .cfg file>/configPkg'

update the path to compiler.opt.def

update the path to the linker .cmd file

update the path to the package.mak file (this is needed for 'clean' & 'rebuild' to work)