"Debug Active Project" fails to launch (when it previously succeeded)

Walter Snafu

Other Parts Discussed in Thread: TMS320C6748

My CCS "Debug Active Project" command fails to launch, under circumstances identical to when it previously succeeded.

Details:

Console Report:

C674X_0: File Loader: Data verification failed at address 0xC0074600 Please verify target memory and memory map.
Error found during data verification.
Ensure the linker command file matches the memory map.

Comment: The target memory, memory map, and linker command file are all identical to when the system worked previously. Nothing changed, except now the "Debug Active Project" fails to launch. It does successfully connect to the target board, so I can view the CPU registers, etc.

Possible Clues?

The problem showed up after an unclean startup/shutdown of CCS. Perhaps this confused it somehow?

So, I tried rebooting everything, plus deleting the .metadata file and re-importing my project. But that didn't solve the problem.

The debugger still allows me to view the CPU registers, etc.

The debugger allows me to poke data into CPU memory. However, it fails to poke data into the external memory on the SOM module. This is the same memory mentioned in the console report above: 0xC0074600 (The external memory ranges from address 0xC0000000 to 0xC8000000.)

I'm using CCS v4.2.3.00004. Windows XP. TI XDS100v2 USB emulator on an embedded system that uses the LogicPD C6748 SOM.

over 14 years ago

0 Walter Snafu over 14 years ago

Genius 3450 points

Here are more clues:

My board configuration file makes reference to version 1 of the XDS100 emulator. That is weird because my target configuration file specifically calls out version 2 of that emulator. ???

The file is exactly where your FAQ said it would be,
in C:\Program Files\Texas Instruments\ccsv4\DebugServer\bin\win32\BrdDat\
It's filename is ccBoard0.dat, and it is the only file in that directory.

Going on a hunch (based on my previous experience), I then deleted the debugger cache files, by using menu command Target->Debug and then deleting all files under Non-Project Debug Session and Project Debug Session. This did not solve the problem. So I tried again, this time going to the directory cited below and deleting all files whose names end in ".cache" This did not solve the problem.

C:\Documents and Settings\<user>\user\CCSTargetConfigurations

Here is my board configuration file:

# config version=3.5
$ sepk
pod_drvr=jioserdesusb.dll
pod_port=0
$ /
$ product
title="Texas Instruments XDS100 USB"
alias=TI_XDS100v1_USB
name=FTDI_FT2232
$ /
$ ftdi_ft2232
usb_vid=0x0403
usb_pid=0xa6d0
gpio_l0="TRSTn,Active_Low"
gpio_l1="EMU_Pin_Enable,Active_Low"
gpio_l2="EMU_Pin_0,Active_Low"
gpio_l3="EMU_Pin_1,Active_Low"
gpio_h0="SRSTn,Active_High"
gpio_h1="SRSTn_In,Active_Low"
gpio_h2="Power_Loss_Detect,Active_Low"
gpio_h3="Power_Loss_Reset,Active_High"
$ /
$ uscif
tdoedge=FALL
jtagboot_mode=disable
jtagboot_value=hiz
powerboot_mode=disable
powerboot_value=hiz
tclk_program=SPECIFIC
tclk_frequency=1.0
$ /
@ icepick_c family=icepick_c drbits=1 irbits=6 subpaths=1
& subpath_0 address=17 default=no custom=no force=yes pseudo=no
@ c674x_0 family=tms320c674x drbits=1 irbits=38
& /
# /

Here is my target configuration file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator_0" href="connections\TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator_0" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator_0">
            <instance XML_version="1.2" href="drivers\tixds100v2icepick_c.xml" id="drivers" xml="tixds100v2icepick_c.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers\tixds100v2c674x.xml" id="drivers" xml="tixds100v2c674x.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320C6748_0" href="Devices\c6748.xml" id="TMS320C6748_0" xml="c6748.xml" xmlpath="Devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

0 Walter Snafu over 14 years ago in reply to Walter Snafu

Genius 3450 points

