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.

CCS/CCSTUDIO: Failed to connected to XDS110 under Citrix virtual machine

Part Number: CCSTUDIO
Other Parts Discussed in Thread: TMDSEMU200-U, TMDSEMU560V2STM-UE

Tool/software: Code Composer Studio

Hi,

This is TI FAE, my customer recently report a issue that while using CCS under Citrix virtual machine, the device manager could find XDS port (COM),  but fail to connect to XDS in CCS. The detail information as followed pictures.

What I guess the root cause of the issue is that  firmware need to update in XDS110 to fit the environment of Citrix. Could you help look into? Thanks!

  • I join this thread to be a bystander.
  • Hi,

    I don't have a Citrix environment to try to reproduce this, therefore I will have to see if someone is using CCS on this environment.

    The screenshots indicate there is a XDS110 acknowledged by the remote host, but I am not entirely sure if Citrix virtualizes a Debug Probe attached to the local host. If that is the case, then I can't really promise anything - neither CCS nor our Debug Probes are tested in this environment.

    Regards,
    Rafael
  • Hi,
    Citrix redirects the device of the local host directly to the remote host, where the TI device is not visible on the local host, and only the remote host can view the device.
    The device I see on the physical is exactly the same as the one I see on the citrix virtual machine.
    I can provide remote if needed.
    Regards,
    chenjunjie
  • Hi Junjie,
    I agree with you, virtually.
  • Hi Junjie,

    As I suspected, unfortunately we don't test this configuration.

    The main issue I imagine it may happen is the longer delay associated with the data traffic between the local and the remote hosts, which may be completely unexpected by the emulation driver built into CCS and causes its own timeouts to expire - as a consequence, the tool gives up any connection attempts.

    You could potentially see if you can connect at the lowest level possible by opening the Target Configuration File (the file with the .ccxml extension) and click on the Test Connect button. I suspect this will not work, but given its data traffic is a lot smaller (just some minor transfers to validate the connection), there is a chance it may work and you could try to reduce the network latency between the two hosts.

    If that does not work at all, perhaps the latency is simply too much for the driver to allow a connection. Sorry.

    Regards,
    Rafael
  • This was resolved offline. For everyone else following this discussion, the root cause of the issue is located in the interactions between the Citrix Remote Desktop software and the XDS110 driver.

    == Explanation ==
    Two references at Citrix and USB.org sites that talk about USB Redirection in the Citrix Remote Desktop are shown below:
    support.citrix.com/.../CTX137939
    www.usb.org/defined-class-codes

    Basically, Citrix’s Generic USB Redirection is only implemented for specific classes and doesn’t include support for BULK interfaces that the XDS110 uses for debug and trace data. It is not possible today for Citrix Remote Desktop to support the Vendor Specific class (class code FFh) that we use.

    == Workarounds ==
    The only workarounds are:
    - use a different Debug Probe such as the XDS200 (which uses a standard CDC interface). The XDS200 was verified to successfully connect via the Citrix Remote Desktop.
    - use an Ethernet-based Debug Probe such as XDS220 (sold by the third party Spectrum Digital) or the XDS560v2 STM, which can be accessible via network by the remote CCS install.

    The Debug Probes mentioned above are:
    TMDSEMU200-U: www.ti.com/.../tmdsemu200-u
    TMDSEMU560V2STM-UE: www.ti.com/.../TMDSEMU560V2STM-UE
    XDS220: www.spectrumdigital.com/.../

    Regards,
    Rafael
  • Rafael,

    many thanks for your replay!
    Moving to virtual computers supported by Ethernet debug probes gives a lot in areas like remote work, backup, recovery, resource sharing, replication, upgrade/downgrade in a controlled environment for a whole team.
    This is the way to go.
    Thanks again!