Hi,

Try switching to a new workspace...

Debugger

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.

• For JTAG specific issues, see: Debugging JTAG Connectivity Problems

• If a data verification error occurs when loading a program, see: Troubleshooting_CCS_-_Data_Verification_Errors

• Delete the debug launch configuration: A launch configuration is a configuration file that Eclipse creates when a debug session is started; it caches the information on which target configuration to use, target options and several other settings.

Go to menu "Run-->Debug Configurations..."

Under "Code Composer Studio - Device Debugging", select the name of your launch configuration and delete it.

• Delete target cache files:

Cache files are saved in a user and CCS installation specific location.

On Windows XP the location is: C:\Documents and Settings\<Your Login ID>\Local Settings\Application Data\.TI

On Windows 7 the location is: C:\Users\<username>\AppData\Local\.TI\

On Linux, there is a hidden directory named .TI and located in the user area. The location is ~/.TI

• If you also have a installation of CCSv3.3 and have CCSv3.3 directories in the system PATH, try removing those directories from the PATH. There is a known issue where CCSv5 will pick up the wrong DLLs from the CCSv3.3 installation if the CCSv3.3 directories are found in the PATH.

Hi Gautam,

thank you for your quick response! I had a look on the posted references and tried several things to get a hint for the issue with the CCS crash. Unfortunately without any success so far...

1) cleaning the currently used workspace by removing the directory ".metadata"
2) creating a new workspace with the same projects
3) starting CCSv5 with the "-clean" flag to clean out any cached data
4) removing manually cached data from the user specific directories "C:\Users\<username>\.TI\", "C:\Users\<username>\.TI-trace\", and "C:\Users\<username>\AppData\Local\.TI\"
5) I checked for the debug configuration settings, but I don't use a debug configuration since I'm always starting the debugging manually. But anyway it makes no difference if I start a debug session with a specific configuration or manually - the behaviour remains the same...
6) I verified that the emulator driver is installed correctly under Windows (device manager)
7) I tested the emulator functionality with the "SDConfig" tool as described on the troubleshooting guide from the emulator manufacturer "Spectrum Digital", but all tests passed Ok
8) to identify any troubles with the emulator or the JTAG configuration I started a connection test out of the target configuration file <project>.ccxml > tab "Basic" > Button "Test Connection" with the following result:

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag.exe -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\swi\AppData\Local\.TI\693494126\
    0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'sd560v2u.out'.
Loaded FPGA Image: C:\ti\ccsv5\ccs_base\common\uscif\dtc_top.jbc
The library build date was 'Aug 19 2013'.
The library build time was '22:41:20'.
The library package version is '5.1.229.0'.
The library component version is '35.34.40.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
The cable+pod has a version number of '8' (0x00000008).
The cable+pod has a capability number of '7423' (0x00001cff).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

The scan-path will be reset by toggling the JTAG TRST signal.
The controller is the Nano-TBC VHDL.
The link is a 560-class second-generation-560 cable.
The software is configured for Nano-TBC VHDL features.
The controller will be software reset via its registers.
The controller has a logic ONE on its EMU[0] input pin.
The controller has a logic ONE on its EMU[1] input pin.
The controller will use falling-edge timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '2' (0x0002).
The utility logic has not previously detected a power-loss.
The utility logic is not currently detecting a power-loss.
Loaded FPGA Image: C:\ti\ccsv5\ccs_base\common\uscif\dtc_top.jbc

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

  Test  Size   Coord      MHz    Flag  Result       Description
  ~~~~  ~~~~  ~~~~~~~  ~~~~~~~~  ~~~~  ~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~
    1   none  - 01 00  500.0kHz   -    similar      isit internal clock
    2   none  - 01 09  570.3kHz   -    similar      isit internal clock
    3    512  - 01 00  500.0kHz   O    good value   measure path length
    4    128  - 01 00  500.0kHz   O    good value   auto step initial
    5    128  - 01 0D  601.6kHz   O    good value   auto step delta
    6    128  - 01 1C  718.8kHz   O    good value   auto step delta
    7    128  - 01 2E  859.4kHz   O    good value   auto step delta
    8    128  + 00 02  1.031MHz   O    good value   auto step delta
    9    128  + 00 0F  1.234MHz   O    good value   auto step delta
   10    128  + 00 1F  1.484MHz   O    good value   auto step delta
   11    128  + 00 32  1.781MHz   O    good value   auto step delta
   12    128  + 01 04  2.125MHz   O    good value   auto step delta
   13    128  + 01 11  2.531MHz   O    good value   auto step delta
   14    128  + 01 21  3.031MHz   O    good value   auto step delta
   15    128  + 01 34  3.625MHz   O    good value   auto step delta
   16    128  + 02 05  4.313MHz   O    good value   auto step delta
   17    128  + 02 13  5.188MHz   O    good value   auto step delta
   18    128  + 02 23  6.188MHz   O    good value   auto step delta
   19    128  + 02 37  7.438MHz   O    good value   auto step delta
   20    128  + 03 07  8.875MHz   O    good value   auto step delta
   21    128  + 03 15  10.63MHz   O    good value   auto step delta
   22    128  + 03 1E  11.75MHz  {O}   good value   auto step delta
   23    512  + 02 3E  7.875MHz   O    good value   auto power initial
   24    512  + 03 0E  9.750MHz   O    good value   auto power delta
   25    512  + 03 16  10.75MHz   O    good value   auto power delta
   26    512  + 03 1A  11.25MHz   O    good value   auto power delta
   27    512  + 03 1C  11.50MHz   O    good value   auto power delta
   28    512  + 03 1D  11.63MHz   O    good value   auto power delta
   29    512  + 03 1D  11.63MHz   O    good value   auto power delta
   30    512  + 03 13  10.38MHz  {O}   good value   auto margin initial

