TMS320C6678: Unable to Run STM based Hardware Trace Analyzer

George,

Support on external emulators are beyond the scope of Processor Forum support.

Thanks for your undestanding.

Regards

Shankari G

Shankari G,

I originally tried to post this to the Code Composer Studio forum, but the form forced me to post to this Processors forum.

Is there a way to have this post redirected to the Code Composer Studio forum?

Or will I get the same response from that forum?

-George

George, 

Actually the problem is the team may not have the external emulators as they use the in-built emulators for their development.

And the knowledge about the various emulators existing in the market would be sparse.

--

And also, as C6678 is an older device; Support is very limited in general.

Regards

Shankari G

Shankari G said:

And also, as C6678 is an older device; Support is very limited in general.

In addition, the CCS versions mentioned (v5.5 and v8.3) are also very old and unsupported versions.

I did try a custom system trace session using CCS 8.3.1 with my Blackhawk XDS560v2 STM probe on a C6678 EVM. I was able to start a session without issue.

George - can you simplify the scenario? Can you just start a new debug session and connect to CPU1 and then (without loading any program) try starting a system trace session and see if the session at least be opened successfully?

Ki,

Thanks for getting back to me on this.

I do realize that the version of CCS v5.5.0 is old and that is why I moved to the latest CCS v8.3.1 with last win32 support for the BHUSB560v2 ST to see if that was any different. This was the recommendation given by Blackhawk/Corelis engineering.

I have tried the simplified debug session you asked about, connecting to C6678_0 with NO program loaded,  When attempting to perform "Tools\Hardware Analyzer -> Custom System Trace (Transport Type 560 V2 Trace)" I get the same results as posted in my original post for CCS v8.3.1.

I have tried w/ and w/o first "show all cores" and connecting to Non Debug Cores per documentation.

Regardless, the result is the same failure as shown within original post with popups showing...

“Progress Information – 560 V2 Trace – Calibration in progress”

“X – Could not run analyzer. Cause: failed to calibrate channel : transmitter frequency measured at 0 Hz”

same Console output

FYI...

Running the provided Blackhawk XDS560v2 Configuration Utility - Bh560v2Config v.1.0.0.14 installed with CCS v8.3.1 when connected to our custom 4-C6678 h/w and performing all tests passes as follows...

CMD: dtc_conf --version
Version 8.4.0.00006, built Nov 25 2019 16:47:30

LAN: Not selected to search.

CMD: dtc_conf get bh560v2u 0 

CMD: dtc_conf get bh560v2u 1 
USB: 1 device found.

TOTAL: 1 device found.


CMD: dtc_conf get bh560v2u 0 
addrConf=:55756
addrIo=:55755
boardRev=2
dtcName=none
epkRev=5.0.573.0
fpgaRev=1.57
productClass=XDS560V2
productName=Blackhawk USB560v2 System Trace Emulator
safeMode=false
serialNum=00:00:00:04:11:25
swBuildTime=Apr 19 2012 14:09:25
swRev=5.0.573.0
time=none
vendorName=Blackhawk
standbyEnable=false
standbyMinutes=20


CMD: dbgjtag -X emulator,driver=bh560v2u,ioport=0 -S integrity -Y reset -S pathlength -G range,lowest=9.350000,highest=11.250000 
Loaded FPGA Image: C:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs831\ccsv8\ccs_base\common\uscif\dtc_top.jbc

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

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

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

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

-----[Test the source and frequency of the JTAG TCLK]------------------------

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

-----[Perform the scan and frequency double test]----------------------------

This test will use a total of 15 frequencies.
This test will measure every frequency.
This test will use blocks of 64 32-bit words.
This test will be applied just once.

  Base         Step          Results (press any key to finish early)

  9.000 MHz    125.0 kHz     -  -  -  O  O  O  O  O 
  10.00 MHz    125.0 kHz     O  O  O  O  O  O  O  O 
  11.00 MHz    125.0 kHz     O  O  -  -  -  -  -  - 

The scan and frequency double test has finished.

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

This test will use blocks of 64 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 64 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.

RES: dbgjtag -X emulator,driver=bh560v2u,ioport=0 -S integrity -Y reset -S pathlength -G range,lowest=9.350000,highest=11.250000 
RES: Ok

As another data-point test...