By process of elimination, I'm starting to suspect my XDS100v2 emulator may have gone belly-up. But belly-up in a peculiar manner. That is, this emulator allows me to connect to the target board, where I can view and poke values into the CPU registers and its memory, but I cannot access the off-chip memory (the external memory of the SOM). I've tried several different boards where everything worked previously, and now the same problem occurs when attaching to any of the three boards. The common denominator for the problem is CCSv4 and the XDS100v2 emulator -- and I am now starting to suspect the latter.

Is there a test I can do that will detect whether the emulator is bad?

I'm still trying to find a solution.

0 Ki over 14 years ago in reply to Walter Snafu

TI__Guru**** 472291 points

Hi Walter

I believe that logicPD board has an onboard XDS100v1. Could you try that connection and see if you can access the external memory?

0 Walter Snafu over 14 years ago in reply to Ki

Genius 3450 points

Guru Ki-Soo Lee,

Yes, I have on hand a LogicPD EVM board, and it has onboard an XDS100v1 emulator and the same kind of LogicPD SOM I am testing on my target board (the board I mentioned in my previous posts). I hooked it up, and instructed CCS to use the target configuration file for THIS emulator (XDS100v1). And it worked! Using the debugger, I am able to poke data into the SOM's external memory.

Does this mean my other emulator (the XDS100v2 USB emulator that I posted about previously) is fried?

0 Ki over 14 years ago in reply to Walter Snafu

TI__Guru**** 472291 points

Walter Snafu said:
Does this mean my other emulator (the XDS100v2 USB emulator that I posted about previously) is fried?

That could be a possibility. But this partial failure is odd, that everything works fine except when trying to access external memory. Maybe you can try some troubleshooting:

http://processors.wiki.ti.com/index.php/XDS100#Troubleshooting

I'll forward this thread to the emulation experts and see if they can provide some more suggestions.

Thanks

0 Walter Snafu over 14 years ago in reply to Ki

Genius 3450 points

Another Clue! The problem isn't the emulator!

Details: I ordered another emulator and with the new emulator, the problem remains identical to the previous emulator. Again, the problem shows up on multiple boards that didn't show the problem previously.

By process of elimination: The problem must be within CCS somewhere.

???

0 Ki over 14 years ago in reply to Walter Snafu

TI__Guru**** 472291 points

Let's take the CCS debugger out of the loop and see if we can validate the XDS100 connection with the target. Can you try running some of the various dbgjtag tests as described in the below link ('Useful tests') and see if they pass or fail?

http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Useful_tests

0 Ki over 14 years ago in reply to Ki

TI__Guru**** 472291 points

I forgot to mention that in CCSv4, the dbgjtag utility can be found in <INSTALL DIR>\ccsv4\common\uscif

0 Walter Snafu over 14 years ago in reply to Ki

Genius 3450 points

Guru Ki-Soo Lee,

