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

Build Errors in CCS

From Texas Instruments Wiki
Jump to: navigation, search

This page is no longer maintained and is kept here for reference only! Please go to this link for the most current version.



When building a project in CCS, you may encounter errors or warnings. The errors may come from gmake or more commonly from one of the build tools: XDCtools, compiler or linker. It is often helpful to understand what the errors and warnings mean and how they can be resolved. This page lists some of the more common errors and warnings. Note that this is, by no means, a comprehensive list of errors but is merely a collection of the more common ones seen by users.


Tip: Paths with non-alphanumeric characters can potentially cause various project management and build issues. In some cases, the build may go fine but clicking the Debug button may not start up the debugger. Or trying to go to Project Properties->Debug may result in error: "Error reading Debug Properties". Any of these symptoms could occur when using paths with non-alphanumeric characters.

Examples of non-alphanumeric characters are '&', '!', '(', etc. Hence it is recommended to avoid such characters in project names, source/header files/folders, CCS workspace folder names, system temp folder, etc. One exception is the underscore character '_', which is normally accepted. Note that a space/whitespace character, while acceptable in most cases, can cause build issues with SYS/BIOS projects, and it is recommend to avoid it for those.

Problems view

For many of the diagnostic messages listed below, and a few others, the Problems view will have a link which you can click on to get more details about the diagnostic.

Problems view1.png

Clicking on the link will take you to an Advice view with details on what the error means, why it is happening and how to correct it.

Problems view2.png

Compiler Diagnostics

Warning: function declared implicitly


Error: could not open source file "xxx.h"

In CCS, include paths are set under Project Properties->Build->Compiler->Include Options
If your include paths make use of Build variables and you encounter this error, make sure that the build variables are set correctly (under Project Properties->Build->Variables tab) and the paths using those variables resolve correctly.
If your include paths make use of system variables, such as PROJECT_ROOT make sure it is a supported variable. To see the list of supported build variables in a specific version of CCS, go to Project Properties->Build->Variables tab, and click on "Show system variables".
It also helps to take a close look at the CCS build console to see exactly what is getting passed to the compiler.

Error: option --include_path is missing its parameter 'dir'

This error appears when the compiler include path specified in CCS involves a variable or macro and the variable is not resolved properly. Check the include paths set under the project's compiler options (by going to Project Properties->Build->Compiler->Include Options, and check the paths under --include_path) and make sure that any paths that use variables/macros are resolved properly (ie) the variables are actually defined. To check the variables, go to Project Properties->Build->Variables tab.

Command-line error: cannot open command file '\\0301616': No such file or directory

Make sure your TMP environment variable is set to something like C:\Users\username\AppData\Local\Temp .

Debug Assertion Failed

The complete error message may look like this:
Debug Assertion Failed
Program: c:\ti\ccsv6\tools\compiler\arm_5.1.10\bin\armcl.exe
File: isctype.c
Line: 68
Expression: (unsigned)(c+1) <= 256
This error is triggered by non-ASCII characters passed as input to the compiler. This could be in paths, compiler options, user name in the computer, or even in the TEMP directory pathname or USERPROFILE directory pathname.
To resolve the error, ensure that there aren't any non-ASCII characters in any paths or user names.
Related forum thread:

Fatal error: cannot open IL output file "../Temp/Main.if"

The compiler is reporting that it is not able to open the .if file which is a temporary file created by the compiler during compilation. Check that the directory being passed to the --temp_directory option (in this case ../Temp) actually exists and is valid prior to running the build.

Linker Diagnostics

Error: unresolved symbols remain

Note that it is quite common to hit this error if you try to create your own project based on a Stellarisware or ControlSuite example but forget to add the required libraries to the project using the --library option in the linker's File Search Path options. These software examples typically require one or more driver libraries or other libraries to resolve references. Examples of libraries are driverlib, grlib, usblib from Stellarisware/Tivaware, and driverlib, IQMath library etc from ControlSuite.

The same concept applies even when you are working with any other libraries, including the C runtime library included with the TI compiler tools.

You can add the required libraries to your project in one of two ways:
  • directly specify the full path and library name in the "--library" option under Project Properties->Build->Linker->File Search Path, or
  • specify the path in the "--search_path" option and the library name in the "--library" option.