On CCS v8.3.1 I created a new truncated Target Configuration for our custom 4-C6678 board having just the 1st C6678 in the scan chain active and the last 3 C6678's bypassed.

Here is that truncated/bypassed Target Configuration .ccxml

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
        <instance XML_version="1.2" desc="Blackhawk XDS560v2-USB System Trace Emulator_0" href="connections/BH-XDS560v2-USB_Connection.xml" id="Blackhawk XDS560v2-USB System Trace Emulator_0" xml="BH-XDS560v2-USB_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
            <instance XML_version="1.2" href="drivers/tixds560c66xx.xml" id="drivers" xml="tixds560c66xx.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560icepick_d.xml" id="drivers" xml="tixds560icepick_d.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cs_dap.xml" id="drivers" xml="tixds560cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560csstm.xml" id="drivers" xml="tixds560csstm.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560etbcs.xml" id="drivers" xml="tixds560etbcs.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320C6678_0" href="devices/C6678.xml" id="TMS320C6678_0" xml="C6678.xml" xmlpath="devices"/>
                <cpu HW_revision="1.0" XML_version="1.2" description="Bypass Cpu" id="bypass_0" isa="BYPASS18"/>
            </platform>
        </connection>
    </configuration>
</configurations>

Here's the successful Test Connection result with this "truncated" Target Configuration...

[Start: Blackhawk XDS560v2-USB System Trace Emulator_0]

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\GenUser\AppData\Local\TEXASI~1\
    CCS\ccs831\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 'bh560v2u.out'.
Loaded FPGA Image: C:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs831\ccsv8\ccs_base\common\uscif\dtc_top.jbc
The library build date was 'Nov 25 2019'.
The library build time was '14:08:22'.
The library package version is '8.4.0.00006'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '6' (0x00000006).
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:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs831\ccsv8\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     64  - 01 00  500.0kHz   O    good value   measure path length
    4     16  - 01 00  500.0kHz   O    good value   auto step initial
    5     16  - 01 0D  601.6kHz   O    good value   auto step delta
    6     16  - 01 1C  718.8kHz   O    good value   auto step delta
    7     16  - 01 2E  859.4kHz   O    good value   auto step delta
    8     16  + 00 02  1.031MHz   O    good value   auto step delta
    9     16  + 00 0F  1.234MHz   O    good value   auto step delta
   10     16  + 00 1F  1.484MHz   O    good value   auto step delta
   11     16  + 00 32  1.781MHz   O    good value   auto step delta
   12     16  + 01 04  2.125MHz   O    good value   auto step delta
   13     16  + 01 11  2.531MHz   O    good value   auto step delta
   14     16  + 01 21  3.031MHz   O    good value   auto step delta
   15     16  + 01 34  3.625MHz   O    good value   auto step delta
   16     16  + 02 05  4.313MHz   O    good value   auto step delta
   17     16  + 02 13  5.188MHz   O    good value   auto step delta
   18     16  + 02 23  6.188MHz   O    good value   auto step delta
   19     16  + 02 37  7.438MHz   O    good value   auto step delta
   20     16  + 03 07  8.875MHz   O    good value   auto step delta
   21     16  + 03 15  10.63MHz   O    good value   auto step delta
   22     16  + 03 1E  11.75MHz  {O}   good value   auto step delta
   23     64  + 02 3E  7.875MHz   O    good value   auto power initial
   24     64  + 03 0E  9.750MHz   O    good value   auto power delta
   25     64  + 03 16  10.75MHz   O    good value   auto power delta
   26     64  + 03 1A  11.25MHz   O    good value   auto power delta
   27     64  + 03 1C  11.50MHz   O    good value   auto power delta
   28     64  + 03 1D  11.63MHz   O    good value   auto power delta
   29     64  + 03 1D  11.63MHz   O    good value   auto power delta
   30     64  + 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 569214Hz.
The delta frequency was 1098Hz.

In the scan-path tests:
The test length was 2048 bits.
The JTAG IR length was 24 bits.
The JTAG DR length was 4 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 64 32-bit words.

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

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

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

This test will use blocks of 64 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 64 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: Blackhawk XDS560v2-USB System Trace Emulator_0]

Upon launching this truncated/bypass Target Configuration it shows that single C6678 in the debug device tree, but when I attempting to connect to C66xx_0 it fails with popup...

