EVM6678 emulator connecting error

Hi,

Please refer below wiki links which would help to debug using CCS and JTAG connectivity issues.

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

http://processors.wiki.ti.com/index.php/Multi-Core_Debug_with_CCSv5

Please ensure that the target EVM is powered ON and correct gel file is used to connect the DSP cores.

If the above information does not help to solve your issue, please post the steps followed to connect the DSP cores.

Thank you.

Hi Rajasekaran

I believe the way I connect with DSP and emulator configuration is correct, because I had successfully debug this EVM6678 board for several times. However, suddenly, the emulator on this board did not work, and I did not change anything. The errors was showing above.

I had redo it. It has the following errors now.

IcePick_D: Error connecting to the target: (Error -154 @ 0xFFFFFF66) One of the FTDI driver functions used to write data returned bad status or an error. (Emulation package 5.0.838.0) 

Besides that, in the *.ccxml file, I use the "test connection" function. It shows the following errors.

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

This error is generated by TI's USCIF driver or utilities.

The value is '-110' (0xffffff92).
The title is 'SC_ERR_OCS_ALREADY_OPEN'.

The explanation is:
This utility opened the controller but found it already in use.
You must exit other debuggers and utilities that access the
controller because this utility must be the only client.

Hi,

Moved this thread CCS Forum for faster response.

Thank you.

Hi,

Based on the initial error messages I think the emulator was reporting back to CCS the device had a power failure on the connected cores (1, 2, and 0), while failing to write to a specific address in core 3. In my opinion it seems the baseboard of the EVM suffered a power glitch while loading code to core 3 (the one with the failed write).

The following error message, (the IcePick_D error) seems to indicate the emulator cannot be initialized anymore - if you are using the onboard emulator provided with the EVM, that could be a power failure on the entire board.

The third error message is just related to the fact you probably had the CCS debugger already launched, which causes the Test Connection to indicate the emulator was already "in use". 

Can you try to check the fist page suggested by Rajasekaran to better pinpoint the exact broken link in this setup?

Hope this helps,

Rafael

Hi Desouza

I had tried several things to make it all right. 

1.Delete the debug launch configuration

2.  Launching a project target configuration manually( it failed when I start the debug session)

3. create a new *.ccxml file

But none of them made the debug working. And to be worse, when I debug my problem, it showed the error:"IcePick_D: Error connecting to the target: (Error -183 @ 0x0) The controller has detected a cable break far-from itself. The user must connect the cable/pod to the target. (Emulation package 5.0.838.0)".

And then, I check the TP22(1.8V_AUX) and TP26(3.3V_AUX), which power the on board emulator. They are OK. Also, I can hear the device plug-in sound generated by Windows, when I power on the board.

So can you help me on this?

Thank You.

Xining Yu

Xining,

Now the issue is a different one, which indicates a problem in the JTAG connection.

Just to clear out any doubts about how you are connecting to the C6678EVM, can you check the thread below and tell me from the pictures there what USB connection are you using?

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/279264.aspx

The thread shows several useful troubleshooting details with the board you have.

Regards,

Rafael

Desouza

The emulator i use is on aboard emualtor XDS100V2. The connection is showing below. I had read through the thread. Yes we have similar problem, however, what mentioned in that thread did not help me.

Thanks.

Xining,

Thanks for sending the picture. You are using the built in XDS100v1 emulator, therefore I assume you are selecting this emulator in your .ccxml file, is that correct?

Also, another striking difference I see with your board compared to all other EVM6678 boards I have ever seen: where's the heatsink and fan over the DSP?!? Did you remove them to take the picture or the board came this way?

If there is no heatsink/fan, I suspect the DSP is either continuously resetting due to the excess temperature or it completely failed due to the thermal stress. Both scenarios would potentially cause the issues you are seeing.

Can you confirm the details above?

By the way, I checked Advantech's documentation to see if the fan was removed in a later revision of the board, but nothing indicates that. For details, check their website at:

http://www.advantech.com/Support/TI-Evm/6678le_download3.aspx

Regards,

Rafael

Hi Desouza

Thanks for replying. We removed the fan on the DSP. It is because we want to plug this board in our chassis. However, the fan is too high for it. And indeed, in this chassis, it has fans to cool the DSP. As we are debuging our system, so everytime the DSP was working less than 10 minutes. So I do not think this DSP is not working. I think there are some problems within this emulator.

Xining,

Ok, thanks for confirming this. I hope you have at least a heatsink attached to the DSP, as airflow alone may not be enough to keep the DSP at a tolerable temperature.

Are you consistently getting the last error message? The reason is that I get this same error message if I inadvertently select XDS100v2 in my target configuration file. For this board you must select XDS100v1. Once this is cleared you may either get a successful connection or get back to the previous error.

Regards,

Rafael

Desouza

Thanks for your help.

Now, I remove this board off our chassis. And add heatsink and fan back again.

Yes, you are right I need to choose XDS100V1. Just like you said, it went back to the previous error. However, before debugging program. I use the ‘test connection" function in the *.ccxml tab. It shows everything all right. But after I started to debug the program(it will be failed), the result of "test connection" would be failed.

Can you tell me what I can do to let this emulator works again?

The successful result is showing below.

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -F inform,logfile=yes -S pathlength -S integrity

[Result]

-----[Print the board config pathname(s)]------------------------------------

C:\Users\yu5109\AppData\Local\.TI\3775577892\
0\0\BrdDat\testBoard.dat

-----[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 'Aug 30 2012'.
The library build time was '21:58:20'.
The library package version is '5.0.838.0'.
The library component version is '35.34.40.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 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).

-----[The log-file for the JTAG TCLK output generated from the PLL]----------

There is no hardware for programming the JTAG TCLK frequency.

-----[Measure the source and frequency of the final JTAG TCLKR input]--------

There is no hardware for measuring the JTAG TCLK frequency.

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

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

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]

Can anyone help me with this?

Thanks in advance