In software development projects for embedded systems, there is quite commonly the need to create a single project that builds related versions of the application for different target hardware/memory configurations, with different build options, etc. In large-scale projects, there is also the need to organize files in a structure that is easily navigated and maintained by multiple team members.
The CCS IDE is a flexible development environment that allows you to (among other features):
This section discusses the project model used by CCS. It covers how to create, organize and configure projects to help you handle different versions of your applications.
This section provides an overview of workspaces and projects, and the types of projects supported by CCS.
All work in CCS is based on projects, which are typically a collection of files and folders. Projects are stored and organized in workspaces.
A workspace is the main working folder for CCS and contains information to manage all the projects defined to it.
When CCS is launched, it will prompt for the workspace folder location. To avoid being prompted in the future, you can enable the option to use the selected folder as the default folder.
After it launches, the CCS Edit perspective will be visible by default. This perspective contains views most commonly used during code development, such as the Project Explorer, Editor and Problems view.
The default location of new projects will be within the workspace folder. Once a project has been added to the workspace, it will be visible in the Project Explorer view.
The workspace folder also stores user information such as user interface preferences and settings.
Workspaces are user specific, hence typically not checked into source control or shared between users. Instead, projects are checked into source control and each user would have their own workspace that references the projects.
It is possible to have multiple workspaces. Only one workspace is active at a time in Code Composer Studio but you can switch workspaces using the menu File → Switch Workspace….
It is advisable to periodically clean your workspace as they could get corrupted over time. Before cleaning, if there are workspace settings you’d like to preserve, you can save the current workspace settings so they can be imported into the new workspace. Projects will have to be re-imported after cleaning the workspace.
To see a video demo of how to save/import workspace settings, check the References section.
Although it is the recommended method, not all settings are preserved using the above method. Another way of saving all preferences is to copy over the ‘.metadata.plugins\org.eclipse.core.runtime.settings’ folder into the new workspace. This is only recommended if you are using the same version of CCS as was used with the older workspace.
To delete a workspace, simply delete the workspace folder from the file system. Note that this will also delete all projects contained within that workspace.
Deleting a workspace does not automatically remove it from the list of recent workspaces displayed by CCS during launch. To delete workspaces from the recent workspace list:
A project stores all the information needed to build an individual program or library, including:
Projects typically contain files and folders. Similar to the workspace, a project maps to a physical folder in the file system. When a new project is created, its default location is in a subfolder (of the project name) within the workspace folder. However you can also choose a folder outside the workspace.
Once the project is created, a reference to it will be made in the workspace and the project will be visible and available for use from the Project Explorer view. Each project in the workspace must have a unique name.
Projects are either open or closed. When you create or import a project into the workspace it is automatically open. Multiple projects can be open simultaneously.
When you close a project, it is still defined to the workspace, but it cannot be modified by the Workbench. The resources of a closed project will not appear in the Workbench, but the resources still reside on the local file system. Closed projects require less memory and are not scanned during routine activity. Hence closing unnecessary projects can improve performance of CCS. Closed projects are still visible in the Project Explorer view with a ‘closed’ folder icon, so they can be easily opened when needed.
To open or close a project:
The Project Explorer view displays all projects that are part of the active workspace. The view is mostly a representation of the file system of the project folder. When you create a subfolder and move files to that subfolder from within the Project Explorer view, the actual filesystem is being altered. Similarly, changes made to the filesystem will be reflected in the Project Explorer view.
Note that not all files that appear in the view will exist in the filesystem and vice versa. Linked files will appear in the view but because they are references and not actual copies, they will not appear in the actual filesystem. The ‘Binaries’ and ‘Includes’ folders that appear in the Project Explorer view also are just references. The ‘Binaries’ folder points to the executable file in your active build configuration sub-folder (example, ‘Debug’).
The screenshot below shows the contents of the ‘c6748_sinewave’ project in the Project Explorer view and how it maps to the physical project folder in the workspace in Windows Explorer. Note how the CCS generated project files (.ccsproject, .cproject, .project) and .settings folder shown in Windows Explorer are hidden in the Project Explorer view and how the ‘Binaries’ and ‘Includes’ folders in the Project Explorer view do not exist in Windows Explorer. Otherwise the rest of the folders and files are structured the same in the Project Explorer view and Windows explorer.
The Project Explorer view can be customized to show/hide various file types to reduce clutter in the view.
Code Composer Studio supports a few different types of projects. The project type can be specified when creating a new project. The project type will determine the toolchain and settings that the build interface will use and display.
For more information on standard Eclipse C/C++ Projects and Makefile projects, refer to the Eclipse online documentation.
This section covers the steps for creating, importing and working with projects.
The steps below describe how to create new projects for the different types of projects supported by CCS.
To create a new CCS project, follow the procedure in the relevant section in the Getting Started chapter.
The general steps for creating a new managed make or standard make C/C++ project are described in the Eclipse online documentation at this link.
The general steps for creating a makefile project are described in the Eclipse online documentation at this link.
CCS supports two methods of adding source files and/or folders to projects. You can either add files or link files.
When you add a file/folder to a project, it is physically copied to the root location of the project directory.
When you link a file/folder to a project, the project will create a reference to the file/folder in the file system instead of copying it into the project directory. Linked files appear in the CCS Project Explorer view with a special icon as shown below.
All files contained in a project (either copied or linked) will be included in the project build unless specifically excluded. To exclude a file from build, refer to Exclude files from build.
To copy or link files to a project, either:
If you use either of the first two methods, the dialog will prompt you to select whether to Copy files or Link to files.
If you choose Copy files, the files will be copied into the project directory.
If you choose Link to files, the files will be linked. You can set the link location to be either an absolute path or a path relative to a path variable. For projects that will be shared among multiple users, use relative link paths as described in the Portable Projects page.
To see a video demo of how to add files to a project, check the References section.
To copy or link folders to a project, either:
If you find that the Link to files is not working as expected (for example, the file does not appear in the Project Explorer view after the selection), check that your Drag and Drop Settings has Enable linked resources enabled.
Since linked files actually reside in a location outside the project folder, be aware that editing these files will modify the file not only for the current project but also for any other project that links to the same file. This is especially important when working with TI software packages and SDKs that may share source files among multiple projects.
To archive a copy of all source files that are part a project (whether copied or linked) so they can be saved to a code repository or shared with another user, you can export the resources to an Archive file.
The resulting archive file will contain a copy of the selected resources.
Note that when the archive is imported into another workspace, all the resources (including linked resources) will be extracted into the root project folder instead of preserving the original directory structure for the linked files. So this technique allows you to export/share resources, however it will not recreate exactly the original build environment upon import.
A more common scenario than creating a new project is to work with an existing project. This could be either your own development project or an example project provided by TI. In this case, you must first import the project into CCS.
CCS can import projects that are created with the same version or older versions of CCS, including legacy CCSv3 projects. However, bear in mind that the greater the variance in CCS version used to create the project vs. version used to import the project, the more error-prone the import process could be.
There are a few different methods of importing projects, depending on the type and source of project.
Import TI Example Projects Using Resource Explorer (recommended whenever possible):
Resource Explorer (in CCS versions 7 and higher) helps you browse examples for your chosen platform, download software packages and import projects all from within a single interface. Projects imported using Resource Explorer will be inherently copied to workspace.
More information on Resource Explorer is available here. Also refer to this section in the Getting Started chapter .
To import a project from Resource Explorer:
Note: If the software package containing the example has already been downloaded and installed, the project will import. Otherwise you will be prompted to install the software package first, after which the project can be imported.
Import TI Example Projects Using Resource Explorer Classic (Legacy):
If you are using CCS 5.2+ to CCSv6, you may be interested in this import method. The Resource Explorer interface in these older CCS versions is different than the one in CCSv7 and higher. You cannot download software packages from this interface but you can still browse and import example projects from older software packages (like TI-RTOS, ControlSuite etc) if it is already installed on your machine.
This Resource Explorer interface (now called Resource Explorer Classic) is still included in CCSv7 and v8 but is not recommended for use with newer software packages. Also note that Resource Explorer Classic is not available in CCSv9 and higher.
More information on Resource Explorer Classic is available here.
To import a project from Resource Explorer Classic:
Import a CCS Project (other than CCSv3 project):
To import a CCS project using the CCS menu, please refer to the relevent section in the Getting Started chapter.
Import a Standard Eclipse C/C++ Project (not recommended for CCS projects):
Import a Legacy CCSv3 Project:
A more detailed reference is available here.
Refer to the Troubleshooting section for information on resolving common project import errors.
The CCS variable PROJECT_ROOT is set to the project’s root folder (the folder that contains the .*project files) by default. When a project is imported (with the “Copy project into workspace” checkbox enabled), CCS will create a new variable/macro named ORIGINAL_PROJECT_ROOT whose value is set to the original project’s root directory.
If the original project specifies the macro $ in any paths such as compiler include paths, it will be replaced with $ in the imported project. This is done because the project may still need to reference resources whose paths are set up relative to the original project location.
Many projects are structured such that the include files reside in a common folder and several projects can use/reference the same set of common include files. Several TI software packages such as TivaWare, C2000Ware are also set up this way. When projects from these packages are imported and copied to workspace, the include folders are not necessarily copied over. So, if the original project has compiler include paths set up relative to the variable PROJECT_ROOT, those paths will be converted to use ORIGINAL_PROJECT_ROOT after project import, so the include files are still correctly referenced relative to the original project.
In your custom project, if you wish to specify include paths to always be relative to the “current” project directory rather than the “original” project directory, use the variable ProjDirPath instead of PROJECT_ROOT.
To rename a project that is open in the Project Explorer view:
To make a copy of a project that is already imported and open in the Project Explorer view:
The copy process will copy over the files/resources from the original project folder into the copied project folder. However, if the project contains linked resources they will still point to their original location. It is the user’s responsibility to check if the project references linked files/resources from another location before directly editing such files. Refer to this section on linked files for more information.
To delete a project that is in the Project Explorer view:
The structure of a project is important when there is a need to share a project with another user or to facilitate having multiple users working on the same project at the same time. The most common use cases for sharing projects are discussed here.
In addition to creating projects without any absolute paths, other things to consider if the project needs to be portable across OS:
The Eclipse framework (and by extension, CCS) provides a lot of flexibility for organizing and navigating your project resources. Some of the features are described here.
Working sets are used to group elements for display in views or for operations on a set of elements.
You can use working sets to restrict the set of resources that are displayed in the Project Explorer view. If you select a working set in the view, only resources, children of resources, and parents of resources contained in the working set are shown.
This is useful if you have a large number of projects in the view but wish to work on only on a sub-set of them at a given time.
To create a working set:
To see a video demo of how to use working sets, check the References section.
Virtual folders are folders that exist only in the CCS workspace tree, and have no file system location. By using virtual folders, files and folders can be organized in a project hierarchy that is independent of their location in the file system.
Regular file and folder resources can not be created under a virtual folder. Only other virtual folders or linked resources can be created directly under a virtual folder.
To create a virtual folder:
You can now link files to the virtual folder.
To see a video demo of how to use virtual folders, check the References section.
CCS provides a lot of flexibility when it comes to project configuration and management.
There are many settings that define the properties of a project, such as the toolset used for the build, compiler and linker build options, project dependencies and environment variables, to name a few. These settings can be viewed and customized through the Project Properties. This section describes the more commonly used settings for a project.
To view and customize General Properties, right-click on a project and go to Properties, then click on General in the left pane.
The Project tab in the right pane (previously named Main in CCS 7.3 and lower versions) contains the following:
For more information on Linker command file and Runtime support library, see the articles Linker command files and Runtime support library.
The Output format field determines the format of the executable (.out).
The Compiler version field shows the version of compiler tools being used for the build. If the project imported into CCS was originally created with a version of compiler tools different than what is installed in your machine or what CCS is set to use, CCS will let you know that the version used for build is different than the original version. This information will be displayed in the Compiler version field as shown below.
The Products tab in the right pane (previously named RTSC in CCS 7.3 and lower versions) contains the following:
For RTSC/TI-RTOS based projects, it also contains:
The Target field is automatically populated based on the Device Variant selected in the Project tab.
The Platform field is selectable by the user based on the target board. It is usually auto-populated for example projects.
The Build-profile field shows which RTSC and SYS/BIOS libraries the configuration build should link in. The selection applies compile options to the C file generated when building the RTSC configuration (.cfg). Note that this is different from the compile options selected under Compiler Properties that apply to the user source code. For example, if you choose the release RTSC profile, a -O2 optimization option may be added to the build, while for the debug RTSC profile, there would not be a -O2 optimization option. Building with release is a good choice as the RTSC and SYS/BIOS runtime functions will be faster and will use less code memory. Building with debug makes the build faster, but the runtime application will be less efficient.
To view and customize Build Properties, right-click on a project and go to Properties, then click on Build in the left pane. The right pane will display several tabs. The settings in each tab are described below. More details on these settings and their usage come in later sections.
Builder: Defines the build command, makefile generation and a few other build settings.
Most users will not need to adjust the default settings under Builder and Makefile generation. These are set to use the default build command and to generate makefiles automatically.
Advanced users may wish to customize the gmake command or even use a different make utility.
See Changing the make utility if you wish to use a make utility other than the default gmake.
The Stop on first build error check box controls whether the build should stop immediately after the first build error or not. By default, this box is unchecked. This passes the -k (–keep-going) option to gmake that tells it to “keep going” or continue with the build as much as possible after an error. If this box is checked, the -k option will go away and the build will stop at the first build error.
Note that even if this box is checked, it will still finish building the current source file and report all the errors found in that file. However, it will not continue with building other source files. In addition, if the Enable parallel build option is enabled, more than one source files may begin building concurrently, in which case the build will stop after all of those files are completed. Removing the -k option may be desired if using a custom build step.
The Enable parallel build setting is enabled by default and takes advantage of PCs with multiple cores to run parallel builds, thereby speeding up the build time. See the section Parallel builds for more details.
Validator: Sets level of adherence to different tools versions.
This tab is visible in CCS 7.4 and higher. This setting configures the criticality of tools version mismatches. This is useful if you want strict control over which version of compiler and other products are to be used for project build.
Steps: Pre-build and Post-build steps.
Pre-build steps are steps that run before the main project build takes place.
Post-build steps are steps that run after the main project build takes place.
See Pre and Post Build Steps for more information.
Variables: Displays Build variables.
Enabling Show system variables shows all system level and built-in variables, otherwise only project level variables are shown.
Build variables can be used in compiler and linker build options, for example, to specify paths to include files or libraries relative to a build variable.
See Portable Projects for more information on build variables.
Environment: Defines environment variables.
Link Order: Defines the order in which files are passed to the linker.
If you need strict control over the linking order you can add the required files here and control the order in which they get passed to the linker.
Dependencies: Defines dependencies between projects, allowing referenced projects to be built before dependent project.
See Project Dependencies for more information.
In CCS 7.3 and lower, the Behavior tab defined build settings and workbench build behavior. In CCS 7.4 and higher these settings moved into the Builder tab.
Under the Build category there are several sub-categories:
Compiler/Linker: Compiler and Linker options
There are several compiler and linker options available to control your build. The list of options is too vast to go into detail here. Refer to the Compiler and Assembly Language Tools Users Guides for details on the options supported by the compiler and linker respectively. In the CCS Build Properties dialog, these options are categorized into groups for easy identification. You can drill down into the Compiler and Linker sections in the CCS GUI to access all of the available options.
Compiler and linker flags can also be added or removed directly via the Edit Flags button.
Hex Utility: Hex utility options
The Hex Utility can be enabled and invoked as part of the build in CCS. By default, the Hex Utility is disabled for a new CCS project. Once enabled, there are several options available. Refer to the Assembly Language Tools Users Guides for details on the options supported by the Hex Conversion Utility.
Hex utility flags can also be added or removed directly via the Edit Flags button.
For additional information on the Hex Utility integration into CCS, refer to the Hex Utility in CCS page.
XDCtools: XDCtools options
Refer to the SYS/BIOS Users Guide for supported options.
There are some advanced project settings that give the user control over features such as Code Analysis, Indexer, Code Style and others.
To view and customize these advanced settings, right-click on a project and go to Properties, then click on Show advanced settings at the bottom of the left pane. The C/C++ General selection allows access to these settings.
Some of the more commonly using setting, such as Code Analysis and Indexer, are described in more detail in the subsections below. For more information on the other settings, please refer to the the Eclipse CDT documentation.
This is the built-in static code analyzer that comes with Eclipse CDT that reports on programming errors, syntax and semantic errors, etc. The default settings are set at workspace level, but can be configured at either workspace level or project level.
The settings can be accessed from Project Properties → C/C++ General → Code Analysis. Make sure to click on Show advanced settings at the bottom left corner of the dialog for this setting to become visible.
By default, Code Analysis checks are internally disabled for CCS projects.
The reason they are disabled by default is that the rules defined in the Eclipse static analysis tool are somewhat different than those defined by the TI tools. Users who are typically developing for TI embedded parts using TI compiler tools are more interested in the errors reported by the TI tools rather than the generic Eclipse CDT errors. To avoid confusion between the two sets of error checks, code analysis checks are disabled.
To confirm that code analysis is disabled, go to Project Properties → C/C++ General → Code Analysis → Launching, and observe that the “Run with build” and “Run as you type” boxes are unchecked.
If you click on Apply or Apply and Close in the Code Analysis dialog, it will turn on code analysis. This may trigger syntax and programming errors. If errors are reported only in the Problems view and CCS editor margins but not in the CCS build console, then they are likely coming from Eclipse CDT and not from TI compiler tools, hence do not impact the build.
Another way to confirm the source of the error is to look at the Type field in the Problems view.
If the Type is C/C++ Problem, it is coming from the TI build tools.
If the Type is Semantic Error or Syntax Error it is coming from the Eclipse Code Analysis tool.
If code analysis checks were inadvertently turned on for a project, use the following steps to turn it off again so the errors in the editor no longer appear:
To leave code analysis on but disable or customize individual settings, select the specific item and click on Customize Selected.
This is the built-in Eclipse parser. It parses source and header files in the project to create a database that provides the basis for C/C++ search, navigation features and content assist (code completion).
To configure or disable the indexer (at workspace level), go to menu Window → Preferences → C/C++ → Indexer. Make sure to click on Show advanced settings at the bottom left corner of the dialog for this setting to become visible.
The default settings are set at workspace level, but can be configured at either workspace level or project level (by enabling the checkbox highlighted below).
By default the indexer is enabled, but you can turn it off if you don’t use the CCS editor or don’t need the advanced editor features. The indexer constantly scans all open projects to support some advanced editor features and uses a decent amount of system resources, sometimes causing CCS to appear sluggish. This is usually more evident with large projects or when there are many open projects in the workspace (or both). Turning off the indexer may improve performance in such situations.
In some cases, there may be Syntax errors or Symbol could not be resolved errors reported by the indexer even when there is no issue with the build itself. In other words the Build Console and Problems view do not report errors, but there are errors highlighted in the editor margin.
The first thing to try, especially if you are the only one experiencing such errors within a team on a known good project, is to open a new, clean workspace and re-import the project into it. If the errors persist or you experience these in your own custom project, you can look at adjusting the indexer settings or even disabling the indexer. This can be done from Project Properties → C/C++ General → Indexer. However, disabling the indexer completely means losing capabilities such as code completion and navigation to declaration/definition. A better option may be to disable the indexer markers without disabling the indexer itself. To do this, go to Window → Preferences → General → Editors → Text Editors → Annotations and uncheck all three checkboxes for C/C++ Indexer Markers.
If you find the advanced editor features such as Code completion, Open declaration etc. not working correctly, it could be due to a corrupted database/cache. In this case, rebuilding the Index could resolve the issue.
To rebuild the indexed database for a project, right-click on the project in the Project Explorer view and select Index → Rebuild.
Enabling the parallel build option speeds up compilation time by taking advantage of the multi core PCs that are very common these days. This can be especially beneficial when working with large projects.
This option is enabled by default in new CCS projects and most TI example projects.
To customize the setting, right-click on the project in Project Explorer view and go to Properties → Build → Builder tab (or Behavior tab in CCS 7.3 and earlier).
The number of parallel jobs to run can be customized here. The default value will be set to the amount of available processors on the machine, but you may find a more optimal number by trial and error. Note that setting the number of jobs to a value much higher than the number of processors in your computer or setting it to use unlimited jobs may result in the system using up more memory and becoming sluggish.
When parallel builds are enabled, the messages/banners in the CCS build console will be interleaved due to the multiple jobs running at the same time.
To see a video demo of parallel builds, check the References section.
As part of the CCS build, you can define pre-build and post-build steps.
Pre-build steps are steps that run before the main project build takes place.
The pre-build step is always executed even if the state of the main build is up to date. An attempt to execute the main build will occur regardless of the success or failure of executing the pre-build step.
Post-build steps are steps that run after the main project build takes place.
The post-build step is not executed if the state of the main build is determined to be up to date. It will be executed only if the main-build has executed successfully.
One common use-case for post-build step is to convert the executable (.out) created by the project into a hex or binary format using the hex converter or other utilities such as tiobj2bin. The hex converter is part of the compiler toolset (can be found in \ccs\tools\compiler\\bin within CCS installation) and tiobj2bin is included with CCS (can be found in \ccs\utils\tiobj2bin within CCS installation).
To set pre and post build steps in CCS, right-click on the project in the Project Explorer view, go to Properties → Build → Steps tab and enter the desired commands in the Pre-build steps or Post-build steps fields.
For example, to convert the executable (.out) to binary format (.bin), the following command can be used as post-build step:
Be sure to replace ofd2000 and hex2000 with the respective binaries for your device, for example, ofd6x and hex6x (for c6000) or armofd and armhex (for ARM).
Note that some example projects in software packages like TivaWare and Simplelink SDKs already have a similar post-build, which you can use as reference as well.
The fields for pre and post build steps allows for multiple commands to be added, each on a new line.
To add some custom steps or call a batch file after the compile step but before the link step, you can add a pre-link step to the command field in the Linker options, as shown below. The custom step is basically prepended before the existing command and separated with an ampersand. The below example adds a pre-link step to call a batch file.
CCS uses gmake (GNU make) to build projects. If you have a need to use a different make utility or custom build step, you can do the following:
You can also use this if you want to simply modify the default build command to pass additional options to gmake.
When using a custom build step, you may want to consider enabling the build setting Stop on first build error. If this is not enabled it will add a -k (–keep-going) option to the end of the command (for gmake, this option tells it to “keep going” or continue with the build as much as possible after an error), which may not be desired for certain custom build commands.
This setting has to be changed at the project level. There is no global way to change the default builder or builder options.
Projects may be constructed such that the main project is dependent on other projects. A common use case is when a main project links in a library and the project for the library is set up as a referenced project. In this set up, when you build the main project, the referenced project will be built first and then the main project.
Project dependencies can be set up when creating a new CCS project or from the Project Properties of an existing project. In order to create a dependency, all referenced projects must be in the same workspace as the main project.
To create a project dependency:
The Referenced Build-configuration column allows you to choose which build configuration to use when building the referenced project. Note that this setting will apply for the active build configuration of the main project. This setting lets you control which build configuration of the referenced project will be built prior to building a specific build configuration of the main project.
Creating a dependency does not mean that the library generated by the dependent project is automatically linked into the main project. It simply means that the dependent project will be built prior to the main project so any changes made to the dependent project since last build will be picked up. The library file will still need to be manually linked to the main project. This can be done either by linking the library file to the main project or by adding the library name and path to the main project’s linker options.
To see a video demo of how to set up project dependencies, check the References section.
Starting with CCSv7, projects that have a dependency on a library project may show the following variables in the compiler include path and linker library and search path options:
It may appear that these variables are being inherited from the dependent project, however, in reality these variables are not being used by CCS at this time. Although the variables are added to the project, they currently do not resolve to anything or serve any purpose.
One way to confirm is that hovering over the three dots (. ) next to the variable shows that it resolves to .
It is possible to set file level build options that are different than the project level options. This is useful, for example, when specific files require a higher or lower level of optimization than other files.
To set file-specific options, right-click on the file (or folder) in the Project Explorer view, go to Properties, and set the desired options.
Files with file-specific options appear with a special icon (push pin) in the Project Explorer view.
To revert the file back to its default settings:
The special icon will disappear when the settings reset back to default.
To see a video demo of setting file specific options, check the References section.
When you add file specific options, a section is added to the project metadata file to indicate that there are file specific options and which default options to override. When you use the Resource Configurations → Reset to Default option on the file, it will remove that whole section. Hence the project sees it as not having any file specific options in the project anymore and the special icon is also removed for that file.
If you instead go to the file’s Properties → Resource and click on Restore Defaults, it will restore the options back to default but will not remove the special icon. This is because even though the override options are removed, the special section for the file that was previously added is still there and so the icon remains.
If you wish to know which file specific options are set for a certain source file, there are a couple of ways to find out:
By default all files and folders within the CCS project folder are assumed to be part of the project build.
To exclude file(s) or folders from the CCS project build, right-click on the file or folder in the Project Explorer view and select Exclude from Build.
If the project has multiple build configurations, you can specify for which build configurations you want to exclude the file. To do this, right-click on the file or folder in the Project Explorer view and select Resource Configurations → Exclude from Build. In the pop-up dialog select the build configurations for which you want to exclude that file.
With the default settings, files (or folders) excluded from build will appear grayed out in Project Explorer view.
If the file(s) excluded from build are not visible in the Project Explorer view at all, check if the below option is enabled in the view filter for the Project Explorer view.
All CCS releases come bundled with specific version(s) of compiler tools. During project development phase you may want to build your project with a different version of compiler tools than what is included with CCS. One reason may be to avail of bug fixes and enhancements in newer versions of compilers, another reason may be to stay locked down on an older version of the compiler. CCS is very flexible in allowing you to do this.
To view the version of compiler used for the project build, right-click on the project in the Project Explorer view and go to Properties → General → Project tab, and view the Compiler version field. If the project imported into CCS was originally created with a version of compiler tools different than what is installed in your machine or what CCS is set to use, that information will be shown when you hover over the Compiler version field.
The drop-down menu in the Compiler version field will show the different versions available to use if there is more than one version discovered/installed into CCS.
If you wish to build with a different version of compiler tools than what is already available, you can install the specific version and have CCS discover it. Please see the Compiler Installation and Selection article for details.
Check for Updates** (only finds versions newer than the one currently installed). - **Help->Install Code Generation Compiler Tools** (finds older and newer versions - this menu is available in CCS 7.4 and higher).
To see a demo video, check the [References](#video-demos) section. In this case, CCS will automatically recognize the compiler tools and show it in the drop-down menu under **Compiler version**. A more detailed explanation of how compiler updates work from within CCS is in this article: [Compiler Updates](https://software-dl.ti.com/ccs/esd/documents/ccs_compiler-updates.html) 2. Install the latest available compiler tools from the **CCS App Center** (menu **View->CCS App Center**). Note that only the very latest compiler version is available here. There isn't a way to select and install a specific older version using the App Center. In this case, CCS will automatically recognize the compiler tools and show it in the drop-down menu under **Compiler version**. 3. Install compiler tools using a separate stand-alone installer (download from [this page](https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/index.htm)). In this case, CCS can be made to detect it by following the steps described here: [Compiler Installation and Selection](https://software-dl.ti.com/ccs/esd/documents/ccs_compiler-installation-selection.html) ####Discovered Tools To see which versions of compiler tools are discovered/known to CCS, go to menu **Window->Preferences->Code Composer Studio->Build->Compilers**, and check the versions listed under **Discovered tools**. There are some paths that CCS always searches by default (typically the folder where CCS was installed). These are listed under **Tool discovery path**. You can also add your own paths to this list by clicking the **Add** button and browsing to the compiler tool's installation directory or to it's parent directory. After the tools are discovered they will appear in the **Discovered tools** list. Discovery paths added by the user (not the default paths) are stored in metadata information in the file \ccsv6\eclipse\configuration\ccs.properties 
When there is more than one version of compiler tools discovered by CCS, they will appear in the drop-down menu in the **Compiler version** field from where you can select the desired version. The version selected in this field will be the version used for building the project. 
To see a video demo of how to change the version of compiler tools used to build a project, check the [References](#video-demos) section. -->
Similar to changing the version of compiler tools, you can also change the version of XDCtools and products like SDKs used to build a project.
To view the current version of XDCtools used for the build and other Product details, right-click on the project and go to Properties → General → Products tab. This tab displays the version of XDCtools used for the build, and Products and Repositories available and enabled, among other things.
The drop-down menu under XDCtools version will show the different versions available to use if there is more than one version discovered/installed into CCS. Similarly, the Products and Repositories view will show all the products discovered/installed into CCS.
If you wish to build with a different version of XDCtools or SDK than what is already available, you can install the specific version and have CCS discover it (a.k.a. Product Discovery). Please see the Product Installation and Selection article for details.
Preferences->Code Composer Studio->Products**, and check the versions listed under **Installed products**. There are some paths that CCS always searches by default. These are listed under **Product discovery path**. You can also add your own paths to this list by clicking the **Add** button and browsing to the directory to search for new products. Then to have CCS discover the products in those paths click the **Rediscover** button. After the products are installed they will appear in the **Installed products** list. 
Once additional Products and Repositories have been installed, you can enable which version to use in your project from the drop-down menu for **XDCtools version** (for XDCtools) and from the **Products and Repositories** tab.  -->
During development, it is quite common to have the need to create a single project that builds executables (.out files) with different project options, source files or even for different memory configurations. In CCS this is done with Project Build Configurations.
A Project Build Configuration defines a set of build options and resources at the project level that can be labeled and easily accessible with a very minimal number of steps. Therefore, by creating multiple build configurations within a single project it is possible to organize and quickly switch between different sets of options and resources.
When a new project is created in CCS, two build configurations are created by default: Debug and Release. The Debug build configuration usually has no optimization and full symbolic debug enabled, to enable easy debugging. The Release build configuration will often have optimization enabled and symbolic debug disabled, to get your code as small or fast as possible without the need for source level debug. These are just the options usually set for the default build configurations, it could be different for different device families, so it is best to check the default options set for each build configuration and tweak it as necessary.
When a new project is created or an existing project is imported into CCS, the first configuration (in alphabetical order) is set to active in the workspace. Usually this is the Debug configuration but may be different depending on the configuration names.
Note that some example projects provided by TI may have custom configuration names other than Debug and Release. For example, projects in C2000Ware may have RAM and Flash configurations, where one is set up to run from RAM and the other to run from Flash. Based on the configuration, the project may use a different linker command fle and may or may not include certain source files.
When a project is built, the output files generated by the build are placed in a configuration-specific subdirectory. For example, if the project is in the directory MyProjects, the output files for the Debug configuration will be placed in MyProjects\Debug. Similarly, the output files for the Release configuration will be placed in MyProjects\Release.
To change the active configuration:
To see a video demo of how to change the build configuration, check the References section.
To create and manage your own custom configurations:
Here you can delete, rename and create new configurations. When creating a new configuration there are several options available to copy a base set of options/settings.
To see a video demo of how to create and manage build configurations, check the References section.
To build all the build configurations of a project:
There are several options available for building projects:
During the build, the Console view displays the standard and error outputs of the build tools.
When the build is finished, the Problems view displays any errors or warnings.
If there are errors encountered during build, refer to the Build errors in CCS page. It discusses some of the more common build errors and warnings and how to resolve them.
CCS projects use the Eclipse managed make system where the makefile is generated automatically and takes care of managing the toolchain and build details.
This section provides an overview of the project metadata files and describes what happens under the hood during the project create and build steps.
When a new CCS project is created, the following project metadata files and folders are created in the project folder:
The .ccsproject file holds a snapshot of selections made at the time of project creation, and rarely changes after that. So if you change properties such as the device-variant or compiler tools version, the change is not stored in the .ccsproject file, but instead stored in the .cproject file.
The .ccsproject file is mainly a historical left-over from the days when some settings were stored on a project-level (as opposed to build-configuration-level). But the file is still currently used to:
Although it seems like this file stores some unnecessary information, it could be helpful when trying to debug issues.
The .ccsproject, .cproject, .project files are XML files. It is generally NOT recommended to manually edit these files unless you are an expert user and have a good understanding of what you are modifying.
When a CCS project is built for the first time or rebuilt, it goes through the following steps:
A typical project build looks like the following:
The makefile auto-generated by CCS includes a few other files, namely makefile.init, makefile.defs and makefile.targets.
makefile.defs is used for defining additional make rules for SYS/BIOS projects.
makefile.init and makefile.targets are not used by the TI build environment. They are inserted into the makefile by one of the Eclipse components(CDT) and can be used to extend the behavior. For example, you can create these optional makefiles in the top-level folder of the project:
Each file, if it exists, gets included at a specific point along the build. You can see where they get included by taking a look at the makefile in the active project configuration folder.
Example of using makefile.targets:
If you wish to add some additional clean commands (i.e. perform some clean actions in addition to what the default clean does) you could do the following:
1. Create a makefile.targets that contains rules for the additional make targets and place the file in the top-level folder of the project. For example, a makefile.targets file to perform additional clean commands (in this case, delete the main.asm file) could look like this:
myclean: -$(RM) "main.asm" -@echo 'Finished my custom clean'
2. Modify the Build → Builder tab in CCS to add “myclean” in addition to the default clean.
Now when you select Clean Project, it will perform the default clean as well as the custom myclean rule, as shown in the output below.
**** Clean-only build of configuration Debug for project test_f28377D **** "C:\\CCStudio_v6.1.1.00022\\ccsv6\\utils\\bin\\gmake" -k clean myclean DEL /F "test_f28377D.out" "test_f28377D.hex" DEL /F "main.pp" DEL /F "main.obj" 'Finished clean' ' ' DEL /F "main.asm" 'Finished my custom clean'
Example of using makefile.init:
This example illustrates how to hook into the generated makefile to script a custom pre-build step. This is useful in cases where the commands cannot be run as a pre-build step in CCS (for example, in cases where you want the main build to fail if the pre-build fails).
all: custom-step custom-step: @echo Custom pre-build step @mkdir a**b
Now, when you build your project, the build will stop immediately after failing to execute the "@mkdir a**b" command in the custom-step. And if you change the command to “@mkdir ab”, the custom-step will succeed and the rest of the build will proceed.
This is just a simple example that shows how to hook into the generated makefile to script a custom pre-build or post-build step. Similarly, hooks can be scripted for individual source files.
To completely customize the makefile, you can go to Project Properties → Build → Builder tab, and deselect “Generate Makefiles automatically”. After the project is built once you can edit (or completely rewrite) the generated makefiles.
Pre-build steps are steps that run before the main project build takes place.
For details on setting up and using the pre-build step in CCS, see the section Pre and Post Build Steps.
When a project is built in CCS, the main build is the step where the build commands and input files are passed to the Compiler tools, and optionally to RTSC tools. RTSC tools are invoked only for projects that involve RTSC components (IPC, SYS/BIOS etc) and are called prior to the compiler tools. Starting with CCS 8.2, there is also support for the SysConfig tool that can be used to configure components like TI Drivers and device-specific components (such as the networking stack, EasyLink, and WiFi) on SimpleLink devices. Each build tool takes in a set of input files and generates a set of output files.
The figure below shows a typical software development flow and gives an idea of the build tools and files involved when a project is built in CCS. All of this is handled in the background by the makefile, however it is helpful to have an understanding of the build flow to better understand the build output that appears in the CCS build console.
The build tools components are highlighted in blue and the input/output files are highlighted in white . The RTSC Tools and SysConfig Tools are dotted to show that they come into play only when working with RTSC and/or SysConfig.
The most common path of software development flow, in the absence of RTSC or SysConfig, is the straight path going from C/C++ Source Files down to the Executable file through the Compiler, Assembler and Linker. The Assembler step usually runs in the background and is hidden from the user. The Archiver and Library build utility are peripheral functions that enhance the process and may or may not be run depending on the requirements.
If the project is a RTSC project, the XDCtools run first and generate output files that are then passed to the compiler and linker.
If the SysConfig tool is used to configure components, the SysConfig command runs prior to the compiler and generates output files (.c, .h) that are then passed to the compiler. The files generated by SysConfig will depend on which SDK components are integrated into the application. As more SDK components start to be integrated with SysConfig, more files will be generated.
For more information on each of the tools shown in figure, please see the references below:
For more information on some of the input and output files in a typical CCS project build flow refer to the article Files in CCS Projects.
The main build step discussed above results in a executable file (.out). This file can be directly loaded to a target device and debugged using Code Composer Studio, or can be converted to a hex format and programmed to a target device by a hex programmer. Other types of post processing can also be performed on the .out file using utilities included with the compiler tools.
The figure below shows some of the typical post build operations.
For more information on each of the tools shown in figure, please see the references below:
Details on all the above tools are in the Assembly Language Tools Users Guide.
For details on setting up and using the post-build step in CCS, see the section Pre and Post Build Steps.
At build time, the Console view displays the standard and error outputs of the build tools. When building multiple projects, the Console view will show the output for the active project selected in the Project Explorer view.
The view displays the options passed to the various build tools and any diagnostic messages reported by the build tools. The information reported in this view are often more detailed and useful than the summary reported in the Problems view.
The Problems view provides a summary of errors and warnings encountered during project build.
Some messages will have a clickable link that provides more details about the diagnostic.
The view contains the following information in the columns:
If the Type column says C/C++ Problem, it indicates the error is coming from the TI build tools. If it says Semantic Error or Syntax Error, the error could be coming from the Eclipse Code Analysis tool.
For more information on Code Analysis errors, refer to the Code Analysis section.
CCS has terminal commands for creating, building, and importing projects. This is very convenient for nightly automated builds, or simply to perform these actions without bringing up the GUI interface.
Please refer to the article below for details on all the supported commands and their usage.
System Projects were introduced starting with CCS 9.x. It is a special type of project designed to simplify management of multiple projects that are associated with different individual cores of a multicore device. In the System Project, associations are made between cores on a device and projects in the workspace. Building the System Project would build all associated projects and debugging a System Project would launch a debug session for the device and load the program build from the project associated with each core.
For more details on how to use System Projects, Please refer to this article.
Please refer to the article below for information on working with source control in CCS.
The Code Composer Studio toolset consists of different components such as the Compiler tools and XDCtools. It is important to understand that each component has its own version number and updates for each component may be released independent of a CCS release.
For example, CCS 10.0 includes the following:
Updates to each of these components can be installed individually while still working with CCS 10.0.
To install compiler updates refer to the Compiler Installation and Selection article.
To specifically understand how compiler tools are versioned and released, please see this article.
To install XDCtools and other Target Content updates refer to the Product Installation and Selection article.
A CCS project can be modified to build with any of the available versions of compiler tools or RTSC products. The same can be done with different versions of SDKs as well.
When reporting an issue to TI, it is important to not only include the version of CCS, but also the version of Compiler tools, SYS/BIOS, XDCtools, SDK, or any other relevant components and software, depending on the issue.
If there are errors encountered during project import or build, refer to this troubleshooting page: Project Import and Build errors in CCS.