The first internal/external clock test resuts are:
The expect frequency was 500000Hz.
The actual frequency was 499110Hz.
The delta frequency was 890Hz.

The second internal/external clock test resuts are:
The expect frequency was 570312Hz.
The actual frequency was 569976Hz.
The delta frequency was 336Hz.

In the scan-path tests:
The test length was 16384 bits.
The JTAG IR length was 6 bits.
The JTAG DR length was 1 bits.

The IR/DR scan-path tests used 30 frequencies.
The IR/DR scan-path tests used 500.0kHz as the initial frequency.
The IR/DR scan-path tests used 11.75MHz as the highest frequency.
The IR/DR scan-path tests used 10.38MHz as the final frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

The frequency of the JTAG TCLKR input is measured as 10.37MHz.

The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
The target system likely uses the TCLKO output from the emulator PLL.

-----[Perform the standard path-length test on the JTAG IR and DR]-----------

This path-length test uses blocks of 512 32-bit words.

The test for the JTAG IR instruction path-length succeeded.
The JTAG IR instruction path-length is 6 bits.

The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 1 bits.

-----[Perform the Integrity scan-test on the JTAG IR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG IR Integrity scan-test has succeeded.

-----[Perform the Integrity scan-test on the JTAG DR]------------------------

This test will use blocks of 512 32-bit words.
This test will be applied just once.

Do a test using 0xFFFFFFFF.
Scan tests: 1, skipped: 0, failed: 0
Do a test using 0x00000000.
Scan tests: 2, skipped: 0, failed: 0
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 0
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 0
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 0
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 0
All of the values were scanned correctly.

The JTAG DR Integrity scan-test has succeeded.

[End]

Now I'm running out of ideas - did I forget anything that I could still test or verify?

Kind Regards

Hi Stephane 

Sorry about the issue you are having. We have received the logs from you and the issue seems to be related to Trace server component in CCS. Unfortunately, we are struggling to reproduce the issue locally and trying to characterize the issue using the crash logs you have sent.  

If you are not using any hardware trace/profiling features, there is a work-around until there is a fix ready (possibly in next 2-3 weeks).  

The work-around is to rename TraceServer.exe file in CCS_INSTALL_DIR\ccsv5\ccs_base\emulation\analysis\bin directory. Once you rename the file, you can launch and use the CCS. Again, this work-around is only valid if you are not using hardware trace functionality in CCS.

Please let me know if this helps until we have the fix posted.  

Hi Vikas,

thank you for the answer - unfortunately, the mentioned work-around did not help. I renamed the "TraceServer.exe" and tried several times to run a debug session, but the behavior is still the same. Each time I stop the debug session CCS crashes...

I observed the situation a bit and found out some more details that may be helpful for your investigations:

1) in the "CCS edit perspective" I always have a window open for the target configurations -> Window > Show View > Target Configurations. To start a debug session I do a right click on the target configuration file "<project>.ccxml", which is visible in this window, and then I click on the context menu item "Launch Selected Configuration". After a short moment CCS switches to the "CCS debug perspective" and the debug session is open and running. If I stop the debug session now without doing any connection to a processor core, the CCS terminates the debug session and comes normally back to the "CCS edit perspective" without crashing - but the target configurations window is gone / closed.

2) if I start a debug session and I connect at least once to any processor core, than I can be sure that CCS will crash as soon as I try to stop the debug session. Even if I do a proper core reset and disconnect...

Note: starting the debug session by means of a target configuration or a debug configuration makes no difference for the two depicted scenarios.

Please let me know if I can or should do any other test to get more information on the root cause of this issue.

Kind Regards,

Stéphane

Hi Vikas,

thank you for the reply - glad to hear that!

I tried renaming the "IceCD.dll" and it works now! I can stop the debugger without crash. Cool!

Thank you a lot for your help!

Regards