I found dbgjtag where you said it would be. But cannot get it to run. (Perhaps differences between CCSv3.3 and v4? -- I'm using the latter.)

Details: Per the wiki instructions, I used the command:

dbgjtag -f brddat\ccbrd.dat -rv

It then complains it cannot find that file. So I searched and found what appears to be the file it seeks at:

<install dir>\ccsv4\DebugServer\bin\win32\BrdDat\ccBoard0.dat

Notice the different filename. ??? It appears this file has a new name (and location?) under CCSv4.

So I tried various ways of giving it the new name (and new location). But nothing worked. It started complaining about "invalid arguments".

<I'm starting to wonder if I should just try uninstalling CCS, and re-installing. Any advice on that?>

0 Ki over 14 years ago in reply to Walter Snafu

TI__Guru**** 472291 points

Sorry, all the examples are for 3.3 so the files locations are different.

The location for the all the files for v4 are here: http://processors.wiki.ti.com/index.php/Debugging_JTAG_Connectivity_Problems#Code_Composer_Studio_v4

0 Walter Snafu over 14 years ago in reply to Ki

Genius 3450 points

Guru Ki-Soo Lee,

I successfully ran all three tests described on the wiki page: pathlength, brokenpath, and integrity. It appears to have successfully passed on three tests.

DETAILS:

C:\Program Files\Texas Instruments\ccsv4\common\uscif>dbgjtag -f "C:\Documents and Settings\<username>\Local Settings\Application Data\.TI\2067366409\0\BrdDat\ccBoard0.dat" -rv -S pathlength

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'jioserdesusb.dll'.
The library build date was 'Feb 28 2011'.
The library build time was '22:16:13'.
The library package version is '5.0.333.0'.
The library component version is '35.34.29.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '4' (0x00000004).
The controller has an insertion length of '0' (0x00000000).
This utility will now 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 FTDI FT2232 with USB interface.
The link from controller to target is direct (without cable).
The software is configured for FTDI FT2232 features.
The controller cannot monitor the value on the EMU[0] pin.
The controller cannot monitor the value on the EMU[1] pin.
The controller cannot control the timing on output pins.
The controller cannot control the timing on input pins.
The scan-path link-delay has been set to exactly '0' (0x0000).

-----[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.

*********************************************

C:\Program Files\Texas Instruments\ccsv4\common\uscif>dbgjtag -f "C:\Documents and Settings\<username>\Local Settings\Application Data\.TI\2067366409\0\BrdDat\ccBoard0.dat" -rv -S brokenpath

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

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

-----[Perform the Broken Path 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
All of the values were scanned correctly.

The JTAG IR Broken Path scan-test has succeeded.

-----[Perform the Broken Path 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
All of the values were scanned correctly.

The JTAG DR Broken Path scan-test has succeeded.

*********************************************

C:\Program Files\Texas Instruments\ccsv4\common\uscif>dbgjtag -f "C:\Documents a
nd Settings\A21YWZZ\Local Settings\Application Data\.TI\2067366409\0\BrdDat\ccBo
ard0.dat" -rv -S integrity

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

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

-----[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.

The JTAG DR Integrity scan-test has succeeded.

0 Walter Snafu over 14 years ago in reply to Walter Snafu

Genius 3450 points

Could be a corrupted or missing .gel file?

0 Walter Snafu over 14 years ago in reply to Walter Snafu

Genius 3450 points

Yes, the problem seems to have been a corrupted or missing .gel file. !!! When I restored a copy of the .gel file, the debugger started behaving more normally.

That''s 99.9 percent of the problem solved. I have one tiny question remaining about the matter.

The following easy CCSv4 startup command now fails:

Target -> Debug Active Project

It makes the following complaint and fails to make a connection.

Error connecting to the target:
(Error -2131 @ 0x0)
Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
(Release 5.0.333.0)

However, all works fine when I go through a more laborious startup sequence:

Target -> Launch TI Debugger
Target-> Connect Target
Target -> Load Program (OK=Yes)

How do I fix that?

0 dharmishtha sharma over 13 years ago in reply to Walter Snafu

Prodigy 10 points

Hello Walter,

Can you please let me know how you recovered the .gel file?

0 Walter Snafu over 13 years ago in reply to dharmishtha sharma

Genius 3450 points

dharmishtha sharma said:
Can you please let me know how you recovered the .gel file?

Dharmishtha,

If your setup worked previously, then you probably still have the .gel file on your computer. If not, then it can be obtained from LogicPD for your EVM board. (It might also be available from TI. But since my EVM and SOM boards were made by LogicPD, that's where I got my .gel files.) Or you can search for *.gel on your computer, (and probably find many examples in your TI directories). So, as step number one, get the .gel file(s) onto your computer, and know where it is.

Step two. Start up Code Composer Studio (CCS). I'll explain using the latest version: Version: 5.1.1.00031 Basically, you need to tell CCS where your specific .gel file is located.

View -> Target Configurations

Find your Target Configuration (It's probably under "User Defined") and double-click it. (If you can't find it, you may have to create a new target configuration. So right-click on "User Defined" and select "New Target Configuration", and give it a name, and go through the process of selecting your processor, etcetera)

Select the "Advanced" tab at the bottom of the Target Configuration window. And see your processor(s) listed there. Select your processor, then on the right side "Browse" down to find (and specify) your .gel file. (If you're using an OMAP part, there will be two processors listed there, and you need to setup one .gel file for each processor.)

Then "Save" the configuration. And you're done.

Code Composer Studio™︎

Code Composer Studio forum

"Debug Active Project" fails to launch (when it previously succeeded)