• Locked Locked
  • Replies 1 reply
  • Subscribers 53 subscribers
  • Views 1121 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.

K2H onboard XDS200 Connection problem on Ubuntu 16.04

Eugene P
Prodigy 40 points
Other Parts Discussed in Thread: AM1802
Hello!
 
We have a problem with JTAG connection in Ubuntu Linux. Our testing environment is:
  • OS: Ubuntu 16.04 LTS
  • Software: Code Composer Studio 6.2.0.00050
  • EVM: EVMK2H Rev 4.0 with onboard XDS200 debugger (firmware version 1.0.0.2, see below).
We can establish JTAG connection of EVMK2H in Windows 10 with Code Composer Studio 6.2.0.00050 and run
debug of EVM board. But on the same PC, running Ubuntu 16.04 we are getting error with the following output:
-----[Print the board config pathname(s)]------------------------------------
 
/home/epetrunin/.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'.
E_RPCENV_IO_ERROR(-6) No connection
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 Onboard Debug Probe_0]
 
I think we have the same case as described in this thread from official TI fourm:
https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/551512
Our lsusb output:
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 006: ID 05c8:0359 Cheng Uei Precision Industry Co., Ltd (Foxlink)
Bus 002 Device 005: ID 138a:003f Validity Sensors, Inc. VFS495 Fingerprint Reader
Bus 002 Device 004: ID 0bda:b001 Realtek Semiconductor Corp.
Bus 002 Device 003: ID 0451:bef0 Texas Instruments, Inc.
Bus 002 Device 002: ID 24ae:2002  
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 
Output of $ ./xds2xx_conf get xds2xxu 0:
 
boardRev=0
ipAddress=0.0.0.0
ipConfig=dhcp
ipGateway=255.255.255.255
ipNetmask=255.255.255.255
productClass=XDS2XX
productName=XDS200
serialNum=00:0E:99:03:9D:10
swRev=1.0.0.2
hostCPU=AM1802
emuCtrlType=Bit bang
extMemType=SDRAM
portUSB=true
portENET=false
portWIFI=false
portRS232=false
EnableUSBSerial=false
CurrentMeasure=false
And output of $ ls /etc/udev/rules.d/
52-xilinx-digilent-usb.rules 
52-xilinx-pcusb.rules 
61-msp430uif.rules 
70-mm-no-ti-emulators.rules 
71-bh-permissions.rules 
71-sd-permissions.rules 
71-ti-permissions.rules
It seems that the drivers for XDS200 is correctly installed. XDS200 is not connected to USB 3.0 port or any
USB hub. It is connected to the same USB port in Windows and Linux, but works good only in Windows.
 
Important note:
We have not tried to upgrade the firmware of onboard XDS200.
it can brick the debugger.

  • TI__Guru**** 169834 points
    Hi,

    The issue you are seeing is definitely caused by the incompatibility between the old firmware revision (1.0.0.2) in your XDS200 Onboard debugger and Linux. Unfortunately there is no way to make this debugger work on Linux other than updating the firmware.

    Regarding the statement on the wiki page you sent, there are some reports of customers bricking their debug probes using Windows or a Virtual Machine, but unfortunately this is too random and we couldn't find an exact root cause for investigation. I also have a bricked XDS200 Onboard debugger but in my case it was completely my fault: I was using a Mac OSX host.

    In this case I would consider two things before attempting the update process:
    - how difficult it is to send the board back to the manufacturer/distributor for a repair or replacement (if in warranty)
    - how easy it is to use or purchase an alternative way to debug the board (either by having a second board in hand or a standalone debug probe) in case the update fails

    Hope this helps,
    Rafael