Another reason you could see this error is if you are using C header from C++ code. If you are including a C header file that isn't provided by the system, and if you are able to change the C header, you should strongly consider adding the extern "C" {...} logic inside the header to make it easier for C++ users to #include it into their C++ code. Since a C compiler won't understand the extern "C" construct, you must wrap the extern "C" { and } lines in an #ifdef so they won't be seen by normal C compilers.

Error: undefined symbol "ResetISR", unresolved symbols remain

If this error appears when creating a new CCS project or using the "Hello World" project template for CC26xx or CC13xx devices, the reason for it is that the New CCS Project wizard does not add the required device startup files and driverlib that are needed for a successful build. The linker error about undefined symbol "ResetISR" appears because that function is defined in a startup file that is not added to the project by default. The startup files and driverlib typically can be found in the SimpleLink SDK software (or in the case of CC2650, the BLE SDK software).
The preferred and recommended method of starting development with Wireless Connectivity devices is to start with the examples in the Simplelink SDK rather than creating a new project in CCS.
If you still wish to create and build a new project or "Hello World" project, you can follow the steps below to fix the undefined symbol error. However, please note that these steps alone may not guarantee that the program runs as expected as this is not a tested/validated build environment, hence not recommended.
These are the steps to fix the unresolved symbol ResetISR error for a CC13xx device (similar steps would work for CC26xx):
  • copy the file startup_ccs.c from C:\ti\simplelink_cc13x0_sdk_1_30_00_06\source\ti\devices\cc13x0\startup_files to your CCS project
  • Under Project Properties->Build->Compiler->Include Options, add the path to the startup_files folder to --include_path option (eg: "C:\ti\simplelink_cc13x0_sdk_1_30_00_06\source\ti\devices\cc13x0\startup_files")
  • Under Project Properties->Build->Linker->File Search Path, add driverlib.lib to --library option, and add the path to driverlib.lib to --search_path option (eg: "C:\ti\simplelink_cc13x0_sdk_1_30_00_06\source\ti\devices\cc13x0\driverlib\bin\ccs")

Error: placement fails for section "xxx"

On C28x this could appear even when it shows there is sufficient memory to accomodate the section. If so, the reason could be data page blocking. Refer to this FAQ for more information.
On MSP430 (or other) devices with limited RAM, the linker may fail to allocate the .bss or other sections allocated to RAM. The .bss section is for uninitialized global variables, and goes into RAM, along with stack (.stack) and heap (.sysmem) sections . If the code has a large number of global variables, you may run out of RAM space. If this is the case, you may consider making some of the variables const so they go into the .const section instead (which gets placed in FLASH instead of RAM).

Error: Tag_Memory_Model attribute value of "1" that is different than one previously seen ("2"); combining incompatible files

This means that the build is combining files with different memory models (small, large, huge) which the linker does not allow. Check the build options for all source files and libraries to make sure they are all built for the same memory model.
For C2000, large memory model (-ml compiler switch) is recommended and used in all examples provided by TI.

Error: Tag_ISA attribute value of "2" that is different than one previously seen ("1"); combining incompatible files

See this FAQ

Error: file rts2800_fpu32.lib<boot.obj>" specifies ISA revision "C28FPU32", which is not compatible with ISA revision "C2800" specified in a previous file or on the command line

See this FAQ

Error: file grlib.lib<fontcmss30b.obj>" was built without VFP coprocessor support while a previously seen file was; combining incompatible files

This means the build is combining files with different floating point support options which the linker does not allow. In this case, one of the files being linked in (grlib.lib) was built without VFP support while another file was built with VFP support and the linker cannot link these files together. Check all object files and libraries and make sure they are all built with the same --float_support option.

Warning: creating output section "xxx" without a SECTIONS specification

This warning means that the linker is creating and allocating output section "xxx" in memory using some default algorithm because it isn't explicitly allocated in the linker command file. While this may be ok, it is generally not advisable. It is best to explicitly allocate the section to the appropriate memory region by adding the section to the SECTIONS directive in the linker command file.

Error: placement with alignment fails for section ".reset" size 0x4 . Available memory ranges: RESET size: 0x2 unused: 0x2 max hole: 0x2

This usually occurs when the CCS project contains only assembly code but the linker runtime model assumes it contains C/C++ code. If the project is truly an assembly-only project, you should start with the "Empty Assembly-only project" template when creating the project in CCS so that the linker runtime initialization model and entry point are set up correctly for assembly-only projects.
Note that for assembly-only projects, the linker runtime initialization model is blank (differently than C/C++ code projects where it is set to --rom_model) and the entry point is set to RESET.