Blackhawk XDS560v2-USB System Trace Emulator_0/IcePick_D

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).
(Emulation package 8.4.0.00006)

Console output...

IcePick_D: 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). (Emulation package 8.4.0.00006)

I'm not quite sure why it's not able to connect to the single C66xx_0 with this "truncated/bypassed" Target Configuration.

-George

George Lathrop said:

I do realize that the version of CCS v5.5.0 is old and that is why I moved to the latest CCS v8.3.1 with last win32 support for the BHUSB560v2 ST to see if that was any different. This was the recommendation given by Blackhawk/Corelis engineering.

Are you on a 32-bit Windows OS? Is that why Blackhawk recommended 8.3.1 (which is indeed the last CCS version to support 32-bit Windows?)

Ki,

I'm actually running on Win7 64-bit, but nonetheless both CCS v5.5.0 and CCS v8.3.1 are being used which in turn engages the win32 support for the BHUSB560v2 ST.

I know I can move forward to newer versions of CCS but then will be changing things using 64-bit drivers which may or may not resolve things in this situation.

The TMS320C6678 was released well over a decade ago circa 2010/11 and as such the TI development and debug eco-system was supporting 

Note the Advantech TMDXEVM6678L EVM was released circa 2010/10 and shipped with CCS v5.1 I believe.

Much of the support documentation, white papers and training workshops I've found show this System Trace working with similar CCS vintage ecosystem, i.e., CCS v.5.4, etc.

It took me the better part of a day to locate an adapter (MIPI-60 to TI-60 4-row connector on EVM) to be able to physically connect the BHUSB560v2 to the EVM.

I then pursued testing with the BHUSB560v2 System Trace emulator and TMDXEVM6678L.

Running on Windows 7 64-bit OS and tools provided with CCS v5.5.0.

Here's the successful output from running the Blackhawk XDS560v2 Configuration Utility - Bh560v2Config v.1.0.0.14 on the "same" BHUSB560v2 System Trace emulator being used for prior testing and "connected" to Advantech's TMDXEVM6678L EVM using a MIPI-60 to TI-60 connection on EVM.

CMD: dtc_conf --version
Version 8.4.0.00006, built Nov 25 2019 16:47:30

LAN: Not selected to search.

CMD: dtc_conf get bh560v2u 0 

CMD: dtc_conf get bh560v2u 1 
USB: 1 device found.

TOTAL: 1 device found.


CMD: dtc_conf get bh560v2u 0 
addrConf=:55756
addrIo=:55755
boardRev=2
dtcName=none
epkRev=5.0.573.0
fpgaRev=1.54
productClass=XDS560V2
productName=Blackhawk USB560v2 System Trace Emulator
safeMode=false
serialNum=00:00:00:04:11:25
swBuildTime=Apr 19 2012 14:09:25
swRev=5.0.573.0
time=none
vendorName=Blackhawk
standbyEnable=false
standbyMinutes=20


CMD: dbgjtag -X emulator,driver=bh560v2u,ioport=0 -S integrity -Y reset -S pathlength -G range,lowest=9.350000,highest=11.250000 
Loaded FPGA Image: C:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs831\ccsv8\ccs_base\common\uscif\dtc_top.jbc

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

This path-length test uses blocks of 64 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.

-----[Test the source and frequency of the JTAG TCLK]------------------------

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

-----[Perform the scan and frequency double test]----------------------------

This test will use a total of 15 frequencies.
This test will measure every frequency.
This test will use blocks of 64 32-bit words.
This test will be applied just once.

  Base         Step          Results (press any key to finish early)

  9.000 MHz    125.0 kHz     -  -  -  O  O  O  O  O 
  10.00 MHz    125.0 kHz     O  O  O  O  O  O  O  O 
  11.00 MHz    125.0 kHz     O  O  -  -  -  -  -  - 

The scan and frequency double test has finished.

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

This test will use blocks of 64 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 64 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.

RES: dbgjtag -X emulator,driver=bh560v2u,ioport=0 -S integrity -Y reset -S pathlength -G range,lowest=9.350000,highest=11.250000 
RES: Ok

