"Error connecting to the target". ccsv5 on linux, XDS100v2 JTAG adapter, devkit8000 Cortex-A8 OMAP3530 target board.

Ali Bahar

Other Parts Discussed in Thread: OMAP3530, CCSTUDIO

Hi,

I am running ccsv5 (5.0.1.00036, with its included Eclipse; Help shows it as "Code Composer Studio Version: N201101102000") on a linux host. This debian 6.0, 32-bit AMD, host is connected, via USB, to an XDS100v2 JTAG adapter. The latter is connected to a devkit8000 target board (ie a Beagle Board clone, with a Cortex-A8 OMAP3530 core); both were manufactured by Embest (armkits.com).

The host can talk to the JTAG pod (xds100v2), as confirmed by the dbgjtag utility (which comes with ccsv5). (See the bottom of this post, for the log.) But I have not been able to get ccsv5 to connect to the c64xp or the cortex-a8. The c64xp connection complains:

Error connecting to the target:
The target does not have a CPU clock.
(Error -1178) @ 109 (0x6D)

And the cortex-a8 connection hangs eclipse.Below, I will take you thru the steps I followed to get to these points.

Currently, most/all of the available info is based on ccsv4, used on a Windows host, and involving well-known target boards which are listed in the ccsv4 menus! On the plus side, there is plenty of info available, so I managed to patch together the/a procedure.

First, I created a Target Configuration, under the "Code Composer Studio - Device Debugging" category. It is best described by its resulting file (~/user/.CCSTargetConfigurations/devkit8000_xds100v2.ccxml) presented here:

<?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/tixds100v2c64xp.xml" id="drivers" xml="tixds100v2c64xp.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds100v2dap_pc.xml" id="drivers" xml="tixds100v2dap_pc.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds100v2cortexA.xml" id="drivers" xml="tixds100v2cortexA.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds100v2cs_child.xml" id="drivers" xml="tixds100v2cs_child.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds100v2etbcs.xml" id="drivers" xml="tixds100v2etbcs.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="OMAP3530_0" href="devices/OMAP3530.xml" id="OMAP3530_0" xml="OMAP3530.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

I left the Advanced options of OMAP3530 at its default values.

The ccBoard0.dat is as follows:

# config version=3.5
$ sepk
pod_drvr=libjioserdesusbv2.so
pod_port=0
$ /
$ product
title="Texas Instruments XDS100v2 USB"
alias=TI_XDS100v2_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="Adaptive_Clock,Active_High"
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"
gpio_h4="EMU_Pin_1,Active_Low"
gpio_h5="Cable_Disconnect,Active_High"
gpio_h6="Loopback,Active_High"
$ /
$ uscif
tdoedge=FALL
jtagboot_mode=disable
jtagboot_value=hiz
powerboot_mode=disable
powerboot_value=hiz
tclk_program=SPECIFIC
tclk_frequency=1.0
loopback_mode=disable
loopback_value=disable
$ /
@ icepick_c_0 family=icepick_c irbits=6 drbits=1 subpaths=2
& subpath_1 address=19 default=no custom=no force=yes pseudo=no
    @ cs_dap_pc_0 family=cs_dap_pc irbits=4 drbits=1 subpaths=2 address=0xD401D030 identify=0x0B6D602F revision=Legacy
      & subpath_6 type=legacy address=0 default=no custom=no force=yes pseudo=yes
        @ csetb_0 family=cs_etb irbits=0 drbits=0 address=0x5401B000 traceid=0x0
      & subpath_2 type=legacy address=0x9000 default=no custom=no force=yes pseudo=no
        @ cs_child_2 family=cs_child irbits=0 drbits=0 address=0xD4010000 identify=0x48C6E409
        @ cs_child_1 family=cs_child irbits=0 drbits=0 address=0xD401D000 identify=0x48CD0C09
        @ cs_child_0 family=cs_child irbits=0 drbits=0 address=0xD4012000 identify=0x48C44C09
        @ cortex_a8_0 family=cortex_axx irbits=0 drbits=0 address=0xD4011000
      & /
& subpath_0 address=17 default=no custom=no force=yes pseudo=no
    @ c64xp_0 family=tms320c64plus irbits=38 drbits=1
& /
# /

Starting eclipse, the initial screen looks as follows:

The JTAG pod has been connected to a USB port on the linux host, which typically makes it show up in dmesg as

[1074674.968126] usb 1-4: new high speed USB device using ehci_hcd and address 18
[1074675.105642] usb 1-4: New USB device found, idVendor=0403, idProduct=a6d0
[1074675.105653] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1074675.105661] usb 1-4: Product: Texas Instruments Inc.XDS100 Ver 2.0
[1074675.105666] usb 1-4: Manufacturer: TI
[1074675.105671] usb 1-4: SerialNumber: USB100V2
[1074675.105966] usb 1-4: configuration #1 chosen from 1 choice

The target board has been powered up. Uboot identifies it as:

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 DevKit8000 Board + LPDDR/NAND
DRAM: 256 MB
NAND: 256 MiB

