Troubleshooting CCS

From Texas Instruments Wiki
Revision as of 20:58, 8 March 2012 by John (Talk | contribs)

Jump to: navigation, search


This guide provides some suggestions for CCSv4 users experiencing odd generic issues not covered in FAQs or other topics and having difficulty to reproducing in other environments (creating a reproducible test case for to provide to support). It also describes how to find/generate additional diagnostic logs that will be useful to provide to TI support when reporting an issue.


  • For failure during installation (CCS installer fails to complete), try removing all files under the InstallJammer registry folder for CCS.
  • Note that the folder is a hidden directory so you may need to type the full path into windows explorer

The path to the folder is:


C:\Program Files\InstallJammer Registry\ccsv4 or Program Files (x86)

Try deleting the entire 'ccsv4' folder.


C:\Program Files\InstallJammer Registry\ccsv5 or Program Files (x86)

Try deleting the entire 'ccsv5' folder.

  • For errors in startup script like the following, make sure to extract the installer zip file into a temporary folder and then run the setup.exe rather than installing it directly "on-the-fly".
Error in action ExecuteScript 
 can't read "fileList": no such variable 
    while executing 
"::InstallJammer::actions::$component $this" 
    while executing 
   (procedure "::InstallJammer::ExecuteActions" line 62)
    invoked from within
"::InstallJammer::ExecuteActions "SetupActions""
    (procedure "::InstallJammer::ParseCommandLineArguments" line 142)
    invoked from within
"::InstallJammer::ParseCommandLineArguments $::argv"
    (procedure "::InstallJammer::InitInstall" line 62)
    invoked from within 
    (file "/installkitvfs/main.tcl" line 64456)

General IDE

CCSv4 is based on the Eclipse open source framework and when experiencing various odd/corrupted behavior (missing menu options, "blank" views, plug-ins are missing or no longer behave properly, random crashes, etc), common tips on cleaning up your Eclipse environment also apply to CCSv4. Some of these tips are:

1. Reset the perspective: If the issue is strange GUI appearance (missing menu options or strange/empty looking views), often just resetting the perspective can resolve this. This can be done by selecting 'Window->Reset Perspective'

2. Use the -clean argument when calling eclipse.exe: CCSv4 is launched by running the '.\ccsv4\eclipse\eclipse.exe' executable. This is what is called when using the CCSv4 desktop shortcut. However, eclipse.exe can be called with some command line arguments. One of them is '-clean'. When calling 'eclipse.exe' with '-clean', it will clean out cached data by the IDE and plug-ins upon launching CCSv4. Sometimes this cached data can get corrupted over time and cleaning it out can fix many problems. Note that launching CCSv4 with '-clean' will cause the launch time to be slower so it is not recommend to use it every time but only when needed

3. Clean the workspace (or try using a new one): CCSv4 stores various information in a folder called '.metadata' located in the user's workspace. The contents of this folder can get corrupted over time, causing various instability and strange behavior. Using a new workspace or cleaning the old workspace often helps resolve these issues. To use a new workpspace, simply select a new workspace location ('File->Switch Workspace'). If you wish to clean the old workspace, the simplest way to do this is to delete the '.metadata' folder in the workspace. This will essentially reset the workspace and restore the environment to the default behavior. All projects that were in the workspace will need to be re-imported into CCSv4, even though they are still physically in the workspace folder. Also note that any modified preference settings will be lost (set back to the default setting). If you wish to avoid resetting those preferences, export the preferences to a file (outside the workspace) by selecting 'File->Export...->General->Preferences->To preference file' before deleting the workspace. Once the workspace has been cleaned, those preferences can be imported back into CCSv4 by selecting 'File->Import...->General->Preferences->From preference file'


For issues encountered during a debug session (launching a debug session, target connectivity issues, crashes experienced during debugging). Note that cleaning the workspace can also help resolve debugger issues.

1. For JTAG specific issues, see: Debugging JTAG Connectivity Problems

2. Delete the debug "launch": A launch is something that Eclipse creates when a debug session is started; it caches the information on which target configuration to use, debug settings…

  • Select "Target->Debug…"
  • Under "Project Debug Session" (or "Non-Project Debug Session" if the launch is not associated with a project) select the name of your launch configuration and delete it.

3. Delete target cache files:

  • CCS 4.1.1 and earlier:
    • Delete your target configuration ccxml cache files: If you are having problems starting a debug session or not seeing updates made to peripheral xml files showing up in the 'Registers' view, try removing the two ccxml cache files (*.cache and *.cache2). The cache files are found in the same location as your ccxml file. The ccxml file is usually saved either in your project folder or in "C:\Documents and Settings\<Your login id>\user\CCSTargetConfigurations\".
    • Delete the target database cache file: This may help resolve issues with starting a debug session. The file is called 'targetdb.dat' and is located under "<CCS Install dir>\ccsv4\common\targetdb\"
  • CCS 4.1.2 and greater:
    • Cache files are saved in a user and CCS installation specific location. On Windows the location will typically be "C:\Documents and Settings\<Your Login ID>\Local Settings\Application Data\.TI". On Linux, look under the ~/.TI. The contents inside the .TI folder can be deleted.  On Windows 7 the location is C:\Users\<username>\AppData\Local\.TI\
    • There may also a targetdb.cache file in <CCS Install Dir>\ccsv4\DebugServer\bin\win32 that can be deleted.