Using CCS v5.5.0 I created a new Target Configuration "BHUSB560v2_TMDXEVM6678L_TargetConfiguration.ccxml"

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
        <instance XML_version="1.2" desc="Blackhawk XDS560v2-USB System Trace Emulator_0" href="connections/BH-XDS560v2-USB_Connection.xml" id="Blackhawk XDS560v2-USB System Trace Emulator_0" xml="BH-XDS560v2-USB_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
            <instance XML_version="1.2" href="drivers/tixds560icepick_d.xml" id="drivers" xml="tixds560icepick_d.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560c66xx.xml" id="drivers" xml="tixds560c66xx.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cs_dap.xml" id="drivers" xml="tixds560cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560csstm.xml" id="drivers" xml="tixds560csstm.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560etbcs.xml" id="drivers" xml="tixds560etbcs.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320C6678_0" href="devices/C6678.xml" id="TMS320C6678_0" xml="C6678.xml" xmlpath="devices"/>
            </platform>
        </connection>
    </configuration>
</configurations>

Here's the successful "Test Connection" output of that new TC from CCS v5.5.0

[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\GenUser\AppData\Local\.TI\3455637229\
    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 'bh560v2u.out'.
Loaded FPGA Image: C:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs550\ccsv5\ccs_base\common\uscif\dtc_top.jbc
The library build date was 'Sep  4 2015'.
The library build time was '19:17:31'.
The library package version is '6.0.14.5'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '6' (0x00000006).
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:\sw-fwdsp\Kilimanjaro\MAIN\ti64+\toolset\TI\ccs550\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     64  - 01 00  500.0kHz   O    good value   measure path length
    4     16  - 01 00  500.0kHz   O    good value   auto step initial
    5     16  - 01 0D  601.6kHz   O    good value   auto step delta
    6     16  - 01 1C  718.8kHz   O    good value   auto step delta
    7     16  - 01 2E  859.4kHz   O    good value   auto step delta
    8     16  + 00 02  1.031MHz   O    good value   auto step delta
    9     16  + 00 0F  1.234MHz   O    good value   auto step delta
   10     16  + 00 1F  1.484MHz   O    good value   auto step delta
   11     16  + 00 32  1.781MHz   O    good value   auto step delta
   12     16  + 01 04  2.125MHz   O    good value   auto step delta
   13     16  + 01 11  2.531MHz   O    good value   auto step delta
   14     16  + 01 21  3.031MHz   O    good value   auto step delta
   15     16  + 01 34  3.625MHz   O    good value   auto step delta
   16     16  + 02 05  4.313MHz   O    good value   auto step delta
   17     16  + 02 13  5.188MHz   O    good value   auto step delta
   18     16  + 02 23  6.188MHz   O    good value   auto step delta
   19     16  + 02 37  7.438MHz   O    good value   auto step delta
   20     16  + 03 07  8.875MHz   O    good value   auto step delta
   21     16  + 03 15  10.63MHz   O    good value   auto step delta
   22     16  + 03 1E  11.75MHz  {O}   good value   auto step delta
   23     64  + 02 3E  7.875MHz   O    good value   auto power initial
   24     64  + 03 0E  9.750MHz   O    good value   auto power delta
   25     64  + 03 16  10.75MHz   O    good value   auto power delta
   26     64  + 03 1A  11.25MHz   O    good value   auto power delta
   27     64  + 03 1C  11.50MHz   O    good value   auto power delta
   28     64  + 03 1D  11.63MHz   O    good value   auto power delta
   29     64  + 03 1D  11.63MHz   O    good value   auto power delta
   30     64  + 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 569214Hz.
The delta frequency was 1098Hz.

In the scan-path tests:
The test length was 2048 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 64 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 64 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 64 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]

I Launched this newly created Target Configuration "BHUSB560v2_TMDXEVM6678L_TargetConfiguration.ccxml" on CCS v5.5.0.

The Debug view showed the single C6678 and it's 7 C66xx's (C66xx_0 ... 7)

I added "show al cores" and connected to them.

I connected to C66xx_0 and did not load any project code and resumed running whatever was loaded on that core.

I then selected "Tools\Hardware Trace Analyzer\Memory Throughput and Access Analysis" selecting Transfer Type ETB with advanced settings of Transaction Masters ... C66xx0-7, EDMA, PCIe

The Trace Viewer showed data collection actively taking place.

