This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
emulator connection problem using CCS
Part Number: TMDSEMU200-U
Tool/software: Code Composer Studio
On macOS and Linux, I have difficulty connecting to the XDS200 emulator. I always receive the following output for the "Test Connection" step in CCS after setting up a target configuration file.
[Start: Texas Instruments XDS2xx USB Debug Probe_0]Execute the command:%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity[Result]-----[Print the board config pathname(s)]------------------------------------/Users/chrisnc/.ti/ti/4/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'.E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_ioFailed to open i/o connection (xds2xxu:0)An error occurred while soft opening the controller.-----[An error has occurred and this utility has aborted]--------------------This error is generated by TI's USCIF driver or utilities.The value is '-250' (0xffffff06).The title is 'SC_ERR_ECOM_EMUNAME'.The explanation is:An attempt to access the debug probe via USCIF ECOM has failed.[End: Texas Instruments XDS2xx USB Debug Probe_0]
When I try to find the devices corresponding to the emulator I see:
$ ls -l /dev/tty.usbmodem*crw-rw-rw- 1 root wheel 21, 10 Sep 24 16:53 /dev/tty.usbmodem141420crw-rw-rw- 1 root wheel 21, 12 Sep 24 16:53 /dev/tty.usbmodem6
These have the correct permissions (read/write by everybody), but still the tools can't connect.
I also tried connecting with the command-line xds2xx_conf utility:
$ ti/ccsv8/ccs_base/common/uscif/xds2xx/xds2xx_conf get xds2xxu 0Error : Failed to open port connection : xds2xxu : 0 Error : test failed
I see these same problems also on Linux, and the permissions are also correct there:
$ ls -l /dev/ttyA*crw-rw-rw- 1 root dialout 166, 0 Sep 24 17:29 /dev/ttyACM0crw-rw-rw- 1 root dialout 166, 1 Sep 24 17:29 /dev/ttyACM1
On Linux the symptoms are slightly different; it hangs indefinitely when I run xds2xx_conf. Interestingly, while trying to debug this by running xds2xx_conf under strace to see what error the tool was encountering, it actually works and prints out the information from the get command! I've found no such workaround on macOS though. The debugger doesn't respond to CCS or the tool until I do this.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to desouza:
Sorry, I should have included the firmware version, it's 126.96.36.199, which appears to be the latest available. I can tell because when I am able to talk to the probe on Linux after using strace, it outputs the firmware version of the probe there.
I have already done the extra steps for the Linux host at the link you provided; the permissions of the device are correct. Any other theories? I strongly suspect that there is a bug in the host-side software that prevents it from finding the device, because it makes no sense to me otherwise why it would happen to work under strace, and that the probe is otherwise functional.
In reply to Christopher Copeland:
Please apologize for the lnog delay; I was sidetracked by many issues around here.
Thanks for sending the firmware information; it is certainly the latest release.
I just finished installing Ubuntu 18.04 (18.04.1) on a native machine (not a VM) and CCSv8.2.0 (installed as a regular user) and I can see the same behaviour as you: the xds2xx_conf gives up immediately when running as a user (Failed to open port connection) and locks up when running as sudo. I tested both USB2.0 and USB3.0 ports without an external Hub. CCS is also unable to talk to the probe, even when running as sudo.
Then, as you mentioned, running strace (as a sudo) once it still locks up. After killing the strace (Ctrl-C) and re-running the trace, everything starts to work well.
As expected, to make it work as a regular user I had to both add myself to the dialout group (for some reason I had to restart the system) and run the install_scripts.sh as a sudo. Several reboots and power cycles on the host, as well as plugging multiple models of XDS200 to different ports did not affect the regular functionality of my system.
The failure was observed with either the stock version of the TI Emulators component (188.8.131.52) and the latest updated version (8.0.803.0).
Since the probe works on my other systems (Ubuntu 14.04 and 16.04) on the same version of CCS (8.2.0), I suspect that is a combination of factors between this version and this OS. I gathered the strace data and will submit for analysis (attached).
That brings me to my next questions: what OS are you running? Are you running it natively or on a VM? (things tend to be trickier on a VM)
We test CCS on Ubuntu and, if I recall correctly, 18.04 should be fully supported by version 8.2.0.
I will try to get some additional insights from the developers.
Thanks for the update. On my setup my user is part of the dialout group, and I did run the install_drivers.sh script as root and then reboot, but I am still unable to use the probe without first running the xds2xx_conf command under strace (I didn't need sudo for this).
This occurs with both a VM and a machine running linux natively. The linux distribution I am using is debian, so very similar to Ubuntu, and it may be failing for the same reason(s) as you are experiencing on Ubuntu 18.04, though just adding myself to dialout and running the script did not fix the problem.
It's still the case that it doesn't work at all on macOS 10.14 (Mojave), even with the correct permissions on the /dev nodes and trying to run the tools as root.
That's fine about Mojave, and not too surprising.
On your linux setup, you mentioned that strace will cause it to work on subsequent tries like it did for me. If you reboot does it still work? My experience has been that once I run the xds2xx_conf program under strace once, it will work in CCS or any other means _until_ I reboot, at which point I need to use strace (or sudo) again. It wasn't clear to me from your earlier message whether this was the same for you.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.