RTSC Diagnostics

xdc.cfg.SourceDir : Build of generated source libraries failed: exit status = 2:

A couple of different reasons could trigger this type of error

  • Make sure there are no whitespaces or non-ASCII characters in any paths referenced by the build tools. In other words, make sure all software packages are installed in paths without spaces, and workspace and project names also do not have spaces or non-ASCII characters. We use gmake to build makefiles, and gmake doesn't deal well with spaces in directory and file names.
  • Take a close look at the CCS build console and ensure that the sh.exe used for the build is the one from the CCS directory. Also check your system PATH variable and see if there is another sh.exe (or gmake.exe) in your system PATH earlier than the one from the CCS installation. If there is one, then that will be used for the build and could cause build errors such as this. Some toolchains that are known to include sh.exe and could cause a conflict are Cygwin, WinAVR, Yagarto. In this case, remove those conflicting tools from the system PATH or modify the PATH so that the sh.exe and gmake.exe from CCS are seen first.
  • Another source of problems related to sh.exe runnig Windows 10 may be Windows Defender. In "Windows Defender Security Centre", "App and browser control", "Exploit protection settings" one can add exceptions under "Program settings". Adding a rule for "sh.exe" to disable/override "Force randomisation for images (Mandatory ASLR)", "Randomise memory allocations (Bottom-up ASLR)", "Validate stack integrity (StackPivot)". missing input config script

The XDCtools build command should normally have the configuration script (.cfg file) passed at the end of the command. If the .cfg is not getting passed correctly, then this message will appear in the CCS build console. This error will then result in other compiler errors further down in the build.

You can confirm if the root cause is the .cfg file not getting passed correctly by looking at the file in the directory Debug (or Release) in your project. The command line that runs configuro usually looks like this:

"C:/ccsproducts/xdctools_3_23_04_60/xs" --xdcpath="..." -o configPkg -t ti.targets.elf.C674 -p ti.platforms.evm6747 
-r release -c "C:/ti/ccsv5/tools/compiler/c6000_7.4.4" --compileOptions "-g --optimize_with_debug" "$<"

If the "$<" part is missing that will cause this error. If that is the case, you can add the .cfg file as ../filename.cfg at the end of the Command-line pattern in Project Properties->CCS Build->XDCtools.

Xdctools commandline.png

We have noticed this error comes up mostly with users from Turkey, and could be related to language settings in Windows. Going into the Control Panel and changing the Language settings to English also seems to help. A proper fix for Turkish Windows users has been implemented in CCSv6.1.3

CCS gmake errors

gmake: Access is denied

This type of error could occur when there is interference with an anti-virus program. Try disabling the anti-virus and retry the build.

These forum threads discuss similar errors related to anti-virus:

If disabling anti-virus does not resolve the error, try deactivating the firewall. Go to "Start", type "Firewall", click "Allow a program through Windows Firewall" and click on "ccstudio" on the new window.

Another variation of this error could be due to incorrect permissions for temp folder. The error message could look like this:

gmake: *** [DSP2802x_CodeStartBranch.obj] Error 5
process_begin: CreateProcess(C:\Users\Owner\AppData\Local\Temp\make7604-1.bat, 
C:\Users\Owner\AppData\Local\Temp\make7604-1.bat, ...) failed.
make (e=5): Access is denied.

make: The system cannot find the file specified

Below are some troubleshooting tips if CCS generates an error like this:

process_begin: CreateProcess(C:\Users\Owner\AppData\Local\Temp\make4812-1.bat, C:\Users\Owner\AppData\Local\Temp\make4812-1.bat, ...) failed.
make (e=2): The system cannot find the file specified.
  • Try disabling anti-virus and deactivating firewall as mentioned in the previous error
  • Check your system PATH variable to see if there are any other "make" binaries in the PATH. If you have other toolchains in your PATH (such as Cygwin, WINAVR) that also contain make utilities, then that could cause a conflict, and the incorrect make may be picked up. Try removing such tools and/or setting your PATH to a bare minimum to ensure that the gmake used by CCS is correctly picked up. Then restart CCS and see if the error persists.
  • Verify that you have execute permissions on TEMP folder (the folder that System variables TEMP and TMP are set to). The build process uses this folder for temporary files.
  • Try changing the TEMP and TMP variables to point to a different directory like c:\temp. You can override the System variables within the scope of CCS by going to CCS menu Window->Preferences->C/C++->Build->Environment, and use the Add button to add these two variables, and set them to a simple directory like c:\temp