I then suspended C66xx_0 and Trace information populated within the "Trace Viewer - CSSTM_0" along with info being shown within both "Memory Throughput - CSSTM_0" and "Minimum Average Latency - CSSTM_0" tabs

This is not all that impressive, but it does show that the EVM with BHUSB560v2 System Trace emulator can collect device information via ETB.

Then I ran "Tools\Hardware Trace Analyzer\Memory Throughput and Access Analysis" selecting Transfer Type "560 v2 Trace" and after a 10-15 seconds of a calibration popup window being displayed it actually showed Trace information being displayed as follows.

Run #1...

Run #2...

This suggests that the issue with performing hardware trace/info data gathering via CCS v5.5.0 or CCS v8.3.1 and "BHUSB560v2 System Trace emulator" regardless of Transfer Type ETB or 560 V2 Trace is localized to our "custom" h/w having 4-C6678s and/or how we are configuring/conditioning the EMU pins and/or clocking/timing setup.

Likely this is what the CCS v8.3.1's popup message was trying to indicate during it's failing calibration step when using our custom 4-C6678 h/w, i.e., see information shared in earlier post.

Progress Information – 560 V2 Trace – Calibration in progress”

“X – Could not run analyzer. Cause: failed to calibrate channel : transmitter frequency measured at 0 Hz”

Is there a setting within our custom board's Target Configuration that we could set/change that would help get this to work on our custom 4-C6678 h/w?

