• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 2854 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

emulator connection problem using CCS

CCS/TMDSEMU200-U: emulator connection problem using CCS

Christopher Copeland
Expert 1243 points
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_io
Failed 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.usbmodem141420
crw-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 0
Error : 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/ttyACM0
crw-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.

  • 0
    TI__Guru**** 168417 points
    Hi,

    Depending on the firmware version of your Debug Probe, there are known issues when using the XDS200 with either Linux or macOS. The symptoms described by you match this scenario.

    This is mentioned in section 6 of the XDS200 page below.

    processors.wiki.ti.com/.../XDS200

    To update the firmware, check the procedure shown in section 7 of the page above. I can't stress enough that a Windows host is highly recommended for this procedure.

    Specifically in Linux, there is an additional step required to be run if you installed CCS as a regular user. Check:

    software-dl.ti.com/.../ccsv8_linux_host_support.html

    Hope this helps,
    Rafael
  • 0 in reply to desouza
    Expert 1243 points

    Hi Rafael,

    Sorry, I should have included the firmware version, it's 1.0.0.8, 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.

    Thanks,

    Chris

  • 0 in reply to Christopher Copeland
    TI__Guru**** 168417 points

    Chris,

    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 (8.0.27.9) 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.

    Regards,

    Rafael

    xds2xx_conf_straces.zip

  • 0 in reply to desouza
    Expert 1243 points

    Hi Rafael,

    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.

    Thanks,

    Chris

  • 0 in reply to Christopher Copeland
    TI__Guru**** 168417 points
    Chris,

    Wow, I wasn't aware a new macOS release was out. Let me double check this release today.

    I will create a new VM and see if I can re-trace the steps of the failing XDS200 so the developers can see it as well (my Ubuntu box didn't fail anymore).

    I will report back.

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168417 points
    Chris,

    On Mojave (macOS 10.14) the XDS200 fails to work at all. Given this OS is not yet officially supported/tested, I suspect the major problem here is that something changed between the two versions and needs to be investigated. I filed the bug report DBGTRC-4328 (in a few hours you can check its status in the link SDOWP in my signature below).

    Regarding Ubuntu, I wasn't yet able to create the Virtual Machine to recreate the scenario with the non-working XDS200 (my native install started working fine after the first strace). I will keep investigating and report back.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 1243 points

    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.

    Thanks,

    Chris

  • 0 in reply to Christopher Copeland
    TI__Guru**** 168417 points
    Chris,

    Yes, on Linux it has been working for me regardless if I restart/power cycle the host. That is why I am trying to set up a VM to see if I can try and reproduce this there and perhaps get a different outcome.

    The developer is baffled by this as well - in the past there were reports of the probe locking up after data was sent to it, but in general a "probe reboot" (i.e., unplug/re-plug) brought things back to normal.

    Definitely having strace causing the probe to start working again is unheard of. My theory is that strace is "slowing down" communications a bit and therefore being able to establish communications with the probe, but I can't necessarily debug it at this point.

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168417 points
    Chris,

    I tested a brand new VM with Ubuntu 18.04 (not 18.04.1) and it worked without a problem from the get go - i.e., no need to run the first strace as in my Ubuntu 18.04.1.

    I am trying a new VM with 18.04.1 just to be sure that is not the problem. I will double-check its status.

    If my theory is correct (the strace is slowing down communications on the native install), I will probably not be able to reproduce on a VM as well, as the layers of software impact the performance.

    I will report back my findings.

    Regards,
    Rafael
  • 0 in reply to desouza
    TI__Guru**** 168417 points
    Chris,

    I can reproduce this behaviour on the VM, but only on Ubuntu 18.04.1 (uname -r reports kernel 4.15.0-29-generic) but, the behaviour is the same as before: it starts to work flawlessly once I run the first strace xds2xxconf get xds2xxu 0

    In this case, I will keep the bug report open for further investigation, but there is a high probability that an overarching change on the kernel may be influencing that.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 1243 points

    Very interesting. So in a VM, 18.04 works but 18.04.1 does not.

    Earlier in the thread you mentioned trying Ubuntu 18.04 natively and seeing the same problem. Was that with 18.04 proper or 18.04.1?

  • 0 in reply to Christopher Copeland
    TI__Guru**** 168417 points
    Chris,

    Yes, I noticed that after I posted: the native install was 18.04.1 and not 18.04. I will fix my original post so it does not confuse anyone in future references to this thread.

    Regards,
    Rafael
  • 0 in reply to desouza
    Expert 1243 points

    Very interesting. So something about 18.04.1 makes this break. I will use an older version of the OS in the mean time. Thanks for looking into this? I will keep an eye out for updates on the macOS 10.14 situation as well.