XDS200 is not recognized by CCS6

Hello,

Pibe said:

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)

This error occurs when the host machine is unable to communicate to the emulator itself. I've seen this occur when something goes wrong with my environment and the debugger is unable access whatever process is needed to communicate to the emulator pod. Killing the related process in a task manager seems to help, so does a computer reboot.

Pibe said:

I even tried placing the JTAG connector looking one side or the other.

You connection should look like this:

Pibe said:

I am running the latest CCS 6 version 6.1.1.00022 on a Linux host (Kubuntu 15.10). I have tried re-running the installer, running manually the emupack installer (6.0.14.5), re-running the install_scripts script, and cleaning the workspace. I tried connecting to a USB 2.0 and USB 3.0 port.

I was able to connect using 6.1.1.00022 on Ubuntu 12.04-64. My setup looked like the picture above and I was plugged in a USB 2.0 port. Did you install CCS as 'user' and then ran the scripts as 'sudo'? Are you running as 'user' now?

Thanks

ki

Killing the related process in a task manager seems to help, so does a computer reboot.

Yep, I tried re-booting several times.

You connection should look like this:

Yep.  I tried the other way too out of disbelief that the mighty TI could design a board with the ribbon going inward... ;)

...I was plugged in a USB 2.0 port. Did you install CCS as 'user' and then ran the scripts as 'sudo'? Are you running as 'user' now?

Yes, yes, yes, and yes.

Thank you Ki for looking into this. My question still remains: how do I tell CCS to connect to a probe with index 1 instead of 0?

Regards,

Pibe

Pibe said:

My question still remains: how do I tell CCS to connect to a probe with index 1 instead of 0?

It should always default to '0' unless you have some other device plugged in that is taking that spot. Is there any other devices plugged in that may be?

In the mean time, change your target configuration to use io port 1 instead of 0

Oh, that's were it is! I did not follow the tree up. Thanks a lot, as soon as I get to the office I'll let you know how it went.

And no, there is no other probe connected.  Maybe when I tried the first time the MSP432P401R board was connected and it never went back to 0?

Pibe said:

Was the photo just to show the position of the cable or you are indicating the jumpers must be left on?

yes, that was only to show the cable position. When you have the JTAG switch to use the external JTAG, the jumpers should not matter.

I have an older (beta) board so some things may look different (like the switch too). But I also tried with a release version with the same (positive) results.

Pibe said:

And no, there is no other probe connected.  Maybe when I tried the first time the MSP432P401R board was connected and it never went back to 0?

The on-board XDS110 of the launchpad would not use the same ports used by the XDS200. If you already had an XDS200 plugged in and then you plugged in another one, then the second one would be set to io port 1.

Thank you for letting me know how to change the index. That fixed the problem of CCS not seeing the probe.  Still, there is an error that seems to involve the Launchpad itself.  This is the (partial) output from "Test Connection":

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

This utility has selected a 560/2xx-class product.

This utility will load the program 'xds2xxu.out'.

The library build date was 'Sep 17 2015'.

The library build time was '21:35:41'.

The library package version is '6.0.14.6'.

The library component version is '35.35.0.0'.

The controller does not use a programmable FPGA.

The controller has a version number of '13' (0x0000000d).

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]-----------------------------

This emulator does not create a reset log-file.

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

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

The value is '-233' (0xffffff17).

The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:

The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.

An attempt to scan the JTAG scan-path has failed.

The target's JTAG scan-path appears to be broken

with a stuck-at-ones or stuck-at-zero fault.

And, if I try to debug I obtain this:

I will try a couple of things, including using another Launchpad.  Any other clue will be appreciated.

Thank you again, Ki.

Pibe

I actually ran into that issue initially also. But I just kept trying and eventually the issue went away. It was odd. I didn't do anything special. I just kept repeating the 'Test Connection' button and then all of a sudden it started working. I thought it was just a symptom of my flaky beta board but maybe it is more widespread.

Also, just to confirm - you flipped the switch to use the external JTAG, right?

Yes, the switch is in the right position.  It was the jumpers.  I think I read in another post that they have to be removed to avoid any load from the on board XDS110 and assumed the connection to the external would go only through the switch.  Now the "Test Connection" succeeds:

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

/home/swdev/.ti/ti/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 'xds2xxu.out'.
The library build date was 'Sep 17 2015'.
The library build time was '21:35:41'.
The library package version is '6.0.14.6'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
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]-----------------------------

This emulator does not create a reset log-file.

-----[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: Texas Instruments XDS2xx USB Debug Probe_0]

But when I try to start a debugging session this happens:

CORTEX_M4_0: GEL Output: Memory Map Initialization Complete

CORTEX_M4_0: GEL Output: Halting Watchdog Timer

CORTEX_M4_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. 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 6.0.14.5)

CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

CORTEX_M4_0: Error occurred during flash operation: Could not read 0x00000004: target is not connected

CORTEX_M4_0: Flash Programmer: Found illegal reset vector address

CORTEX_M4_0: Error occurred during flash operation: Could not write 0xE0044000: target is not connected

CORTEX_M4_0: Error occurred during flash operation: Could not write 0xE0044004: target is not connected

........

Any idea of what may be happening now?  Should I try a lower TCLK?

Thank you,

Pibe