Our "custom" Target Configuration ... "BHUSB560v2_C6678_4_TargetConfiguration.ccxml" re-posted here for convenience...

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
        <instance XML_version="1.2" desc="Blackhawk XDS560v2-USB System Trace Emulator_0" href="connections/BH-XDS560v2-USB_Connection.xml" id="Blackhawk XDS560v2-USB System Trace Emulator_0" xml="BH-XDS560v2-USB_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Blackhawk XDS560v2-USB System Trace Emulator_0">
            <instance XML_version="1.2" href="drivers/tixds560icepick_d.xml" id="drivers" xml="tixds560icepick_d.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560c66xx.xml" id="drivers" xml="tixds560c66xx.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cs_dap.xml" id="drivers" xml="tixds560cs_dap.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560csstm.xml" id="drivers" xml="tixds560csstm.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560etbcs.xml" id="drivers" xml="tixds560etbcs.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320C6678_0" href="devices/C6678.xml" id="TMS320C6678_0" xml="C6678.xml" xmlpath="devices"/>
                <device HW_revision="1" XML_version="1.2" description="C66x core" id="TMS320C6678_0" partnum="TMS320C6678"/>
                <instance XML_version="1.2" desc="TMS320C6678_1" href="devices/C6678.xml" id="TMS320C6678_1" xml="C6678.xml" xmlpath="devices"/>
                <device HW_revision="1" XML_version="1.2" description="C66x core" id="TMS320C6678_1" partnum="TMS320C6678">
                    <router HW_revision="1.0" XML_version="1.2" desc="IcePick_E" description="ICEPick_D Router" id="IcePick_D_0" isa="ICEPICK_D">
                        <subpath desc="subpath_8" id="subpath_0">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_8" description="C66xx CPU" id="C66xx_0" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_9" id="subpath_1">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_9" description="C66xx CPU" id="C66xx_1" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_10" id="subpath_2">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_10" description="C66xx CPU" id="C66xx_2" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_11" id="subpath_3">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_11" description="C66xx CPU" id="C66xx_3" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_12" id="subpath_4">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_12" description="C66xx CPU" id="C66xx_4" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_13" id="subpath_5">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_13" description="C66xx CPU" id="C66xx_5" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_14" id="subpath_6">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_14" description="C66xx CPU" id="C66xx_6" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_15" id="subpath_7">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_15" description="C66xx CPU" id="C66xx_7" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="DAP_0" id="DAP">
                            <router HW_revision="1.0" XML_version="1.2" desc="CS_DAP_DebugSS_0" description="CS DAP Router" id="CS_DAP_DebugSS" isa="CS_DAP">
                                <subpath desc="STM_0" id="STM">
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="CSSTM_1" description="CS System Trace" id="CSSTM_0" isa="TMS470R26X"/>
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="TETB_STM_0" description="CS Embedded Trace Buffer" id="TETB_STM" isa="CS_ETB"/>
                                </subpath>
                            </router>
                        </subpath>
                    </router>
                </device>
                <instance XML_version="1.2" desc="TMS320C6678_2" href="devices/C6678.xml" id="TMS320C6678_2" xml="C6678.xml" xmlpath="devices"/>
                <device HW_revision="1" XML_version="1.2" description="C66x core" id="TMS320C6678_2" partnum="TMS320C6678">
                    <router HW_revision="1.0" XML_version="1.2" desc="IcePick_F" description="ICEPick_D Router" id="IcePick_D_0" isa="ICEPICK_D">
                        <subpath desc="subpath_16" id="subpath_0">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_16" description="C66xx CPU" id="C66xx_0" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_17" id="subpath_1">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_17" description="C66xx CPU" id="C66xx_1" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_18" id="subpath_2">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_18" description="C66xx CPU" id="C66xx_2" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_19" id="subpath_3">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_19" description="C66xx CPU" id="C66xx_3" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_20" id="subpath_4">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_20" description="C66xx CPU" id="C66xx_4" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_21" id="subpath_5">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_21" description="C66xx CPU" id="C66xx_5" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_22" id="subpath_6">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_22" description="C66xx CPU" id="C66xx_6" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_23" id="subpath_7">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_23" description="C66xx CPU" id="C66xx_7" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="DAP_1" id="DAP">
                            <router HW_revision="1.0" XML_version="1.2" desc="CS_DAP_DebugSS_1" description="CS DAP Router" id="CS_DAP_DebugSS" isa="CS_DAP">
                                <subpath desc="STM_1" id="STM">
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="CSSTM_2" description="CS System Trace" id="CSSTM_0" isa="TMS470R26X"/>
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="TETB_STM_1" description="CS Embedded Trace Buffer" id="TETB_STM" isa="CS_ETB"/>
                                </subpath>
                            </router>
                        </subpath>
                    </router>
                </device>
                <instance XML_version="1.2" desc="TMS320C6678_3" href="devices/C6678.xml" id="TMS320C6678_3" xml="C6678.xml" xmlpath="devices"/>
                <device HW_revision="1" XML_version="1.2" description="C66x core" id="TMS320C6678_3" partnum="TMS320C6678">
                    <router HW_revision="1.0" XML_version="1.2" desc="IcePick_G" description="ICEPick_D Router" id="IcePick_D_0" isa="ICEPICK_D">
                        <subpath desc="subpath_24" id="subpath_0">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_24" description="C66xx CPU" id="C66xx_0" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_25" id="subpath_1">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_25" description="C66xx CPU" id="C66xx_1" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_26" id="subpath_2">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_26" description="C66xx CPU" id="C66xx_2" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_27" id="subpath_3">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_27" description="C66xx CPU" id="C66xx_3" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_28" id="subpath_4">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_28" description="C66xx CPU" id="C66xx_4" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_29" id="subpath_5">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_29" description="C66xx CPU" id="C66xx_5" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_30" id="subpath_6">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_30" description="C66xx CPU" id="C66xx_6" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="subpath_31" id="subpath_7">
                            <cpu HW_revision="1.0" XML_version="1.2" desc="C66xx_31" description="C66xx CPU" id="C66xx_7" isa="TMS320c66xx"/>
                        </subpath>
                        <subpath desc="DAP_2" id="DAP">
                            <router HW_revision="1.0" XML_version="1.2" desc="CS_DAP_DebugSS_2" description="CS DAP Router" id="CS_DAP_DebugSS" isa="CS_DAP">
                                <subpath desc="STM_2" id="STM">
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="CSSTM_3" description="CS System Trace" id="CSSTM_0" isa="TMS470R26X"/>
                                    <cpu HW_revision="1.0" XML_version="1.2" desc="TETB_STM_2" description="CS Embedded Trace Buffer" id="TETB_STM" isa="CS_ETB"/>
                                </subpath>
                            </router>
                        </subpath>
                    </router>
                </device>
            </platform>
        </connection>
    </configuration>
</configurations>

I will engage our h/w folks to look into any potential JTAG/EMU pin timing and/or electrical issues there may be within our custom h/w design.

Fixing this in software vs hardware would be most desirable at this point.