Information for Support

  • Before posting a support question, please include the information below in the post. This will allow support to quickly diagnose the problem and resolve it quickly. For attachments, a single zip file can be attached via the "options" dialog of the forum post.
  1. A clear problem statement. Reproduce the problem, noting what steps were performed in what order. Include screen shots, photos, diagrams, etc. as needed to help someone recreate the problem or see what the problem looks like. Tip: Analysis is easier if the problem can be reduced to a simple test case which can be run on a TI DSK/EVM. This allows the engineers to reproduce and examine the problem in the lab.
    1. Ex: (good problem statement)
      1. I am trying to connect to an C2812 with an XDS100v2 emulator. After starting CCS v4.1.1, I click "debug" and I get "Error initializing emulator."
    2. Ex: (bad problem statement)
      1. I can't connect to the target. (Note: This could be improved if the steps used to get to the problem were included)
  2. Prepare a summary of your environment with the information below:
    1. Screenshot of error message
    2. CCS Version: (get from Help->About)
    3. CCS Installation directory:
    4. Setup Configuration .CCXML file for configuration being used (found in the "<user name>\user\CCSTargetConfigurations" directory):
    5. Setup Configuration ccBoard0.dat file (found in \ccsv4\DebugServer\bin\win32\BrdDat)(Please make sure it is saved after failure.) (optional):
      1. If using Spectrum Digital emulators, “sdopts.cfg” file located in Windows\System32 and is generated by sdconfig:
    6. Any GEL files used for each CPU (optional, mandatory if customized by user):
    7. If Simulator - Simulator board name
    8. Chip Part Number and revision:
    9. Target Board Manufacturer:
    10. Target board part #:
    11. Target board revision #:
    12. Target connector used (ex: 14 pin TI JTAG):
    13. If customer board, please provide schematic, chips in the scan chain for the JTAG scan chain (up to and including resistors, FETS, etc. that are in the scan chain):
    14. Picture of target board (optional):
    15. Host Operating System:
    16. Host Operating System Version:
    17. Host Operating System Service pack:
    18. Host Operating System bits (32-bit or 64-bit)
    19. Emulator Board Manufacturer:
    20. Emulator model # (ex: XDS560, XDS100v1, XDS100v2, 510USB+, etc.):
    21. Emulator connector used (ex: 14 pin TI JTAG):
    22. Emulator adapter used (ex: TI 14 pin emulator to 20 pin ARM target, 14 to 14 pin isolation adapter, etc.):
  3. CCS Diagnostic Logs (as described Troubleshooting CCS#CCS_Diagnostic_Logs):
    1. Eclipse Error Log:
    2. JVM Error Logs:
    3. Debug Server Logging:
  4. Output from the tests specified in Debugging JTAG Connectivity Problems
    1. Scan Path Length Test:
    2. Broken Path Test:
    3. Integrity Test:
    4. If you are using Spectrum Digital emulators, please see these instructions
  5. Additional information for XDS560 Trace users
    1. If XDS560 Trace Connectivity Issues (Failure to initialize XDS560 Trace type of problems)
      1. Screenshot of the XDS560 Trace Receiver settings (from Tools->Trace Control):
      2. Turn on trace logging XDS560TRACE FAQ#How_can_I_turn_on_Logging_for_Trace_for_TI_support.3F
    2. If XDS560 Trace functional problems (Trace output is incorrect, not as expected, etc.)
      1. Zip file of Trace Analyzer/Display TDF file
      2. Application .OUT file (optional)
      3. Screenshot of the issue
    3. If CToolsLib is used provide:
      1. Compiler version used:
      2. Compiler command line flags and settings
      3. CToolsLib version of the target content library:
      4. Source example and project to reproduce problem

CCS Diagnostic Logs

If you are still unable to resolve your issue, you can contact TI support for help. In addition to the usual information, providing the following additional diagnostics logs can help support personnel in their investigations:

  • Install Logs
  • Eclipse/JVM Error Logs
  • Crash Dump Files
  • Debug Server Logs
  • cTools/Trace Logs

For versions of CCS 4.2.2 and greater, there is a utility that will automatically grab the above logs except the cTools/Trace Logs. This utility is accessible via 'Help->CCS Support Activities' menu. This will launch the CCS Support dialog:

CCS Support Dialog

From the above dialog are options to view various logs ('View' button), e-mail to support ('Email...'), clear the log ('Clear') and to enable logging ('Properties...'). Only the Debug Server Log is not enabled by default. To enable it, highlight it and click on Properties, check the box to 'Enable Debug Server Logging' and specify a location to save the log file. There is also a button to 'Archive Logs...'. This will zip up all the enabled logs to a location on your PC. This zip file can then be e-mailed or attached to the CCS support forums.

If you are using a version of CCS older than 4.2.2, you will have to manually find the logs. Locations of the logs are below:

Install Logs

For installation errors, provide the install logs:

  • CCSv3: 'TI_InstallLog.txt' in the root of your system drive
  • CCSv4: 'TI_CCSv4_Install.log' located in C:\Program Files\InstallJammer Registry\ccsv4\D….\?
    • Note: the directory InstallJammer Registry has the hidden attribute turned on. You must enable the display of hidden files and folders in Windows Explorer to access it (XP or Vista and 7).
  • CCSv5: 'TI_CCSv5_Install.log' located in C:\Program Files\InstallJammer Registry\ccsv5\6….\? (See note about hidden files above.)

Eclipse Error Log

  • Open the Error Log view (View->Other->PDE Runtime->Error Log) and export the log to a text file.

JVM Error Logs

  • JVM error logs are generated somewhere inside '<INSTALL DIR>\ccsv4' folder. It is recommended to do a recursive search inside that directory for *.log files. JVM error logs will look something like 'hs_err_pid<some number>.log' (for example: hs_err_pid4044.log) ).