Then, in the above Eclipse window, in the Target Configurations view, I select the default target (devkit8000_xds100v2.ccxml) with the Right mouse button, and choose Launch Selected Configuration from its pop-up menu. After a bit of processing, this results in

Then, in the Debug view, I select the IcePick, using the mouse Right button, and run Connect Target. After a moment, it seems to succeed:

Then I do the same for the CS_DAP, which seems to succeed as well:

The next one, for c64xp, fails as follows:

Never the less, I try connecting to the Cortex-A8 anyway, but that simply hangs Eclipse! My ckermit serial console to the target hangs as well; only a power cycle gets me out of it. (Eclipse needs a C-c, or SIGHUP, to exit, of course.)

Though the .ccxml file should/may suffice, I will show some some screen grabs of its configuration anyway:

The dbgjtag log is shown here:

Fullscreen 8306.dbgjtag_log_2011Feb22Tue.20.23.10.txt Download

root Tue Feb 22 17:02:13 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv

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

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver.

The value is '-180' (0xffffff4c).
The title is 'SC_ERR_CTL_NO_TRG_POWER'.

The explanation is:
The controller has detected a target power loss.
The user must turn-on or connect the power supply for the target.
root Tue Feb 22 17:02:25 angstrom> #let's power up the board
#let's power up the board
root Tue Feb 22 17:04:36 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv

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

This utility has selected a 100- or 510-class product.
This utility will load the adapter 'libjioserdesusbv2.so'.
The library build date was 'Jan 3 2011'.
The library build time was '23:12:04'.
The library package version is '5.0.281.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).
root Tue Feb 22 17:05:34 angstrom> echo $?
echo $?
0
root Tue Feb 22 17:28:36 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv S pathlength
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv S pathlength

Error: This utility has invalid arguments.
root Tue Feb 22 17:29:14 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv -S pathlength
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv -S pathlength

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

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

