TI 15.4-Stack Software Development Platform — TI 15.4-Stack 0 documentation (2024)

Figure 3. Single Device and Coprocessor Configuration

Figure 4. TI 15.4-Stack Development System

Note

Specific documentation for detailed Linux example applications can befound in the ${linux_sdk_root}/doc folder after running the LinuxInstaller.The Linux installer requires an x86 64-bit machine running Ubuntu.

Installing the SDK¶

To install the SimpleLink CC13x0 SDK, run the installer:simplelink_cc13x0_sdk_1_30_00_xx.exe

The default TI 15.4-Stack install path is:

C:\ti\simplelink_cc13x0_sdk_1_30_00_xx\examples\rtos\CC1350_LAUNCHXL\ti154stack

(if using a CC1350) or

C:\ti\simplelink_cc13x0_sdk_1_30_00_xx\examples\rtos\CC1310_LAUNCHXL\ti154stack

(if using a CC1310).

In addition to TI 15.4-Stack code, documentation, and projects, installing theSDK also installs the TI-RTOS bundle and the XDC tools, if not alreadyinstalled. Table 1. lists the software and tools that aresupported and testedwith this SDK. Check the TI 15.4-Stack Wiki for the latest supportedtool versions.

Code Composer Studio¶

Code Composer Studio (CCS) provides a suite of tools that are used todevelop applications that run on TI’s MCUs and embedded processors. CCS containsmany features that go beyond the scope of this document—more information can befound on the CCS website. Check the CC13x0 SimpleLink SDK release notes tosee which CCS version to use.

The following describes installing and configuring the correct version of CCS and the necessary tools.

1. Download CCS 7.1 from the Download CCS wiki page.
2. Launch the CCS installer.
3. On the Processor Support menu (seeFigure 5.), expand SimpleLink Wireless MCUs andselect SimpleLink CC13xx and CC26xx Wireless MCUs

1. Click the Next button, then click the Finish button.
2. After CCS has installed, apply all available updates by selecting Help →Check for Updates.

Configure CCS¶

This section explains how to configure CCS for development and debugging. Italso provides information on useful CCS IDE settings (see Useful CCS IDE Settings)

Using CCS¶

This section describes how to open and build an existing project. The Sensorproject is used as an example. However, all of the CCS projects included in thedevelopment kit have a similar structure.

Importing SDK Projects¶

Launch the CCS IDE and prepare to import the TI 15.4-Stack projects from the installedSDK:

1. Select Project → Import CCS Projects

2. Select Select search-directory: and click the Browse… button.

3. Navigate to

   C:\ti\simplelink_cc13x0_sdk_1_30_00_xx\examples\rtos\CC1350_LAUNCHXL\ti154stack

   and click the OK button (see Figure 6.).If using CC1310, navigate to

   C:\ti\simplelink_cc13x0_sdk_1_30_00_xx\examples\rtos\CC1310_LAUNCHXL\ti154stack

4. The Discovered projects box now lists the projects that have been found.Select the Copy projects into workspace checkbox, click the Select Allbutton, and last click the Finish button to import a copy of each SDKproject into the workspace (see Figure 7.).

   Note

   In the following sections, the project names for the CC1310 andCC1350 platforms are referred to as CC13x0. Replace x with either 1 or 5 depending on the wireless MCU being used.

Workspace Overview¶

The workspace now contains all projects needed to build downloadable images. Thefollowing examples build a Sensor image, to produce a functional sensor device.

In the Project Explorer pane, click on the sensor_cc13x0lp project to makeit active. Click on the arrow to the left of the project to expand its contents,as shown in Figure 8..

In Figure 8., all folders (under thesensor_cc13x0lp project) except for sensor_cc13x0lp can beconsidered input folders, which contain source code files, header files, andconfiguration files used to compile and link the application. Thesensor_cc13x0lp folder contains output files, which include programmableimages and the linker map.

Compiling and Linking¶

All example projects in the SDK are ready to build out-of-the-box meaning theyare preconfigured for use with a specific target board, in this case the CC13x0 LaunchPad.To build a Sensor Application image that is ready to program onto a LaunchPadboard, select Project → Rebuild Project. The Console pane of the IDEdisplays the individual results of source file compilations, followed by thelinker results, as shown in Figure 9..

In Figure 9., the output foldersensor_cc13x0lp is populated with results from a successful build of theSensor Application. Two programmable output files have been produced,sensor_cc13x0lp.out and sensor_cc13x0lp.hex, along with a detailedlinker map file, sensor_cc13x0lp.map.

Downloading Hex Files¶

As shown in Compiling and Linking, the CCS linker produces .hex filesthat are readyfor direct download to the target hardware. The hex image can be downloaded to atarget device by a stand-alone tool, such as the SmartRF Flash Programmer 2,shown in Figure 10..

