Indigresso Wiki

Open Source Stuff for DASH7

User Tools

Site Tools


opentag:tools:ccs

TI Code Composer Studio (CCS)

Code Composer Studio from Texas Instruments is an embedded toolchain, based on Eclipse, that is supplemented with code libraries, cross-compilers, debuggers, simulators, and other such tools for common TI processors. For usage with OpenTag, the most common target processors that CCS would be used with are the TI CC430 and other MSP430 MCUs. TI's ARM product line is not focused on low-power and therefore not as well-suited to OpenTag as some other ARM product lines from other manufacturers.

More Information

TI keeps its own CCS wiki, which is recommended reading for anyone interested in CCS.

Versions

There are three versions of CCS that users may encounter. CCSv4 and v5 are “officially supported” versions, and CCSv5 is highly recommended over CCSv4.
CCSv3: Old version (not Eclipse-based), not officially supported by OpenTag.
CCSv4: Previous version, officially supported by OpenTag.
CCSv5: Current version, officially supported by OpenTag.

Running CCS via Virtualization

In case you are curious about what emulation tools work with CCS over Windows, I will give you my experience. Contact me if you have more datapoints.

Host OS Virtualization Result Notes
Mac OS X Parallels 7 No issues Best overall performer
VMWare Fusion 2 No issues
VMWare Fusion 3 No issues
VMWare Fusion 4 No issues
wine (via X11) Crashes immediately

Configuring CCS for OpenTag

Downloading the Code

The first thing you need to do to use OpenTag with CCS is to download the OpenTag code and the associated CCS project files. Most “official” OpenTag apps have CCS v4 or v5 project files (every app that works on CC430 has a CCS project file). OpenTag download instructions are available on the Archives Page.

Preparing The Project on Your System

CCS works only with Windows, so I'm going to safely assume you are using a Windows system. It is now important to configure the CCS Project to find the code in the right place. There are two ways to do this.

Method 1: Map a Lettered-Drive to OpenTag

Quickstart: Map the OpenTag_M2 code directory to Drive B
This is the easiest way. Projects use Drive-B, which is usually quite safe to use considering that there are almost no floppy disks any more. If you are storing the OpenTag codebase on a networked disk, then Windows can easily map this directory to Drive-B. If you are storing the OpenTag codebase on your filesystem, then you will need something like Virtual Clone Drive.

Method 2: Change the Project Settings

If you cannot map the Drive B, then you can change the project to find the files wherever you put them. This will take more time, and it is not recommended. If CCS actually worked the way it was supposed to, then relative linking would work, and there would be no need for any of this. Needless to say, CCS doesn't work properly. This is a problem for CCSv4 and also CCSv5. Relative linking simply does not work reliably in CCS.

Step 1: Modify the Project File

Navigate to the project folder (named “proj_CSSv4” or “proj_CSSv5”) within the application folder. There should be some additional folders inside this, named after the project variations. Go inside each of these project-variation folders and find the file named “.project”. It might be invisible, but it is there. Open it, and do a search-replace.

Search Replace in .project File
“B:/” → YOUR_ROOT_DIRECTORY
That is, change the “B:/” mapping to wherever in the filesystem you have stored the OpenTag_M2 directory.

Step 2: Verify/Modify the Project Linked Resources

Run CCS and open the project you are interested in building. It should load, and you will see a list of directories and files on the left of the screen, in the “Project Explorer” section.

Right-Click on the top-level Project Variation you want to build, and select “Properties.” A new box will appear. Navigate to Resource → Linked Resources, and click on the “Linked Resources” tab. It should look something like the image below. Make sure that the links are to the correct places in your file system. Use the Path Variables at your own risk (see commentary below, in the “Fiddling with Linked Resources” paragraph).

Step 3: Set Include Options

In the same Properties box as before, navigate now to CCS Build → MSP430 Compiler → Include Options. For each Configuration Type (in the top pulldown), you will need to configure the include directories in the bottom frame to the correct locations. In your filesystem, they are probably different than in the example image below. Once you have corrected all of the include directories, you can select all the lines in the frame, copy them, and then paste them into the other Configurations.