-----[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.
root Tue Feb 22 17:29:33 angstrom> echo $?
echo $?
0
root Tue Feb 22 17:29:37 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv -S brokenpath
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/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.
root Tue Feb 22 17:39:07 angstrom> echo $?
echo $?
0
root Tue Feb 22 17:39:10 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.dat -rv -S integrity
/usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -f ~him/.TI/1164384085/0/BrdDat/ccBoard0.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.
root Tue Feb 22 17:43:31 angstrom> echo $?
echo $?
0
root Tue Feb 22 17:43:34 angstrom> # It certanly is a cause for concern that "controller cannot monitor the value on the EMU" or "cannot control the timing"!
# It certanly is a cause for concern that "controller cannot monitor the value on the EMU" or "cannot control the timing"!
root Tue Feb 22 17:45:46 angstrom> set -v
set -v
root Tue Feb 22 17:46:07 angstrom>

root Tue Feb 22 17:46:09 angstrom> set +v
set +v
root Tue Feb 22 17:46:12 angstrom>
root Tue Feb 22 17:46:13 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -E single,number=-180

-----[The explanation of the error number '-180']----------------------------

This error is generated by TI's USCIF driver.

The value is '-180' (0xffffff4c).
The title is 'SC_ERR_CTL_NO_TRG_POWER'.

The explanation is:
The controller has detected a target power loss.
The user must turn-on or connect the power supply for the target.
root Tue Feb 22 17:47:59 angstrom> /usr/local/CCSv5/./ccsv5/ccs_base_5.0.1.00036/common/uscif/dbgjtag -E single,number=-151

-----[The explanation of the error number '-151']----------------------------

This error is generated by TI's USCIF driver.

The value is '-151' (0xffffff69).
The title is 'SC_ERR_POD_OPEN'.

The explanation is:
This utility failed to open the adapter for a custom emulator.
The adapter returned an error.
root Tue Feb 22 17:48:19 angstrom>

The following observations should also be of interest.

I ran 'strace eclipse', and noticed that, when the hang occurs, it is trying to access

stat64("/usr/local/CCSv5/ccsv5/ccs_base_5.0.1.00036/DebugServer/bin/linux_ia32/LinuxDriver.dll", 0xbfb87448) = -1 ENOENT (No such file or directory)

Is this a remnant of Windows code? That directory lists only

him@interzone Thu Feb 24 10:46:19 CCSv5> ls -l /usr/local/CCSv5/ccsv5/ccs_base_5.0.1.00036/DebugServer/bin/linux_ia32/
total 3580
drwxr-xr-x 2 no9 no9   4096 Feb 14 15:55 SerializedProfileActivities/
-rwxr-xr-x 1 no9 no9 95275 Jan 21 23:17 drive_ofs*
-r--r--r-- 1 no9 no9    161 Jan 21 23:17 drivers.ini
-rwxr-xr-x 1 no9 no9 53483 Jan 21 23:17 libBkptCollector.so*
-rwxr-xr-x 1 no9 no9 124540 Jan 21 23:17 libCCSnowFlash.so*
-rwxr-xr-x 1 no9 no9 901202 Jan 21 23:17 libCollectorServer.so*
-rwxr-xr-x 1 no9 no9 362761 Jan 21 23:17 libDatasetServer.so*
-rwxr-xr-x 1 no9 no9 79763 Jan 21 23:17 libFlash28xx.so*
-rwxr-xr-x 1 no9 no9 22590 Jan 21 23:17 libFlashStellaris.so*
-rwxr-xr-x 1 no9 no9   4032 Jan 21 23:17 libLibraryLoader.so*
-rwxr-xr-x 1 no9 no9 455111 Jan 21 23:17 libLinuxDriver.so*
-rwxr-xr-x 1 no9 no9 556087 Jan 21 23:17 libtiofr11.so*
-rwxr-xr-x 1 no9 no9 152649 Jan 21 23:17 libtiofr_gnu.so*
-rwxr-xr-x 1 no9 no9 494909 Jan 21 23:17 libtiofr_tial.so*
-rwxr-xr-x 1 no9 no9 182755 Jan 21 23:17 libXPCOMUtility.so*
-rwxr-xr-x 1 no9 no9 94105 Jan 21 23:17 ofs_dump*
him@interzone Thu Feb 24 10:46:22 CCSv5>

(The executability is, IIRC, another such Windows artifact as well.) However, desparately creating a soft link

ln -s libLinuxDriver.so LinuxDriver.dll

did not help anything.

FYI, during the c64xp connection failure, the following echoed:

stat64("/usr/local/CCSv5/ccsv5/eclipse/plugins/com.ti.ccstudio.debug.server_5.0.1.201101102000/com/ti/debug/engine/dialogs/IBaseDialog$IconType.class", 0xbfb86f30) = -1 ENOENT (No such file or directory)

However, this seems more informational than functional -- unless if a debug plugin is needed.

him@interzone Thu Feb 24 11:08:24 linux_ia32> ls -l /usr/local/CCSv5/ccsv5/eclipse/plugins/com.ti.ccstudio.debug.server_5.0.1.201101102000/com/ti/
total 4
drwxr-xr-x 3 him him 4096 Feb 14 15:58 ccstudio/
him@interzone Thu Feb 24 11:08:32 linux_ia32>

him9@interzone Thu Feb 24 12:11:24 Xterm.log> uname -a
Linux interzone 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux
him@interzone Thu Feb 24 12:11:26 Xterm.log>

That's all the info which I can think of. My original goal was to break into x-loader, and dump some data/variables, that's all!

Thanks for any help, tips or commiseration which anyone can provide.

over 14 years ago

0 AartiG over 14 years ago

TI__Guru**** 173310 points

The results of running dbgjtag show that your JTAG connection is good. After launching the target configuration, for the OMAP3530 you should connect to the Cortex A8 core first and then the DSP core. There is no need to separately connect to IcePick or DAP.

Please take a look at these related articles:

http://processors.wiki.ti.com/index.php/GSG:Common_target_configurations#Beagleboard.2C_Hawkboard.2C_Leopardboard.2C_Pandaboard
http://processors.wiki.ti.com/index.php/GSG:Connecting_to_slave_cores_in_SoC_devices

Also some other posts I found on the forums that might be helpful:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/93463/325219.aspx#325219
http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/49087.aspx

0 Ali Bahar over 14 years ago in reply to AartiG

Prodigy 30 points

Excellent! It works. Thank you so much.

This is the procedure which I have now followed:

1. start eclipse;

2. Select my Target Configuration, as before;

3. The JTAG pod has already been connected to a USB port on the linux host. The target board is booted up (or a hard reset); once the uboot prompt is reached, it is paused to stop the autoboot;

4. in Eclipse's Debug View, I select Cortex-A8, and do "Connect Target" as above. After a few moments, it does.

Though I'd looked at the two wiki pages before, I'd missed the #Beagleboard.2C_Hawkboard.2C_Leopardboard.2C_Pandaboard section (in favour of the xds100v2 section)!

Thanks again,

Ali

Aarti said:

http://processors.wiki.ti.com/index.php/GSG:Common_target_configurations#Beagleboard.2C_Hawkboard.2C_Leopardboard.2C_Pandaboard
http://processors.wiki.ti.com/index.php/GSG:Connecting_to_slave_cores_in_SoC_devices

0 NITIN MEWADA over 14 years ago in reply to Ali Bahar

Prodigy 120 points

Hi everyone

I am using the CCSv5.x on windows 7 for devkit8000. Problem is that when i am trying to connect the ArmCortexA8 first , then in the debug it is showing "connecting" but ,then CCS gets hanged. What could be possible reasons ? Previously I had worked with beagle board, so i know the steps and some stuffs . There i tried changing gel files also , but same result, it hanged.

With Regards

Nitin Mewada

Code Composer Studio™︎

Code Composer Studio forum

"Error connecting to the target". ccsv5 on linux, XDS100v2 JTAG adapter, devkit8000 Cortex-A8 OMAP3530 target board.