Thanks the help,

-George

George Lathrop said:

I'm actually running on Win7 64-bit, but nonetheless both CCS v5.5.0 and CCS v8.3.1 are being used which in turn engages the win32 support for the BHUSB560v2 ST.

You should be able to use the latest CCS version with the Blackhaek USB560v2 STM debug probe on Win 7-64 with C6678. However I can't say the updating from 8.3.1 will resolve your issue. 

George Lathrop said:

I then pursued testing with the BHUSB560v2 System Trace emulator and TMDXEVM6678L.

Yes I have the EVM and Blackhawk probe. I used it with both CCS 8.3.1 and CCS 12.7.1 successfully.

George Lathrop said:

This suggests that the issue with performing hardware trace/info data gathering via CCS v5.5.0 or CCS v8.3.1 and "BHUSB560v2 System Trace emulator" regardless of Transfer Type ETB or 560 V2 Trace is localized to our "custom" h/w having 4-C6678s and/or how we are configuring/conditioning the EMU pins and/or clocking/timing setup.

Yes, I this is my assessment also.

George Lathrop said:

Is there a setting within our custom board's Target Configuration that we could set/change that would help get this to work on our custom 4-C6678 h/w?

I am not aware of any

I'll ping the trace experts for any suggestions. The device experts may also need to investigate.

Thanks

ki

George - are you using any startup GEL files in both the working case with the EVM and the non-working case on the custom board?

Ki

No not using any GEL files either in the working case with the EVM nor the failing case with our custom board.

In the success EVM test case i created a new custom TC by going direct at the TMS320C6678 as there wasn't a  TMDSEVM6677LE in the board options. As such no board nor GEL was specifically added to TC.

This is same method used when creating custom TC for our custom 4-C6678 board. No GEL scripts attached .

Some investigating found a reference to the calibration failure message we're seeing on CCS v8.3.1 (see earlier post).

The following link's Q&A has reference to a "failed to calibrate channel".  See the following liink....

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_xds560v2.html#q-i-get-the-failed-to-calibrate-channel-no-signal-on-clock-check-external-pin-manager-settings-and-clock-circuit-connection-error-message-from-the-trace-control-what-could-be-wrong-

Ki,

Further investigation into our custom 4-C6678 board did show that EMU0 and EMU1 pins were never connected to any of the 4 C6678 devices. These two pins were pulled up with 4.7K resistors.

The other EMU pins 2-18 are connected but only to the first C6678_0 intended for h/w trace to just that DSP.

The original design intent was to use EMU0/1 for global breakpoints device cross-triggering by connecting to all 4 C6678's, but it was never fully implemented.

A simple board mod was done to actually connect the EMU0 and EMU1 pins with short 1/4 inch wires to the available fly-by two wire network strategy to all 4 C6678's on our board per guidelines in the Emulation and Trace TRM (spru655i.pdf).

With this mod EMU0/1 are connected to all 4 C6678's and EMU2-18 pins are only connected to first DSP C6678_0.

At the moment the 4.7K pull ups were left intact on EMU0/1 pins. These in the end may need to be removed to pass Signal Integrity (Si) and being pursued.

Testing following this mod with BHUSB560V2 ST showed that there's no longer a calibration failure but doing a h/w trace complains about data integrity and only shows 3 trace entries, start, data-integrity error, and stop. More testing needed after investigating SI and pull-ups on EMU0/1 pins.

The Emulation and Trace TRM (34) does clearly suggest that EMU0/1 are optional for Trace due to necessity of violating Traces 3" board trace lengths when used for multiple DSP cross triggering. It further suggests h/w Trace is possible with the other remaining EMU pins if emulator supports EMU pin selection. Other Q&A references to external pin manager (see earlier post) seem to likewise suggest the same capability. Unfortunately, with the trace emulators we have its not clear how to specify which EMU pins to use for Trace. Have not been able to accomplish with vendor emulator tools nor CCS setup/config facilities.

We've tried Blackhawk's BHUSB560v2 System Trace and played with the available pin options 4, 2, 1 without success.

I recently hooked up the Spectrum Digital XDS560v2 ProTrace emulator with my board's unmodified EMU0/1 connections, i.e., not connected to DSPs, and it too fails same as with BHUSB560v2 ST.