CCS Syntax/Semantic errors

Type 'xyz' or Symbol 'abc' could not be resolved

These errors usually come from the Eclipse CDT (C/C++ Development Tools) indexer and not from the TI compiler tools. To confirm this you can check that the errors appear in the CCS Editor and Problems view but not in the CCS build console.
  • If you are working with a newer version of CCS and opening a workspace that was created with an older version (like CCSv4), these types of errors may occur. Try opening a new clean workspace and import your project into it and rebuild.
  • You could ignore the CDT syntax error or you could turn off syntax error reporting in the editor by going to Window->Preferences->General->Editors->Text Editors->Annotations, select C/C++ Indexer Markers and uncheck all the checkboxes.
More information on the Eclipse indexer can be found in this page.

CCS Post-build/Pre-build Steps errors

tiobj2bin.bat failed on ofd470

If your post-build or pre-build step command (to invoke tiobj2bin) is split into multiple lines, it will generate an error. For example, if the command is split as shown below, then the following error message would appear at build time.

"C:/ti/ccsv6/utils/tiobj2bin/tiobj2bin" "Test1.out" "Test1.bin"
tiobj2bin.bat failed on ofd470
Please see
tiobj2bin.bat failed on hex470
Please see
'C:\workspaces\test_workspace\Test1\Debug\armofd' is not recognized as an internal or external command,
operable program or batch file.
'mkhex4bin' is not recognized as an internal or external command,
operable program or batch file.
mkhex4bin failure occurred.  Giving up.
"C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armofd" "C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armhex" "C:/ti/ccsv6/utils/tiobj2bin/mkhex4bin"
error: failed to read
error: failed to read

To fix the issue, check the post-build/pre-build steps and make sure the complete command is in a single line.

Other References

CCS Build Console

  • To understand and debug build errors, pay close attention to the output in the CCS build console. If the error message is not described in this page or the references listed above, then use the full text of the diagnostic or diagnostic number and search the TI Embedded processors wiki or the TI forums for an explanation of the error.
  • When reporting errors/issues to TI, please send the full output of the CCS build console. This can be very helpful as it will show the complete list of options being passed to the XDCtools and/or code generation tools.
    • To save the CCS build log to a file, click on the icon shown below in the CCS build console and choose the location and file name for the log file.
      Ccs build log.png

    • Alternately, the CCS build log is also saved off automatically in a default directory within the workspace. Please check the short video below for more information.
      Saving Project Build log

Useful Object File Utilities

  • There are several utilities included with the compiler toolset that can be very handy in analyzing object files and executables as well as in debugging build issues. For eg, the object file display (ofd) utility prints the contents of object files (.obj), executable files (.out) and archive libraries (.lib) in text and XML formats. A lot of useful information can be gleamed from the output of ofd. More information on this utility and others can be found in the Assembly Language Tools Users Guides. These utilities can be run stand-alone from a command prompt or added as a post-build step in CCS.
  • Code Generation Tools XML Processing scripts (cg_xml) is a separately downloadable package of Perl scripts that can be used to process the output from the code generation tools. It can be used to do things like detailing the size of all sections in an object file, or figuring out how much of the memory map is taken up by specific libraries.
  • A utility called objdiff, included in the cg_xml package, is very useful for comparing executables to verify if they are bit-exact. The utility ignores meta-data that does not get loaded to the target (such as debug information and timestamp) and only compares the relevant information.

    At build time, the compiler includes timestamp and file path information to the output file. As a result, builds performed by users that have different file paths will not be bit-exact or have matching CRCs. There is no option to remove the timestamp from the object file, so the best option is to compare the object files using utilities like objdiff, which will ignore those differences.
    For the project path, this is usually stored in the debug information. You can use the strip utility (included with the compiler tools) on the file to get rid of the debug sections before comparison. Some projects refer to the __FILE__ macro, which will embed a string in the actual target memory; this cannot be stripped.
    For more information, please see this wiki page: Binary comparison of executables generated by TI CGT tools to reduce test cycle time