Crash Dump File

  • CCSv4.1.2 and older: Crash dump files can be found in '<INSTALL DIR>\ccsv4\DebugServer\win32\components\Log' and have a *.dmp extension
  • CCSv4.1.3 and newer: Crash dump files placed in a directory named .TI in the user area and it is recommended to do a recursive search inside that directory for *.dmp files. Typical locations are:
Windows XP systems
C:\Documents and Settings\<username>\Local Settings\Application Data\.TI
Windows Vista and 7 systems:
This change is required to accomodate the requirements of Windows Vista and 7 that prevent access to sensitive areas of the system.

Debug Server Logging

  • Additional diagnostic logs can be generated by the debugger. This is NOT enabled by default. Enabling Debug Server Logging will slow overall CCS performance, so it is not recommended to leave logging enabled. If you are unable to provide a reproducible test case to TI support, you can enable debug server logging to generate additional diagnostics logs. These logs will only be useful for issues related to the debug server (ex: can't connect to the target, debugger hangs, etc) and useless for other issues like project management or the editor. To generate enable debug server logging on Windows:
  1. Download and unzip this program from Microsoft: DbgView
  2. Open a DOS command window (i.e. 'cmd' from the windows start->menu).
  3. Change directories to <ccs_install_dir>/ccsv4/eclipse
  4. Set environment variable TI_DS_ENABLE_LOGGING=1
  5. Start 'eclipse.exe' from the command window
  6. Start the 'dbgview' program
  7. Launch a debug session as before and wait for the launch to complete. You should see a lot of data inside the 'dbgview' window.
  8. Save the log. Go to menu File --> Save As...

To generate enable debug server logging on Linux using bash:

  1. Open a terminal window and change directories to <ccs_install_dir>/ccsv4/eclipse
  2. Set environment variable TI_DS_ENABLE_LOGGING=1
  3. Set environment variable TI_DS_LOGGING_OUTPUT=<path to log file>
    export TI_DS_LOGGING_OUTPUT=/tmp/dslog.txt
  4. Start 'eclipse' from the command window

Logging data from the debugger can get very large, so it may be desirable to only enable capture from DbgView just before the event of interest is being exercised. On Widows, after the event has occurred, the log can be saved to a text file from DbgView, zipped, and sent to TI support or attached to the relevant forum post.

  • You can also enable logging from within CCS by entering eval("DEBUG_LogEnable(1)") in the Scripting Console

cTools/Trace Logging

  1. Quit CCS.
  2. Right click on the “MyComputer” icon on your desktop.
  3. Select “Properties”.
  4. On XP select System Properties, in Win7 click on "Advanced System Settings"
  5. In the System Properties dialog, click on the “Advanced” tab. (should already be selected in Win7)
  6. Click on the “Environment Variables” button. In the “Environment Variables” dialog
  7. Under the “User variables” group, verify that the “TI_TRACE_LOGGING” environment variable exists and has a value of 6. Create it if it is not there.
  8. Click “OK” in all dialogs. Restart CCS.
  9. Reproduce the problem, noting what steps were performed in what order.
  10. Zip up the log file and send it to TI via the forums. The log file will be in /ccsv4/emulation/analysis/bin/Logs/ (WinXP) or /users/<userid>/.TI-trace (Win7). The file name will be something like: ti_trace_log_MMDDYY_PID.txt file.