As shown in Figure 10., SmartRF Flash Programmer 2 canbe used to program the prebuilt hex file using the Flash image(s) → Singlefeature. Use the Browse… button to select the following files:

\examples\rtos\CC1350_LAUNCHXL\ti154stack\hexfiles\default\sensor_default.hex

After connecting a CC13x0 LaunchPad target board to one of the USB ports ofthe PC, the XDS110 instance becomes listed in the Connected devices panel.Select the listed device by clicking on the CC1310 icon. Programming theCC13x0 LaunchPad is accomplished through the following sequence (seeFigure 10.).

1. Select the Erase action, using the Pages in image option.
2. Select the Program action, using the Entire source file option.
3. Select the Verify action, using the Readback option.
4. Press the Play button (blue icon at the lower right corner of the Actionspanel).
5. Observe the device programming feedback in the Status panel. It showsSuccess! when finished.
6. Exit the SmartRF Flash Programmer 2 and power cycle the LaunchPad to run theapplication.

Debugging¶

When debugging is necessary, .out files produced by the linker are downloadedand run from the CCS IDE. The following procedure would typically be used to debug the program.

Continuing with the Sensor example project, the compiled program can bedownloaded to the target and a debug session initiated by selecting: Run →Debug on the IDE, as shown in Figure 11..

In Figure 11., the IDE has switched from the CCSEdit perspective to CCS Debug and shows the program counter stopped at main().From this starting point, the developer can single-step through sourcecode, set and run-to breakpoints, and run the program using icons at the top ofthe display. During a debug session, the user can switch between the CCS Editand CCS Debug perspectives, as necessary, to view project files and performdebugging operations.

Useful CCS IDE Settings¶

The CCS provides a large number of configurable settings that can be used tocustomize the IDE and individual projects. The following examples do not alterthe generated program code, but they can improve the developer’s experience whenworking with CCS projects. The CCS can reduce project compilation time by takingadvantage of multiple processor cores on the development computer.

To use this feature, navigate to Project → Properties → Build → Behaviorand select Enable parallel build, as shown in Figure 12..

CCS users can control the amount of information that is displayed in the Consoleportion of the screen during project compilation and linking, ranging fromVerbose to Super quiet. To change this setting, navigate to Window →Preferences → Code Composer Studio → Build and select an entry from theConsole verbosity level drop-down, as shown inFigure 13.

Figure 14. Predefined Symbols Pane

Figure 15. Software Architecture

Using Nonvolatile Memory¶

Thetion NV area of flash is used for storing persistent data for the application.TI 15,4-Stack provides two implementations of NV. One uses one page of internalflash, while the other uses two. By default example applications use one pageNV. For more information on one page NV please refer to nvocop.c whichdescribes the implementation details. Also nvoctp.c describes the implementationdetails of the two page NV. The last page in flash is the CCA page, dependingon whether one page or two page NV is used one or two pages before the last page (CCA)are defined as the NV area. The example projects use theNV driver with the API defined in nvintf.h.

The NV driver is set up in main.c:

#ifdef NV_RESTORE /* Setup the NV driver */ NVOCTP_loadApiPtrs(&Main_user1Cfg.nvFps); if(Main_user1Cfg.nvFps.initNV) { Main_user1Cfg.nvFps.initNV( NULL); }#endif

Then the applications use the function pointers in Main_user1Cfg to call the NVfunctions defined in nvintf.h:

//! Structure of NV API function pointerstypedef struct nvintf_nvfuncts_t{ //! Initialization function NVINTF_initNV initNV; //! Compact NV function NVINTF_compactNV compactNV; //! Create item function NVINTF_createItem createItem; //! Delete NV item function NVINTF_deleteItem deleteItem; //! Read item function NVINTF_readItem readItem; //! Write item function NVINTF_writeItem writeItem; //! Write existing item function NVINTF_writeItemEx writeItemEx; //! Get item length function NVINTF_getItemLen getItemLen;} NVINTF_nvFuncts_t;

The following is an example of a write from csf.c:

static void updateDeviceListItem(Llc_deviceListItem_t *pItem){ if((pNV != NULL) && (pItem != NULL)) { int idx; idx = findDeviceListIndex(&pItem->devInfo.extAddress); if(idx != DEVICE_INDEX_NOT_FOUND) { NVINTF_itemID_t id; /* Setup NV ID for the device list record */ id.systemID = NVINTF_SYSID_APP; id.itemID = CSF_NV_DEVICELIST_ID; id.subID = (uint16_t)idx; /* write the device list record */ pNV->writeItem(id, sizeof(Llc_deviceListItem_t), pItem); } }}

The following is an example of a read from csf.c:

bool Csf_getNetworkInformation(Llc_netInfo_t *pInfo){ if((pNV != NULL) && (pNV->readItem != NULL) && (pInfo != NULL)) { NVINTF_itemID_t id; /* Setup NV ID */ id.systemID = NVINTF_SYSID_APP; id.itemID = CSF_NV_NETWORK_INFO_ID; id.subID = 0; /* Read Network Information from NV */ if(pNV->readItem(id, 0, sizeof(Llc_netInfo_t), pInfo) == NVINTF_SUCCESS) { return(true); } } return(false);}

The NV system is a collection of NV items. Each item is unique and have thefollowing pieces to it (defined in nvintf.h).:

/*** NV Item Identification structure*/typedef struct nvintf_itemid_t{ //! NV System ID - identifies system (ZStack, BLE, App, OAD...) uint8_t systemID; //! NV Item ID uint16_t itemID; //! NV Item sub ID uint16_t subID;} NVINTF_itemID_t;

System Stack¶

Besides the RTOS and ICall heaps previously mentioned, there are other sectionsof memory to consider. As described in TI-RTOS Overview, each task hasits ownruntime stack for context switching. Furthermore, another runtime stack is usedby the RTOS for main(), HWIs, and SWIs. This system stack is allocated in theApplication linker file, to be placed at the end of the RAM of the Application.

For CCS, the RTOS system stack is defined by the Program.stack parameter in theapp.cfg RTOS configuration file.

/* main() and Hwi, Swi stack size */Program.stack = 1280;

Then the RTOS system stack is placed by the linker in the RAM space of theApplication::

/* Create global constant that points to top of stack *//* CCS: Change stack size under Project Properties */STACK_TOP = stack + STACK_SIZE;

Dynamic Memory Allocation¶

The system uses two heaps for dynamic memory allocation. It is important tounderstand the use of each heap so that the application designer maximizes theuse of available memory. The RTOS is configured with a small heap in the app.cfgRTOS configuration file.

var HeapMem = xdc.useModule('xdc.runtime.HeapMem');BIOS.heapSize = 1724;

This heap (HeapMem) is used to initialize RTOS objects as well as allocate theTI 15.4-Stack task runtime stack. This size of this heap has been chosen to meetthe system initialization requirements. Due to the small size of this heap, TIdoes not recommend allocating memory from the RTOS heap for general applicationuse. For more information on the TI-RTOS heap configuration, refer to the HeapImplementations section of the TI-RTOS SYS/BIOS Kernel User’s Guide.

Instead, a separate heap must be used by the Application. The ICall modulestatically initializes an area of Application RAM, heapmgrHeapStore, which canbe used by the various tasks. The size of this ICall heap is defined by thepreprocessor definition of the Application HEAPMGR_SIZE, and is set to 0 bydefault for the Collector and Sensor projects; a value of 0 means that allunused RAM is given to the ICall heap. Although the ICall heap is defined in theApplication project, it is also shared with the TI 15.4-Stack APIs whichallocate memory from the ICall heap. To manually change the size of the ICallheap, adjust the value of the preprocessor symbol HEAPMGR_SIZE in theApplication project to a value other than 0.

To profile the amount of ICall heap used, define the HEAPMGR_METRICSpreprocessor symbol in the Application project. Refer to heapmgr.h inComponents\applib\heap for available heap metrics. The following is an exampleof dynamically allocating a variable length (n) array using the ICall heap.:

//define pointeruint8_t *pArray;// Create dynamic pointer to array.if (pArray = (uint8_t*)ICall_malloc(n*sizeof(uint8_t))){ //fill up array}else{ //not able to allocate}

The following is an example of freeing the previous array.:

ICall_free(pMsg->payload);

A Note on Initializing RTOS Objects¶

Due to the limited size of the RTOS heap, TI strongly recommends that usersconstruct and not create RTOS objects. To illustrate this recommendation,consider the difference between the Clock_construct() and Clock_create()functions. Listing 1. shows the definitions of thesefunctions from the SYS/BIOS API.

// Allocate and initialize a new instance object and return its handleClock_Handle Clock_create(Clock_FuncPtr, UInt timeout, \ const Clock_params *params, Error_Block *eb);// Initialize a new instance object inside the provided structureVoid Clock_construct(Clock_Struct *structP, Clock_FuncPtr clockFxn, \ UInt timeout, const Clock_Params *params);

By declaring a static Clock_Struct object and passing this object toClock_construct(), the .DATA section for the actual Clock_Struct is used, notthe limited RTOS heap. Conversely, Clock_create() causes the RTOS to allocateClock_Struct using the limited heap of the RTOS. As much as possible, thismethod is how clocks and RTOS objects in general, should be initializedthroughout the project. If creating RTOS objects must be used, the size of theRTOS heap may need to be adjusted in app.cfg.