Project Import and Build errors in CCS

## Introduction This page describes how to troubleshoot and resolve some of the common project import and build errors in CCS. Build errors may come from gmake or more commonly from one of the build tools: compiler, linker or XDCtools. Note that this page is not a comprehensive list of errors, just a collection of the more common ones. ## Project Import Errors **1. Error: A project with name 'xyz' already exists in the workspace!** This means that another project with the same name already exists in the workspace. CCS does not allow multiple projects with the same name to be imported into the workspace. To import the new project, use one of the following solutions: - Delete the existing project in the workspace (from the project’s context menu, select **Delete**). If the project directory is physically inside the workspace directory, additionally check the box to **Delete project contents on disk**. - Use a new workspace. **2. Error importing project. Device-id "MSP432P401R" is not recognized!** This error usually appears if support for the mentioned processor was not installed with CCS. One way to confirm this is to try to create a new project for the device noted in the message. Go to menu **Project → New CCS Project** and see if you can select the device mentioned in the message (MSP432, in this example) in the Target list. If the device is not in the list, that confirms that support for that device is not installed. To add this support, re-run the main CCS installer executable (either online or offline). Follow the installer screens and select the same directory as the original install. Keep following the installer screens, select the desired Product families for which you'd like to add support, and continue with the installation. This will add support for the selected product family into your existing CCS installation. The process is also described in the [CCS Updates](./users_guide/ccs_updates.html#changing-the-code-composer-studio-installation) page. When the installation is complete, the project should import successfully. **3. Error: Import failed for project 'abc' because its compiler definition is not available. The project does not appear to be a CCS Project. Please try importing it using the 'General → Existing Projects into Workspace' wizard.** This type of error could error if support for the processor the project is created for (and consequently the compiler tools) was not installed with CCS. For example, if it is a C2000 project, go to menu **Window → Preferences → Code Composer Studio → Build → Compilers** and check if the C2000 compiler is listed under **Discovered Tools**. If it is not, then CCS is missing device support for C2000 devices. Note that in this case, simply installing the compiler tools for the processor family (using menu **Help → Install Code Generation Compiler Tools**) is not sufficient. Instead full device support needs to be added. To add this support, re-run the main CCS installer executable. Follow the installer screens and select the same directory as the original install. Keep following the installer screens, select the desired Product families for which you'd like to add support, and continue with the installation. This will add support for the selected product family into your existing CCS installation. The process is also described in the [CCS Updates](./users_guide/ccs_updates.html#changing-the-code-composer-studio-installation) page. When the installation is complete, the project should import successfully. **4. Error: Import failed for project 'abc' because its compiler definition is not available. Please install the X.Y.Z compiler before importing this project...** This error is slightly different from the previous one. Note the difference in the text of the message. In this case, CCS requires a specific version of the compiler tools to be installed before it can import the project. **Background and Reason** Compiler releases included with CCS follow a certain version numbering scheme. It is recommended to read through [this page](./sdto_cgt_lts-and-sts-compiler-releases.html) first to understand the compiler version numbers . We will use X.Y.Z numbering here to refer to both older and newer (STS/LTS) compiler version numbers. To explain this error we will use the following acronyms: - **Project Compiler version (PCV)** - refers to compiler version used to create the project that is being imported - **Known Compiler Version (KCV)** - refers to compiler version(s) that are "known" to the user's CCS installation KCV: Every installation of CCS has a list of compiler versions "known" to it. The list comprises of versions included with that CCS as well as versions that have historically shipped with CCS. Usually the latest version in the "known" list is the version shipped with that CCS. Note that the list of KCVs is specific to a installation of CCS. For these KCVs, CCS has the built-in model that is required to parse a project. As long as PCV is in the list of KCVs, CCS is able to successfully import the project. A "new" compiler version is one that differs from KCV in either X or Y digit. For example, if 15.12.0.LTS compiler is the latest version in KCV, then 16.3.x.STS or 16.6.x.STS compiler is considered a "new" version. If PCV is a "new" version, CCS does not have the built-in model required to parse the project, hence is not be able to import the project. In summary, for a project created with compiler version X.Y.Z (where X.Y.Z is not a KCV) - if the version differs from KCV in only Z digit, then the project still imports - if the version differs from KCV in either X or Y digit, then the project does not import and the above error message is generated For example, if the latest version CCS ships with is 15.12.0, it can import projects created with 15.12.1, 15.12.9, etc. but not projects created with 16.12.0 or 17.3.0 (until that exact compiler version is installed and discovered by CCS). **Solution** To allow the project to import, install the **exact** compiler version with which the project was created. The required version will be mentioned in the error message. For details on installing a specific compiler version, please see the [Compiler Updates](ccs_compiler-updates.html#install-new-features) page. If you already have a compiler installed that is newer than the required version, then see [Installing Older Versions](ccs_compiler-updates.html#installing-older-versions) section for details. ##General Tips 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 going 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. 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. A space/whitespace character, while acceptable in most cases, can cause build issues with SYS/BIOS projects, hence it is recommended to also avoid it. ##Problems view For many of the diagnostic messages, the **Problems** view in CCS will have a clickable link that will provide more details about the diagnostic. ![](./images/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. ![](./images/problems_view2.png) ##CCS Build Console To understand and debug build errors, pay close attention to the output in the CCS build console. Note that when building multiple projects, the build console will show the output for the active project selected in the **Project Explorer** view. If the error message is not described in this page, then use the full text of the diagnostic or diagnostic number and search the [TI forums](https://e2e.ti.com/support/default.aspx) for an explanation of the error. If you still fail to understand the error, post a question to the [TI forums](https://e2e.ti.com/support/default.aspx). When reporting errors 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. ![](./images/ccs_build_log.png) - Alternately, the CCS build log is also saved off automatically in a default directory within the workspace. Please check this short video for more information. [Saving Project Build log](https://www.youtube.com/embed/m60atZiqyuU) ##Compiler Diagnostics ###Warning: function declared implicitly See https://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/225 ###Error: could not open source file "xxx.h" See https://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/5 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 (go 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: <pre> 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 </pre> 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: https://e2e.ti.com/support/development_tools/compiler/f/343/t/244013 ###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 #10234-D: unresolved symbols remain See https://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/10234 It is quite common to hit this error if you try to create your own project based on a TivaWare 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 Tivaware, and driverlib, IQMath library etc from ControlSuite. The same concept applies even when you are working with 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: Under **Project Properties → Build → Linker → File Search Path** - directly specify the full path and library name in the "--library" option 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 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). Rather than creating a new project in CCS, the preferred and recommended method of starting development with Wireless Connectivity devices is to start with the examples in the Simplelink SDK. 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 although these steps may resolve build errors, there is no guarantee that the program will run as expected. This is not a tested/validated build environment, and is generally 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" See https://processors.wiki.ti.com/index.php/Compiler/diagnostic_messages/10099 On C28x this could appear even when it shows there is sufficient memory to accommodate the section. If so, the reason could be data page blocking. Refer to [this page](https://software-dl.ti.com/ccs/esd/documents/c2000_c28x-compiler-understanding-linking.html#frequently-asked-questions) 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 page](https://software-dl.ti.com/ccs/esd/documents/c2000_c28x-compiler-error-and-warning-messages.html#error-tag_isa-attribute-value-of-2-that-is-different-than-one-previously-seen-1-combining-incompatible-files). ###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 page](https://software-dl.ti.com/ccs/esd/documents/c2000_c28x-compiler-error-and-warning-messages.html#fatal-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). ###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 #10247-D: 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. For additional details, please check the section **The SECTIONS Directive** of the article [Linker Command File Primer](./sdto_cgt_Linker-Command-File-Primer.html). ###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. ###Error #10269: output file "minimalProject.out" exceeds code size limit This error is caused by the use of a code size limited linker. This code size limitation was removed when Code Composer Studio version 7 was released. To convert Code Composer Studio into full versions, simply follow the instructions for [CCSv4](https://processors.wiki.ti.com/index.php/Licensing_-_CCSv4), [CCSv5](https://processors.wiki.ti.com/index.php/Licensing_-_CCSv5), [CCSv6](https://processors.wiki.ti.com/index.php/Licensing_-_CCSv6). ##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. Usually there will be other errors reported prior to this diagnostic, which should help further isolate the cause. - Check that 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. If the build encounters spaces in paths, one typical error is: *Syntax error: Unterminated quoted string* - If the errors are coming from the shell, the problem may be related to Cygwin (which is supplied with CCS and XDCtools). The types of shell errors that can occur are: - unable to remap *somedll* to same address as parent - couldn't allocate heap - can't reserve memory for stack - died waiting for dll loading - child -1 - died waiting for longjmp before initialization - child state waiting for longjmp - STATUS_ACCESS_VIOLATION - Resource temporarily unavailable To solve the problem, try the following solutions in order: 1) Reboot the PC 2) Look for tools that may contain another Cygwin shell in your Windows system/user PATH environment variable. Sometimes an incompatible version of sh.exe or gmake.exe in the PATH could cause this type of error. [This page](https://processors.wiki.ti.com/index.php/Mklib#MKS_or_Cygwin_or_gmake_tools_in_your_path) tells how to check which shell is getting picked up. If you find any conflicting tools in your PATH , delete them temporarily from the PATH and try again. You may need to reboot after changing the path. 3) Temporarily disable or eliminate anti-virus and security software A list of potential software that could interfere with Cygwin and more information about the issue is noted in this page: https://cygwin.com/faq/faq.html#faq.using.bloda If using Windows Defender, the below security setting may work around the problem: - Go to Windows Defender Security Center - Click on App & Browser Control - At the bottom click on the "Exploit Protection Settings" link - Go to "Program Settings" and click on the "Add program to customize" -> "Choose exact file path" - Navigate to "C:\ti\xdctools_<version>_core\bin\sh.exe" and add it - Override and turn off the following: "Force randomization for images (Mandatory ASLR)" and "Randomize memory allocations (Bottom-up ASLR)" - Click "Apply" If the executable being blocked is from a different directory, like c:\ti\ccsv8\utils\cygwin\sh.exe, then the same procedure should be applied for that executable.  ###xdc.tools.configuro: 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 subdir_rules.mk file in the directory Debug (or Release) in your project. The command line that runs configuro usually looks like this: <pre> "C:/ccsproducts/xdctools_3_23_04_60/xs" --xdcpath="..." xdc.tools.configuro -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" "$<" </pre> 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**. ![](./images/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 was 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: - https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/286276.aspx - https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/270455.aspx - https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/291917.aspx 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: <pre> 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. </pre> ###make: The system cannot find the file specified If CCS generates an error like this try the troubleshooting tips below: <pre> 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. </pre> - 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. ###gmake: the system cannot find the file specified If the gmake command fails to build the program, the Windows cmd.exe (Command Processor) may have its Command Extensions disabled. Close CCS and enable the registry key indicated in the topic Enabling and disabling command extensions of the article below: - [CMD article at Microsoft](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/cmd) Note: third party programs set to run in the AutoRun registry key may cause issues with proper execution of gmake. Check the thread below for additional details - [Thread on Microsoft forums](https://answers.microsoft.com/en-us/windows/forum/windows_xp-windows_programs/cmdexe-the-system-cannot-find-the-file-specified/c38bacf4-fb96-4990-a650-1c6155d4a432) ##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) Code Analyzer or Indexer and not from the TI compiler tools, hence should not directly impact the build. To confirm if that is the case and to understand more about the Eclipse Code Analysis and Indexer settings please see the [Advanced Project Settings](./users_guide/ccs_project-management.html#advanced-project-settings) page in the CCS User's Guide. ##CCS Post-build/Pre-build Steps errors ###tiobj2bin.bat failed on ofd470 If your pre-build or post-build step command is split into multiple lines, it will generate an error. For example, if the tiobj2bin command is split as shown below, then the following error message would appear at build time. ![](./images/postbuildtiobj2bin.png) <pre> "C:/ti/ccsv6/utils/tiobj2bin/tiobj2bin" "Test1.out" "Test1.bin" tiobj2bin.bat failed on ofd470 Please see https://processors.wiki.ti.com/index.php/Tiobj2bin_Failed tiobj2bin.bat failed on hex470 Please see https://processors.wiki.ti.com/index.php/Tiobj2bin_Failed '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 "C:/ti/ccsv6/tools/compiler/ti-cgt-arm_5.2.5/bin/armhex" error: failed to read "C:/ti/ccsv6/utils/tiobj2bin/mkhex4bin" </pre> To fix the issue, check the post-build/pre-build steps and make sure the complete command is in a single line. ##Useful Object File Utilities There are several utilities that are useful for analyzing object files and executables as well as for debugging build issues. Some are included with the compiler toolset and some are part of the **[Code Generation Tools XML Processing Utilities](sdto_cgt_cg_xml_overview.html)** (cg_xml) which is a separately down-loadable package of Perl scripts that can be used to process the output from the code generation tools. Some examples: - The **object file display (ofd)** utility (included in the compiler tools) 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](https://www.ti.com/tool/TI-CGT#technicaldocuments). These utilities can be run stand-alone from a command prompt or added as a post-build step in CCS. - The **objdiff** utility (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. More information on this utility and others in the cg_xml package can be found in the getting_started.txt and index.htm files in the cg_xml installation directory. ###Binary Comparison At build time, the compiler includes timestamp and file path information to the output file. As a result, builds performed at different times by users that have different file paths will not be bit-exact or have matching CRCs. For the project path, this is usually stored in the debug information. You can use the **strip** utility (included in 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. There is no way 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. ##References This page describes a few other common diagnostic messages: [Compiler diagnostic messages](https://processors.wiki.ti.com/index.php/Category:Compiler_diagnostic_messages) This page lists some common diagnostics for C2000: [C28x Compiler Error and Warning Messages](c2000_c28x-compiler-error-and-warning-messages.html)  <div id="footer"></div>