• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 668 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/MSP432P401R: Unable to connect to MSP432P401R when using Zero Client PC.

Franklin Cooper
Intellectual 2020 points

Part Number: MSP432P401R

Tool/software: Code Composer Studio

I'm working with a university who is attempting to use the MSP432P401R on a zero client PC. They are unable to connect/program the board via CCS, CCS Cloud, Energia or xdsdfu to the MSP432P401R.  They have no issue using the MSP-EXP430G2, EK-LM4F120XL and MSP-EXP430F5529 on the same zero client PCs.

Here are the following observations on the zero client when attempting to debug this issue:

  • The most common zero client PC they are using is the 10zig Zero Client 293d.
  • Virtualized Host OS: Windows 7 Enterprise 64bit Version 6.1.7601 Service Pack 1 Build 7601
  • Device Manager detects XDS110 Class Application/User UART and XDS110 Class Auxilary Data Port.
  • Power led on MSP432P401R is on along with all the necessary jumpers
  • Tried various MSP432P401R. They don't work on the zero client but works on a traditional PC.
  • Code Composer Studio v8, Code Composer Studio Cloud and Energia reports that it fails to connect to the JTAG device when trying to upload a program.
  • xdsdfu.exe -e reports no errors but says "Found 0 devices"

We will appreciate help on resolving this issue. Please let me know what additional information we can provide.

Below are various screenshots showing driver information and error messages.

  • 0
    TI__Guru**** 171094 points

    Franklin,

    Error -260 is described in detail at the Debugging JTAG page below (search for the error number):

    http://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html 

    The fact the xdsdfu -e reports no Debug Probes found, indicates that, in fact, the issue is between the host and the Debug Probe. 

    Despite we don't claim support for thin clients, virtualization and remote services such as Citrix, I thought about some tests to try and isolate the issue. 

    - If you have available a different Debug Probe such as the TMDSEMU200-U or a TMDSEMU560V2STM-U, can you test and see if the same problem occurs? This would help isolate the problem to the Launchpad boards and their built-in XDS110 Debug Probes. 

    - A similar thing if you have a standalone TMDSEMU110-U probe or a different Launchpad kit such as the MSP-EXP432P4111. Perhaps it may be something tied to the specific the Launchpad kits (although I would be hard pressed to believe there would be a difference between them). 

    - Is there a way to test this environment in low traffic hours? Being a thin client (or Zero client), its performance will be highly dependent on the network traffic and usage. This test may be helpful to isolate the issue to the network. 

    I will try to think about a few additional details and report back. 

    Regards,

    Rafael

  • 0 in reply to desouza
    TI__Intellectual 2020 points

    I will have the university perform the test using the different debugger and boards. They will report back.

    Thanks for your help.

  • 0 in reply to Franklin Cooper
    TI__Intellectual 2020 points

    Hi Rafael,

    Is there anything beyond the below we should include in our test?

    • Install Code Composer Studio 9.1.0 which includes EMUPack v8.2.0.00004
    • Run xdsdfu.exe -e
    • If the above tool detects the jtag then attempt uploading a program using Code Composer Studio 9.1.0

    We plan to do the above with the different JTAGs you mentioned and the other MSP432 board you recommended.

  • 0 in reply to Franklin Cooper
    TI__Guru**** 171094 points

    Franklin,

    I can't think of any additional tests at this time. 

    Let me know the resuts of these. 

    Regards,

    Rafael

  • 0 in reply to desouza
    TI__Guru**** 171094 points

    For others following this thread, it is being worked offline. 

    I will post the results in this thread. 

  • 0 in reply to desouza
    TI__Guru**** 171094 points

    For others following this thread, some test results and a conclusion follow below: 

    - MSP-FET, XDS200 (TMDSEMU200-U) and XDS560v2 (TMDSEMU560V2STM-U) worked well in this environment;
    - XDS100v2 worked, but it was very slow;
    - XDS110 (both Launchpads and the standalone TMDSEMU110-U) did not work under any circumstances.

    Comments:

    It is very likely the setup includes built in support for CDC interface devices which optimizes those types of connections. The XDS200 and the MSP-FET do JTAG Debugging over a CDC interface. So with built-in support, those should work well.

    The XDS110 uses the CDC interface for the auxiliary UART port and for the SWO Trace. However, for JTAG Debugging and EnergyTrace, it uses bulk endpoints, which are most probably not supported directly by the setup vendor. For these USB interfaces that are not directly supported by them, they probably have to transmit and receive hardware register accesses, which is going to be (best case) very slow to (worst case) unusable.

    At this point there is a chance the CDC drivers could be the way to redirect this. However, it would be difficult to restructure the XDS110 to use CDC interfaces because the CDC interface requires an additional endpoint the probe does not have (all of the available endpoints of the TM4C device are already used). Also, re-architecting the stack to use a serial port instead of BULK endpoint which would be impractical at this point in time, due to the risk of breaking compatibility with the tens of thousands of existing XDS110 units already on the market. 

    This scenario is very similar to what was discussed with a Citrix environment as shown in the e2e thread below:

    https://e2e.ti.com/support/tools/ccs/f/81/t/743647

    At this point our choices of acting to fix the XDS110 are severely narrow.

    The alternatives would be either the use of XDS200 or XDS560v2 via USB interface, or XDS220 or XDS560v2 via Ethernet interface.

    Regards,

    Rafael