Can't get XDS100v2 to connect to target from CCS 6.1

Hi,

The errors you mentioned are indeed strange; I wonder if something bad happened during the CCS installation. I am able to connect to my board here:

How are you connecting to the board? The XC5777X board does not have built-in XDS100 JTAG circuitry, requiring you to have an external JTAG debugger and an adapter.

Hope this helps,

Rafael

Rafael,  My connections look just like your photo.   I do see that we have different switch settings on the SW5 USERCONFIG.  I have only 4 & 5 on where you have 3 & 5 on.  I have no reference for the switch meanings, but I tried your setting and it didn't make a difference.

I am going to try this on a Beagle board I have and make sure it still works there. That is what I got the XDS100 with a couple of years back.

Scott,

Sorry to throw you off. Irrespective of the connection, the error with the <jtagdata.dll> is really bugging me.

I have suspicion that a Microsoft library is not installed and I wonder if you are hitting this. Can you try one thing?

The utility Dependency Walker scans through the dependencies of a given file and shows if there is anything missing. Can you download it from its official website and run it on the jtagdata.dll file? If everything is correct, you should see something similar to this:

My suspicion is the highlighted DLL above (MSVCR120.DLL) is missing from your system.

If that is confirmed, you may have to install the Visual C++ 2013 Runtime package separately.

Regards,

Rafael

I also have the problem with CCS 6.1.1 on WIN7 an nothing I found in this forum or on google helped.

Just a stupid idea:

Just saw this 8.3 filename format in the path to the boarddata.

Could this be an issue?

(My value for NtfsDisable8dot3NameCreation in the registry is 2)

Here the output of my dependeny walker in case this should help

jtagdata.zip

No, still no real fix.  I can't get either an XDS-100 or -200 running on one machine, but both run on another identical machine.  I got a reply saying it was added to the bug list, but I haven't heard about a fix.  Strangely it appears to be some kind of permissions problem related to creating a local file.

I guess because this question is marked as aswered TI staff dont really bother if there is activity here.

For me only a fresh install of WIN7 did help.

Before that I tried things like processors.wiki.ti.com/index.php/Troubleshooting_CCSv5 and other

things I dont remember.

One thing I remember that I monitored ccstudio.exe whith procmon from sysinternals

on a functioning system and on my machine.

On my machine the string "ccBoard0.dat" could be found only once in an reading context.

On the funtioning machine the creation of "ccBoard0.dat" could also be observed.

Another interesting thing was that the folder

..\AppData\Local\Texas Instruments\CCS\ti\0\0\BrdDat was

recreated on every attempt to start the debugger bit the folder was

empty after that (no ccBoard0.dat)

I also found it remarkable that the error messge had 8.3 filename format in the path to the boarddata.

..\AppData\Local\TEXASI~1\CCS\ti\0\0\BrdDat\ccBoard0.dat

and I posted the question if this could be an issue but there was no answer.

Juergen Rothbaecher said:

I also found it remarkable that the error messge had 8.3 filename format in the path to the boarddata.

..\AppData\Local\TEXASI~1\CCS\ti\0\0\BrdDat\ccBoard0.dat

and I posted the question if this could be an issue but there was no answer.

Is it possible that the "8.3 short file name support" was disabled during the installation of your Win7 OS?  Please see this post where another user confirmed that reinstalling Win7 with "8.3 naming schema" enabled resolved a similar issue for them. Could you please check into this and confirm if your issue is related? If so, we will make sure to capture this information in an FAQ.

All I know is that my value for NtfsDisable8dot3NameCreation in the registry after the installation was 2.

I cant say how it was before or at win7 installation time.

BTW

I just foud out If I do

>echo > 123456789ABCDEFGH.txt

and then

>dir /X 1*

the result is

...

12.11.2015  09:57                30 123456~1.TXT 123456789ABCDEFGH.txt

...

so maybe 8.3 is not the issue for me.

This issue still exists.  I have now updated the machine to Windows 10, uninstalled and reinstalled CCS 6.1.1 and have the same problem.  I have attached a doc containing two image clips.  I couldn't get them to add directly to this post.

Dependency Walker is reporting an error, but I don't understand.  It does not look like the  MSVCR120.dll is missing.

Scott

TI1.docx

With CCS 6.2 an additional Info is displayed:

"%1 is no valid Win32-Application"

Whatever %1 should meant to be :)

@Scott: Do you get the same difference if you update to CCS 6.2?

I don't remember if it was on 6.1 or 6.2,  but I have definitely run into that problem.  For me that was a project configuration issue.  The compiler was not defined in the project so the local environment variable for the compiler was NULL and the % 1 could not be resolved.

Scott

Regarding msvcrt120.dll I found some differences betweeen a functioning and a nonfunctioning PC when searching for the file in the windows directory.

On the nonfunctioning system it could be found only once on the funtioning twice (system32 and syswow64).

Unfortunately I was a little to eager and uninstalled all visual c++ redistributable packages.

Anyhow the kind of error changed when I reinstalled visual c++ 2013 redistributables and I was at least able to do a succesful "test connection" from the target configuration page. I'm still not able to establish a real Debugging session though.

Now the error message is like: "Unable to load .....\tixds510icepick_d.dvr: %1 ... no valid win32 app".

Strange: If enabling Debug Server Log from Help->Support it looks like this

The addional info changes to "The transaction completed successfully" (translated).

Maybe reinstalling only the Visual c++ 2013 redistributables (which contain msvcr120.dll) could help for this problem.