Step 4: Flush Old Builds

In the Project Explorer, find any directories that are called “Debug” or “Release” (or anything similar to those) and delete them.

Note: Using Relative Paths Instead of Drive Mapping

You may have seen guides such as this one or this one (PDF) that demonstrate methods for using relative paths in the project file via a macros.ini file. TI recommends (and almost enforces) that shared projects use relative paths, but I have found that CCS is unreliable with relative paths. In fact, I've never actually managed to get relative paths to work, even when following the guides linked above to the letter. You can try fiddling with relative paths and the macros.ini, if you want.

Using the Command Line

It appears directly specifying relative include paths works for cl430.exe: The CWD (current working directory) is ${PROJECT_LOC}/Debug (if your active configuration is Debug). So for example you can try include search path “../../../../../OTlib”.

Fiddling with Linked Resources

You can try removing hard-coded paths in Project Properties → Resources → Linked Resources → Linked Resources tab. Sometimes, this works, but not always. In this setup, all locations should have root of Path Variable (i.e. not drive letter), with path variable inheriting ${PROJECT_LOC}. ${WORKSPACE_LOC} could be outside of source tree. Some sources have reported that this works, but others report that it does not.

Using CCSv4

There is a large amount of user documentation for CCSv4 on TI's wiki, and this article will not replicate that documentation. However, it will describe how an OpenTag project is represented in CCSv4, and what you need to do to build and load a project onto a supported device (generally a CC430).

The Editor Screen

When you open up a project, the first thing you see is an editor screen for C/C++ editing (no C++ will touch OpenTag, though). You can move the window frames around, but generally they will be arranged much like the example below. Make sure that you can click on the folders in the “C/C++ Projects” window frame, and that the files inside the folders are displayed. If you cannot get the files to display in the folders, there is something wrong with your project configuration (make sure to set up the “B” drive, etc).

The Debugger Screen

When you successfully build a project, click on the icon in the toolbar that looks like a green bug to load the firmware to the microcontroller and launch the debug screen. Again, the TI wiki has plenty of information on how to use this, but here are a few tips:

  • You can set and clear breakpoints during live debugging
  • The Right-click menu has an option called “Run To Line.” This is a great feature. It will run your program until it reaches the line in the code where cursor is.
  • One of the best way to make sure your program is doing the right things is to probe the memory.
    • Open the “Memory” window frame and enter a hex base address in 0x… form to go to a place in memory.
    • When code changes a value in memory between pauses, it will mark the address in red.
    • Open the “Disassembler” window frame and step through the code to find the addresses of variables that you want to monitor (you can plug these into the Memory window).

Build Properties

In the Project menu, there is a “Properties” option. If you open Properties, you will see a window that is full of sub-properties. Really, the only one that matters is the “C/C++ Build” sub-option. The rest of the sub-options might be fun to play with, but they are not critical to understand (the defaults are fine).

The “C/C++ Build” options are the kind of things that you would write into a makefile, except they are presented in GUI form. Of particular note are the options below:

Tool Settings → MSP430 Compiler → Basic Options
You can fiddle with the compiler optimization settings here. OpenTag is pretty heavily optimized at the code level, so I would advocate going for speed optimization over size optimization, where you will get more benefit.

Tool Settings → MSP430 Compiler → Include Options
If you are having trouble because the compiler is not finding your include files, make sure to update the include paths here.

Tool Settings → MSP430 Compiler → Runtime Model Options
You can enable some compiler tricks and errata workarounds here. As far as I know, all the CC430 errata are dealt with manually in the OpenTag codebase. However, you can safely enable the –small-enum option.

Tool Settings → MSP430 Compiler → Optimizations
I would leave this stuff alone for the debug builds, but for release builds you can shave-off a little bit of build size and improve runtime performance a tiny bit by enabling some of these specific optimizations.

opentag/tools/ccs.txt · Last modified: 2012/06/11 19:14 by jpnorair