One difference is the Spectrum Digital XDS560v2 ProTrace doesn't fail at the calibration step, but does fail with data corruption as a result of doing a h/w Trace attempt.

It would be good to find out if the emulators we have support EMU pin re-direction for h/w Trace and how to accomplish this and if they don't is there an emulator available that does support this feature not using EMU0/1 but higher EMU pins 2-18.

Thanks,
-George

Ki,

We have made progress with our custom 4-C6678 board and now can do h/w System Trace.

In order to get h/w Trace to work we resorted to connecting JTAG as well as ALL EMU pins just to a single device C6678_0 on our 4-C6678 custom board.

This was done to make our multi-C6678 board mimic the TMDSEVM6678LE which works with h/w trace and the BHUSB560v2 ST.

With this modification we have abandoned the use of EMU0/1 pin connections to the other 3 C6678's devices eliminating the possibility for global-breakpoints and cross-triggering which we would like to have at our disposal for debug on our board.  The Emulation and Trace TRM (spru655i.pdf) clearly says that we should be able to configure our multi-C6678 custom board to connect all devices in a single JTAG scan chain as well as have EMU0/1 connected to all devices with EMU pins 2-18 being connected to C6678_0 for h/w trace.

Here's a snippet from the Emulation and Trace TRM (SPRU655i) Fig. 23 Pg 34 that clearly shows connecting all devices via JTAG in a single chain as well as connecting EMU0/1 to all devices.  This was our original design configuration intent for our custom 4-C6678 board.

The associated documentation found within that TRM suggests that this is clearly a viable implementation.  Nonetheless, configuring our custom 4-C6678 board in this manner proved to be problematic with h/w trace with the BHUSB560v2 ST.

In the end to get h/w trace to work on our board we resorted to reducing our JTAG and EMU0/1 pin connections to just a single C6678_0 device.

Our desire is to get this multi-device JTAG/EMU0/1 implementation to work.  Our h/w team has scrubbed our custom board and believe that it is fully in compliance with the guidelines set by TI documentation available.

Does this JTAG and h/w trace with EMU0/1 to multiple devices actually work?  Has this been demonstrated to be a viable implementation?

Is there other h/w design documentation that we should be looking at?  If so, please share that with us.

With this modification to use just to a single device we can connect to C6678_0 and perform h/w trace and inspect DDR3 Memory Bandwidth consumption on that device.

Here's a trace snapshot of a Memory Throughput & Latency Trace capture that we can now get...

I have a few questions regarding this output.

1. Several DDR3 masters were selected in the advanced settings, i.e. C66x_0-7, EDMA, PCIe, but these are not presented in the legend as selectable by Memory Throughput nor Minimum Average Latency graphs.  We would like to gain insight into how much of the memory bandwidth is being consumed by which masters.  How can we get these various masters to be shown and selectable within these graphs?

2.  The horizontal axis shows Timing (Ticks).  Is this in terms of the DSP clock cycles (1.25 GHz) or is this in terms of DDR3 clock cycles (667 Mhz)? What does Timing (Ticks) mean?

3.  Is there a way to configure an external trigger during h/w Trace?  How is the EMU Trigger Filter used within Advanced Properties?

Please share any documentation or other definitive information as to how to use this h/w Trace capability.

Thanks,

-George

Hi George,

Thank you for the additional details. This is all beyond my area of expertise. I will need to escalate this issue for further analysis.

Sorry for the delay. Engineering has responded with the below replies:

George Lathrop said:

Does this JTAG and h/w trace with EMU0/1 to multiple devices actually work?  Has this been demonstrated to be a viable implementation?

Is there other h/w design documentation that we should be looking at?  If so, please share that with us.

[CCS Engineering] We are unsure of this detail. It is possible the device experts may know

George Lathrop said:

How can we get these various masters to be shown and selectable within these graphs?

[CCS Engineering] If they are not in the graphs then no data was collected for those masters. It could be that there were non transaction in the time window data was collected. 

George Lathrop said:

What does Timing (Ticks) mean?

[CCS Engineering] This is the bus clock.

George Lathrop said:

Is there a way to configure an external trigger during h/w Trace?  How is the EMU Trigger Filter used within Advanced Properties?

[CCS Engineering] This may be possible. We will need to investigate.