• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 1068 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Connect to target on C6678 fails in CCS 5.2 with Blackhawk USB560 emulators

OyvindV
Prodigy 110 points
Other Parts Discussed in Thread: CCSTUDIO, TMS320C6678

We are experiencing problems with JTAG debugging on C6678 using Blackhawk USB560 emulators.

The problems appear when using CCS v5.1 and newer, forcing us to use CCS v5.0.3 beta for in-circuit debugging.

The setups that fails:
Windows XP sp3 32-bit, or Windows 7 64-bit
CCStudio v5.1.0.09, v5.1.1.31 or v5.2.1.18
Emulators:
Blackhawk USB560m with BH-ADP-20e_cTI-60t_TI pin converter, or USB560v2 with BH-ADP-60e_MIPI-60t_TI pin converter
Boards:
TMDXEVM6678L, or our own custom hardware using C6678.

A full CCS 5 license is provided from a license server.

All these combinations of Windows, emulator and target work relatively "flawless" with CCS v5.0.3, except that this is an unsupported, unfinished beta version.

To reproduce, start with a fresh install of e.g. CCS v5.2. Then install all available updates using "Help/Check for updates".
This step would install the latest Blackhawk drivers, as adviced.

Open the target configurations window, create a new config. Select "Blackhawk USB560-M Emulator, 20-pin JTAG Cable"
(or "Blackhawk XDS560v2-USB System Trace Emulator" if used) for connection, and TMS320C6678 for device. Leave all settings as default. Save the configuration.

Clicking the "Test Connection" tool in the target config window, results in a successful verification of the JTAG scan chain, so there seems to be no fundamental problem with the emulator connection.

Launch the newly created target configuration. This step seems to work, as all 8 cores of the C6678 appear in the Debug window in (Disconnected: Unknown) mode.

The problem appears when running "Connect Target" on e.g. Core 0/C66xx_0. "Executing Connect Target" appears in the progress bar in the right bottom corner of the screen, and stays there for a long time. When clicking anywhere inside the CCS window, the progress bar stops moving and the entire application freezes and eventually silently exits.

The Java Error log (hs_err_4996.log) reports:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c00249f, pid=4996, tid=3620
# The crash happened outside the Java Virtual Machine in native code.
# Problematic frame:
# C 0x7c00249f
# See problematic frame for where to report the bug.

Has anybody experienced any similar problems, or do we have a unique situation here?

A common denominator for all computers this has been tested on is that CCS 3.3 has been installed with Blackhawk drivers prior to installing CCS 5. I am soon getting a new computer where I will try a fresh install of CCS 5 without any other TI/Blackhawk software previously installed.

See the attached .zip file for all debug logs. The 'ccBoard0.dat' file is missing, as it could not be found in the specified directory, but the result of the JTAG chain test is provided.

Hope we can sort this out soon, as we are approaching production code development.

Regards, Oyvind

2012_08_01_TI_CCS_debug_logs.zip
  • 0
    TI__Genius 16510 points

    Thank you for the very detailed and complete description of the problem!

    In looking at the attached files, I can see that CCS v5 is loading DLLs from the CCSv3.3 folder. To prevent this from please there are several options. If you not using CCSv3.3, it could be removed or the folder renamed to something else. If you are using it, please edit the PATH environment variable to remove the CCS3.3 components from the PATH before starting v5.2.

  • 0 in reply to AndyW
    Prodigy 110 points

    Thank you for your swift answer, Andy!

    I just removed the "c:\CCStudio_v3.3\cc\bin" folder from my PATH, then everything seems to work as expected!

    May I ask in what file you found the info about the old .dll? If something similar comes up again...

    Although this resolves our problem, it would be nice if CCS 5 was more friendly towards older versions of itself. No big thing - as it works now - but a small notice in the release notes or user manual may be appropriate so that loyal customers don't need to spend too much time fiddling with these things when they update to a newer software. As we all know, for supporting old products you need to have both old and new tools installed at the same time, so this scenario should not be that uncommon. 

    But, again, thanks for the quick answer!

    Regards, Oyvind

  • 0 in reply to OyvindV
    TI__Genius 16510 points

    Oyvind,

    I agree with everything you mention and sorry for the trouble with this. A bug report was recently filed for this issue and I hope it will be addressed in the next CCS release.

    For your information, the .dmp file contains the full path of all loaded modules for that process space. The .dmp file is a Microsoft "minidump". By looking at what DLLs were loaded, I could see there was one loaded from a different install folder.