• Locked Locked
  • Replies 26 replies
  • Subscribers 54 subscribers
  • Views 7805 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.

XDS troubleshooting on Linux

Hank Barta
Intellectual 970 points

I'm trying to debug using a Delfino controlCARD (F28377D) with expansion backplane and a Spectrum Digital XDS200 JTAG debugger. Here is what I've done so far.

1) Gotten this all working on my Windows 7 desktop to verify that I had switch settings working, XDS200 is functional and familiarize myself with the setup. (During this process I also upgraded CCS from 6.1 to 6.2.)

2) Plugged the board/debugger intro our Linux build server and repeated the process. When it came to configuring the "Target configuration" I configured as before "Texas Instruments XDS2xx USB Debug Probe":

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="Texas Instruments XDS2xx USB Debug Probe_0">
        <instance XML_version="1.2" desc="Texas Instruments XDS2xx USB Debug Probe_0" href="connections/TIXDS2XXUSB_Connection.xml" id="Texas Instruments XDS2xx USB Debug Probe_0" xml="TIXDS2XXUSB_Connection.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="Texas Instruments XDS2xx USB Debug Probe_0">
            <instance XML_version="1.2" href="drivers/tixds560icepick_c.xml" id="drivers" xml="tixds560icepick_c.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560c28x.xml" id="drivers" xml="tixds560c28x.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cla1.xml" id="drivers" xml="tixds560cla1.xml" xmlpath="drivers"/>
            <instance XML_version="1.2" href="drivers/tixds560cs_child.xml" id="drivers" xml="tixds560cs_child.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="TMS320F28377D_0" href="devices/tms320f28377d.xml" id="TMS320F28377D_0" xml="tms320f28377d.xml" xmlpath="devices"/>
                <device HW_revision="1" XML_version="1.2" description="" id="TMS320F28377D_0" partnum="TMS320F28377D">
                    <router HW_revision="1.0" XML_version="1.2" description="ICEPick_C router" id="IcePick_C_0" isa="ICEPICK_C">
                        <subpath id="Subpath_1">
                            <property Type="numericfield" Value="0x11" desc="Port Number_0" id="Port Number"/>
                        </subpath>
                    </router>
                </device>
            </platform>
        </connection>
    </configuration>
</configurations>

I clicked the "Test Connection" button. The test ran for a long time with the last line displayed :

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.

And after some minutes (a timeout?) completed and reported 

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]

This seems to be the generic 'can't communicate' with the USB debugger message. Following is what I find in dmesg output when

[1444128.176067] usb 4-1.2: new high-speed USB device number 12 using ehci-pci
[1444128.268904] usb 4-1.2: New USB device found, idVendor=0451, idProduct=bef0
[1444128.268909] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1444128.268913] usb 4-1.2: Product: XDS2xx USB Emulator - Composit
[1444128.268916] usb 4-1.2: Manufacturer: Spectrum Digital
[1444128.268918] usb 4-1.2: SerialNumber: S200-000E99039000
[1444128.269425] cdc_acm 4-1.2:1.0: ttyACM1: USB ACM device
[1444128.269903] cdc_acm 4-1.2:1.2: ttyACM2: USB ACM device

Perms on the TTY devices look OK (and I am a member of the dialout group.)

hbarta@itws007:/opt/ti/ccsv6/install_scripts$ ls -l /dev/ttyACM?
crw-rw-rw- 1 root dialout 166, 0 Oct 27 15:17 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 1 Oct 27 15:17 /dev/ttyACM1
crw-rw-rw- 1 root dialout 166, 2 Oct 27 15:17 /dev/ttyACM2

XDS200-lsusb.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
Device: ID 0451:bef0 Texas Instruments, Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x0451 Texas Instruments, Inc.
idProduct 0xbef0
bcdDevice 1.00
iManufacturer 1 Spectrum Digital
iProduct 2 XDS2xx USB Emulator - Composit
iSerial 3 S200-000E99039000
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 141
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 2 Communications
bFunctionSubClass 2 Abstract (modem)
bFunctionProtocol 1 AT-commands (v.25ter)
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x01
call management
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I think I have just attached the relevant entry for this device from 'lsusb -v'.

I ran the XDS200 firmware update procedure on Windows and found that the firmware version is 1.0.0.8 and there does not seem to be anything more recent. (The XDS200 was just purchased.)

I don't see any obvious problems with anything I have looked at. Versions of what I'm running are:

Ubuntu Linux 14.04 LTS

CCS 6.2.0.00050 (Linux and Windows 7)

Debugger probe lists the following information on the sticker (I have obfuscated the serial number):

Spectrum Digital Inc.
P/N 616410-0001A
S/N X2B_1601nnn (obfuscated)
Product: XDS200

Output following instructions on 

http://processors.wiki.ti.com/index.php/XDS200#Updating_the_XDS200_firmware

C:\ti\ccsv6\ccs_base\emulation\specdig\xds2xx>xds2xx_conf get xds2xxu 0
boardRev=1
ipAddress=0.0.0.0
ipConfig=dhcp
ipGateway=0.0.0.0
ipNetmask=0.0.0.0
productClass=XDS2XX
productName=XDS200
serialNum=00:0E:99:04:nn:nn   (obfuscated)
swRev=1.0.0.8
hostCPU=AM1802
emuCtrlType=Bit bang
extMemType=SDRAM
portUSB=true
portENET=false
portWIFI=false
portRS232=false
EnableUSBSerial=false
CurrentMeasure=false

C:\ti\ccsv6\ccs_base\emulation\specdig\xds2xx>update_xds2xx xds200

C:\ti\ccsv6\ccs_base\emulation\specdig\xds2xx>echo off
Updating CPLD
.
Updating Firmware
.
Rebooting
.
Reading Configuration
.
Check swRev is 1.0.0.8 or higher
.
boardRev=1
ipAddress=0.0.0.0
ipConfig=dhcp
ipGateway=0.0.0.0
ipNetmask=0.0.0.0
productClass=XDS2XX
productName=XDS200
serialNum=00:0E:99:04:nn:nn (obfuscated)
swRev=1.0.0.8
hostCPU=AM1802
emuCtrlType=Bit bang
extMemType=SDRAM
portUSB=true
portENET=false
portWIFI=false
portRS232=false
EnableUSBSerial=false
CurrentMeasure=false
Press any key to continue . . .

C:\ti\ccsv6\ccs_base\emulation\specdig\xds2xx>

I have previously used the XDS100 USB debugger built into the controlCARD on Linux mostly successfully. (Couldn't get it working inside a Docker container.)

Any help resolving this is very appreciated. If further information is needed, please let me know.

Thanks!

  • Intellectual 970 points
    I have just installed available updates for CCS6.2 including a debugger update but it does not seem to improve the situation.

    I also tried running CCS as root (via sudo) to see if it was a permissions problem and it seems not to be.
  • in reply to Hank Barta
    Intellectual 970 points
    To check out my procedure for creating the Target Configuration on Linux (and the S/W behind it) I created a target configuration for the built in XDS100 debugger and tested it. The test was successful.
  • in reply to Hank Barta
    Intellectual 970 points
    Any chance I can get someone to look into this?

    Am I asking in the right place?

    Thanks!
  • in reply to Hank Barta
    Intellectual 970 points
    I found this at Spectrum Digital: support.spectrumdigital.com/.../ but do not know how to apply it.

    Thanks!
  • in reply to Hank Barta
    TI__Guru**** 169874 points

    Hank,

    Please apologize for the delay and thanks for a very thorough post. It contains pretty much all details that would have been asked. A first detail: this Linux machine is native and not a VM or docker, right?

    I compared the output of both lsusb -v commands (I also have a Ubuntu 14.04/64) and could only find a small difference on the first line that describes where the XDS200 is mapped in the USB subsystem.

    My system said:
    Bus 001 Device 019: ID 0451:bef0 Texas Instruments, Inc.

    Your system said:
    Device: ID 0451:bef0 Texas Instruments, Inc.

    Therefore I ask: can you make sure the udev rules are correctly installed under the directory below?

    rules.d said:

    user@host:~$ ls -l /etc/udev/rules.d/
    total 36
    -rw-r--r-- 1 root root  381 Nov  1 10:42 61-msp430uif.rules
    -rwxr-xr-x 1 root root  711 Nov  1 10:42 70-mm-no-ti-emulators.rules
    -rw-r--r-- 1 root root  439 Mar  6  2015 70-persistent-net.rules
    -rw-r--r-- 1 root root  691 Sep 12 09:41 71-bh-permissions.rules
    -rw-r--r-- 1 root root  559 Sep 12 09:41 71-sd-permissions.rules
    -rw-r--r-- 1 root root 1814 Nov  1 10:42 71-ti-permissions.rules
    -rw-r--r-- 1 root root  544 Aug  2 09:43 99-icdi.rules
    -rw-r--r-- 1 root root 2998 Feb 25  2015 99-jlink.rules
    -rw-r--r-- 1 root root 1157 Apr 14  2014 README

    If you don't see the highlighted file above (others may be missing depending on the installed components) then this may be getting on the way of a successful connection. Check the second important remark in the link below for details:

    http://processors.wiki.ti.com/index.php/Linux_Host_Support_CCSv6#Installation_Instructions

    At last, it may well be an issue with incompatible HUB or USB port on the Linux machine that is unknown. In this case, switching the port should help workaround this.

    I will think about additional scenarios and reply back.

    Hope this helps,

    Rafael

  • in reply to desouza
    Intellectual 970 points

    Hi Rafael,

    Thank you for your reply.


    This is native Linux, not a VM or Docker container.

    Rules in udev are

    hbarta@itws007:~$ ls -l /etc/udev/rules.d/ 
total 24
-rw-r--r-- 1 root root  626 Apr 11  2016 70-persistent-net.rules
-rw-r--r-- 1 root root  691 Oct 27 15:16 71-bh-permissions.rules
-rw-r--r-- 1 root root  559 Oct 27 15:16 71-sd-permissions.rules
-rw-r--r-- 1 root root 1814 Oct 28 09:06 71-ti-permissions.rules
-rw-r--r-- 1 root root  343 Nov 20  2015 80-docker.rules
-rw-r--r-- 1 root root 1157 Apr 14  2014 README
hbarta@itws007:~$

    I cannot see anything highlighted in your post but I presume you meant to point out the '71-*' files. If there is something missing, please let me know.

    I have the device plugged into what I believe to be a USB 2.0 port on the front of a Dell PC. (It is not easy to tell because the markings are subtle.) I will try other ports to see if it helps.

    Can you share what brand PC you are using and/or the USB HUB ID in case that matters? I have attached complete 'lsusb -v' output for the Linux PC I am working on.

    I have another thought about this. I am logging into the PC via 'ssh -Y' and not using a console X session. Do you think that matters? I ask because I think some actions (such as when inserting a USB thumb drive) depend on the user logged into the console so e.g. a thumb drive is made accessible to the console user. We have multiple users on this machine.

    complete-lsusb.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    Bus 004 Device 006: ID 413c:2107 Dell Computer Corp.
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 1.10
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 8
    idVendor 0x413c Dell Computer Corp.
    idProduct 0x2107
    bcdDevice 1.15
    iManufacturer 1 Dell
    iProduct 2 Dell USB Entry Keyboard
    iSerial 0
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 34
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
    (Bus Powered)
    Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 3 Human Interface Device
    bInterfaceSubClass 1 Boot Interface Subclass
    bInterfaceProtocol 1 Keyboard
    iInterface 0
    HID Device Descriptor:
    bLength 9
    bDescriptorType 33
    bcdHID 1.10
    bCountryCode 0 Not supported
    bNumDescriptors 1
    bDescriptorType 34 Report
    wDescriptorLength 65
    Report Descriptors:
    ** UNAVAILABLE **
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0008 1x 8 bytes
    bInterval 10
    Device Status: 0x0000
    (Bus Powered)
    Bus 004 Device 005: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    thanks,

    hank

  • in reply to Hank Barta
    TI__Guru**** 169874 points

    Hank,

    Hank Barta said:
    I cannot see anything highlighted in your post but I presume you meant to point out the '71-*' files. If there is something missing, please let me know.

    Yes, sorry. I meant to highlight the <71-ti-permissions.rules> file. Nothing missing from your setup.

    Hank Barta said:
    Can you share what brand PC you are using and/or the USB HUB ID in case that matters?

    It is a Dell Precision T3500 (2.6GHz Xeon with 4GB RAM and only USB1.1/2.0 ports). The output of the lsusb-v is attached below and the XDS200 is connected to the USB2.0 Hub (a port at the front of the PC).

    lsusb_output_complete.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 9 Hub
    bDeviceSubClass 0 Unused
    bDeviceProtocol 0 Full speed (or root) hub
    bMaxPacketSize0 64
    idVendor 0x1d6b Linux Foundation
    idProduct 0x0002 2.0 root hub
    bcdDevice 3.16
    iManufacturer 3 Linux 3.16.0-70-generic ehci_hcd
    iProduct 2 EHCI Host Controller
    iSerial 1 0000:00:1d.7
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 25
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
    Self Powered
    Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 9 Hub
    bInterfaceSubClass 0 Unused
    bInterfaceProtocol 0 Full speed (or root) hub
    iInterface 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0004 1x 4 bytes
    bInterval 12
    Hub Descriptor:
    bLength 9
    bDescriptorType 41
    nNbrPorts 6
    wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    bPwrOn2PwrGood 10 * 2 milli seconds
    bHubContrCurrent 0 milli Ampere
    DeviceRemovable 0x00
    PortPwrCtrlMask 0xff
    Hub Port Status:
    Port 1: 0000.0100 power
    Port 2: 0000.0100 power
    Port 3: 0000.0100 power
    Port 4: 0000.0100 power
    Port 5: 0000.0100 power
    Port 6: 0000.0100 power
    Device Status: 0x0001
    Self Powered
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Hank Barta said:
    I have attached complete 'lsusb -v' output for the Linux PC I am working on.

    The file you sent only seems to have the XDS100 that is built into the F28M36 kit. In any case, it seems you have at least one USB3.0 Hub at Bus 002. When you connect your XDS200 and issue a lsusb you can find which port type is being used.

    Hank Barta said:
    I have another thought about this. I am logging into the PC via 'ssh -Y' and not using a console X session. Do you think that matters? I ask because I think some actions (such as when inserting a USB thumb drive) depend on the user logged into the console so e.g. a thumb drive is made accessible to the console user. We have multiple users on this machine.

    Hmm, maybe or maybe not. However, in your original post you seem to indicate you are running the GUI by using the target configuration editor, running the "Test Connection" button, etc.

    In any case, try to run any of the utilities from the command line: either the xds2xx_conf -e or the dbgjtag -X emulator,driver=xds2xxu,ioport=0 -rv (to see if the JTAG debugger is recognized from Linux) or ultimately loadti (to see if you can connect and load code to the device via the command line)

    Unless your system differentiates between a remote and a local user regarding privileges, I can't imagine the low-level utilities failing in a pure command line remote session. 

    Hope this helps,

    Rafael 

  • in reply to desouza
    Intellectual 970 points

    complete-lsusb-01.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    Bus 004 Device 006: ID 413c:2107 Dell Computer Corp.
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 1.10
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    bDeviceProtocol 0
    bMaxPacketSize0 8
    idVendor 0x413c Dell Computer Corp.
    idProduct 0x2107
    bcdDevice 1.15
    iManufacturer 1 Dell
    iProduct 2 Dell USB Entry Keyboard
    iSerial 0
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 34
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
    (Bus Powered)
    Remote Wakeup
    MaxPower 100mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 3 Human Interface Device
    bInterfaceSubClass 1 Boot Interface Subclass
    bInterfaceProtocol 1 Keyboard
    iInterface 0
    HID Device Descriptor:
    bLength 9
    bDescriptorType 33
    bcdHID 1.10
    bCountryCode 0 Not supported
    bNumDescriptors 1
    bDescriptorType 34 Report
    wDescriptorLength 65
    Report Descriptors:
    ** UNAVAILABLE **
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0008 1x 8 bytes
    bInterval 10
    Device Status: 0x0000
    (Bus Powered)
    Bus 004 Device 005: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.00
    bDeviceClass 0 (Defined at Interface level)
    bDeviceSubClass 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Oops! Captured lsusb when working with the other emulator. I've reconnected the XDS200 and captured new list. (attached)

    This PC is also a Dell, a Precision T7610 and I'm also using one of the ports on the front of the case. It has a dual processor motherboard and /proc/cpuinfo lists 48 "Intel(R) Xeon(R) CPU E5-2697 v2" cores. 

    I'm using the CCS GUI through a Windows X server (Cygwin) and 'ssh -y user@host' type of connection. 

    thanks,

    hank

  • in reply to Hank Barta
    Intellectual 970 points
    Hi Rafael,
    I did log in on the console to see if that mattered. It did not.

    thanks,
    hank
  • in reply to Hank Barta
    Intellectual 970 points

    More things I've tried...

    Uninstall and reinstall of CCS 6.2 and drivers. (Previous install may have been over 6.1) No change.

    Move XDS200 to another USB connector. I noticed that the XDS200 was sharing the 'hub' with some other devices:

    hbarta@itws007:~/Downloads$ tree /dev/bus/usb
/dev/bus/usb
├── 001
│   └── 001
├── 002
│   └── 001
├── 003
│   ├── 001
│   └── 002
└── 004
    ├── 001
    ├── 002
    ├── 005
    ├── 006
    ├── 011
    └── 027

4 directories, 10 files
hbarta@itws007:~/Downloads$ lsusb
Bus 004 Device 006: ID 413c:2107 Dell Computer Corp. 
Bus 004 Device 005: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 004 Device 011: ID 0d28:0204 NXP LPC1768
Bus 004 Device 027: ID 0451:bef0 Texas Instruments, Inc. 
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

    Moving to another connector on the front panel gets it on another USB hub by itself.

    hbarta@itws007:~/Downloads$ lsusb
Bus 004 Device 006: ID 413c:2107 Dell Computer Corp. 
Bus 004 Device 005: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 004 Device 011: ID 0d28:0204 NXP LPC1768
Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0451:bef0 Texas Instruments, Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
hbarta@itws007:~/Downloads$ tree /dev/bus/usb
/dev/bus/usb
├── 001
│   ├── 001
│   └── 004
├── 002
│   └── 001
├── 003
│   ├── 001
│   └── 002
└── 004
    ├── 001
    ├── 002
    ├── 005
    ├── 006
    └── 011

    No change. :(

  • in reply to Hank Barta
    Intellectual 970 points

    Debug Server Log of a 'test connection' operation.

    0677.debugServerLog.log
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    0x7FAAF5FCF740 51568 3 XPCOM R: ( (dsILogger*)0x7fa9781bca00 )->redirect( /home/hbarta/USB/debugServerLog.log ) = 0x00000000
    0x7FAAF5FCF740 51568 3 XPCOM C: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( 0x7ffd680321f0 )
    0x7FAAF5FCF740 51568 3 XPCOM R: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( *0x7ffd680321f0 = /home/hbarta/USB/debugServerLog.log ) = 0x00000000
    0x7FAAF5FCF740 51568 3 XPCOM C: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( 0x7ffd680321f0 )
    0x7FAAF5FCF740 51568 3 XPCOM R: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( *0x7ffd680321f0 = /home/hbarta/USB/debugServerLog.log ) = 0x00000000
    0x7FAAF5FCF740 51568 3 XPCOM C: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( 0x7ffd680321f0 )
    0x7FAAF5FCF740 51568 3 XPCOM R: ( (dsILogger*)0x7fa9781bca00 )->getLogFile( *0x7ffd680321f0 = /home/hbarta/USB/debugServerLog.log ) = 0x00000000
    0x7FAAE1F26700 55092 3 XPCOM C: ( (dsIDebugger*)0x7fa9781b82d0 )->generateBoardDataFile( /root/ti/CCSTargetConfigurations/NewTargetConfiguration.ccxml, 0x00000000, 0x7faae1f238f0, 0x7faae1f23908 )
    0x7FAAE1F26700 55092 3 COM_DBG_IF C: 10dsDebugger::OnTaskStart()
    0x7FAAE1F26700 55092 3 COM_DBG_IF R: 10dsDebugger::OnTaskStart()
    0x7FAAE1F26700 55092 5 COM_DBG_IF I: Final Release for 14CoProgressTask (this = 0x7fa9b40009a8)
    0x7FAAE1F26700 55092 5 COM_DBG_IF I: Final Release for N14XPCOMFramework5EventINS_17EventTemplateArgsI14dsIStringEventPKc22dsIStringEventCallbackEEEE (this = 0x7fa9b4002b88)
    0x7FAAE1F26700 55092 5 COM_DBG_IF I: Final Release for N14XPCOMFramework5EventINS_17EventTemplateArgsI14dsIObjectEventP11nsISupports22dsIObjectEventCallbackEEEE (this = 0x7fa9b4002ae8)
    0x7FAAE1F26700 55102 3 SETUP I: SELECT sql FROM sqlite_master ORDER BY tbl_name, name
    0x7FAAE1F26700 55103 3 SETUP I: Loading repository "/opt/ti/ccsv6/ccs_base/common/targetdb/"
    0x7FAAE1F26700 55103 3 SETUP I: SELECT * FROM TargetDB_Repositories
    0x7FAAE1F26700 55103 3 SETUP I: SELECT * FROM TargetDB_Repositories WHERE dbid=1
    0x7FAAE1F26700 55103 3 SETUP I: PRAGMA journal_mode = MEMORY
    0x7FAAE1F26700 55103 3 SETUP I: PRAGMA synchronous = OFF
    0x7FAAE1F26700 55103 3 SETUP I: BEGIN IMMEDIATE TRANSACTION
    0x7FAAE1F26700 55103 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2006_regids.xml"
    0x7FAAE1F26700 55104 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=1
    0x7FAAE1F26700 55104 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470RXX_regids.xml"
    0x7FAAE1F26700 55104 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=2
    0x7FAAE1F26700 55104 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS700C41XX_regids.xml"
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=3
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS320C66XX_regids.xml"
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=4
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2001_regids.xml"
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=5
    0x7FAAE1F26700 55105 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470R9X_regids.xml"
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=6
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2003_regids.xml"
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=7
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470R25X_regids.xml"
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=8
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS320C6XXX_regids.xml"
    0x7FAAE1F26700 55106 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=9
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2004_regids.xml"
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=10
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS700C40XX_regids.xml"
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=11
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS225C100_regids.xml"
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=12
    0x7FAAE1F26700 55107 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="CS_DAP_0_regids.xml"
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=13
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2030_regids.xml"
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=14
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2000_regids.xml"
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=15
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470REX_regids.xml"
    0x7FAAE1F26700 55108 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=16
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2028_regids.xml"
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=17
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470R2X_regids.xml"
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=18
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470R15X_regids.xml"
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=19
    0x7FAAE1F26700 55109 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470RDX_regids.xml"
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=20
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2008_regids.xml"
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=21
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS470RCX_regids.xml"
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=22
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2007_regids.xml"
    0x7FAAE1F26700 55110 3 SETUP I: SELECT * FROM TargetDB_Files WHERE dbid=23
    0x7FAAE1F26700 55111 3 SETUP I: SELECT * FROM TargetDB_Files WHERE Filename="TMS192C2027_regids.xml"
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • in reply to Hank Barta
    Guru 92251 points

    Hank Barta said:
    Debug Server Log of a 'test connection' operation.

    I can't see any obvious problem from the debug server log file, or from the other information you have posted.

    Some suggestions based upon troubleshooting other debug probe problems under Linux:

    1) Can you look at the dmesg output and /var/log/syslog before and after the test connection and see if the failed test connection reports any messages in dmesg or /var/log/syslog ?

    2) Can you try downloading a program using loadti and post the output from loadti?

    This is because sometimes loadti gives a more informative error message than trying a test connection or starting a debug session in the CCS GUI.

  • in reply to Chester Gillon
    Intellectual 970 points

    (I'll try again. The first post never completed.)

    Hi Chester,

    Here is the information you requested. I have included some information for both XDS100 (controlCARD) and XDS200 since the XDS100 works and the XDS200 so far does not.

    First XDS200 messages from dmesg and /var/log/syslog when I unplug and plug in the debugger.

    dmesg XDS200 disconnect followed by reconnect

[2369245.007449] usb 1-2: USB disconnect, device number 4

[2369256.280082] usb 1-2: new high-speed USB device number 5 using xhci_hcd

[2369256.410916] usb 1-2: New USB device found, idVendor=0451, idProduct=bef0

[2369256.410921] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[2369256.410925] usb 1-2: Product: XDS2xx USB Emulator - Composit
[2369256.410928] usb 1-2: Manufacturer: Spectrum Digital
[2369256.410930] usb 1-2: SerialNumber: S200-000E99039000
[2369256.414652] cdc_acm 1-2:1.0: ttyACM1: USB ACM device
[2369256.415312] cdc_acm 1-2:1.2: ttyACM2: USB ACM device

from var/log/syslog
Nov  7 07:16:20 itws007 kernel: [2369245.007449] usb 1-2: USB disconnect, device number 4
Nov  7 07:16:31 itws007 kernel: [2369256.280082] usb 1-2: new high-speed USB device number 5 using xhci_hcd
Nov  7 07:16:31 itws007 kernel: [2369256.410916] usb 1-2: New USB device found, idVendor=0451, idProduct=bef0
Nov  7 07:16:31 itws007 kernel: [2369256.410921] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov  7 07:16:31 itws007 kernel: [2369256.410925] usb 1-2: Product: XDS2xx USB Emulator - Composit
Nov  7 07:16:31 itws007 kernel: [2369256.410928] usb 1-2: Manufacturer: Spectrum Digital
Nov  7 07:16:31 itws007 kernel: [2369256.410930] usb 1-2: SerialNumber: S200-000E99039000
Nov  7 07:16:31 itws007 kernel: [2369256.414652] cdc_acm 1-2:1.0: ttyACM1: USB ACM device
Nov  7 07:16:31 itws007 kernel: [2369256.415312] cdc_acm 1-2:1.2: ttyACM2: USB ACM device
Nov  7 07:16:31 itws007 mtp-probe: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:1c.0/0000:06:00.0/usb1/1-2"
Nov  7 07:16:31 itws007 mtp-probe: bus: 1, device: 5 was not an MTP device

    Next connect XDS100

    From 'dmesg'

[2370053.156085] usb 1-2: new high-speed USB device number 6 using xhci_hcd
[2370053.291405] usb 1-2: New USB device found, idVendor=0403, idProduct=a6d0
[2370053.291420] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2370053.291424] usb 1-2: Product: Texas Instruments Inc.XDS100 Ver 2.0
[2370053.291426] usb 1-2: Manufacturer: TI
[2370053.291429] usb 1-2: SerialNumber: F28M36X
[2370053.298145] usb 1-2: Ignoring serial port reserved for JTAG
[2370053.302262] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[2370053.302337] usb 1-2: Detected FT2232H
[2370053.303037] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[2370053.314019] usb 1-2: Ignoring serial port reserved for JTAG
[2370053.323330] usb 1-2: Ignoring serial port reserved for JTAG
[2370053.335605] usb 1-2: Ignoring serial port reserved for JTAG

from /var/log/syslog

Nov  7 07:29:48 itws007 kernel: [2370053.156085] usb 1-2: new high-speed USB device number 6 using xhci_hcd
Nov  7 07:29:48 itws007 kernel: [2370053.291405] usb 1-2: New USB device found, idVendor=0403, idProduct=a6d0
Nov  7 07:29:48 itws007 kernel: [2370053.291420] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov  7 07:29:48 itws007 kernel: [2370053.291424] usb 1-2: Product: Texas Instruments Inc.XDS100 Ver 2.0
Nov  7 07:29:48 itws007 kernel: [2370053.291426] usb 1-2: Manufacturer: TI
Nov  7 07:29:48 itws007 kernel: [2370053.291429] usb 1-2: SerialNumber: F28M36X
Nov  7 07:29:48 itws007 kernel: [2370053.298145] usb 1-2: Ignoring serial port reserved for JTAG
Nov  7 07:29:48 itws007 kernel: [2370053.302262] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
Nov  7 07:29:48 itws007 kernel: [2370053.302337] usb 1-2: Detected FT2232H
Nov  7 07:29:48 itws007 kernel: [2370053.303037] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
Nov  7 07:29:48 itws007 mtp-probe: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:1c.0/0000:06:00.0/usb1/1-2"
Nov  7 07:29:48 itws007 mtp-probe: bus: 1, device: 6 was not an MTP device
Nov  7 07:29:48 itws007 kernel: [2370053.314019] usb 1-2: Ignoring serial port reserved for JTAG
Nov  7 07:29:48 itws007 kernel: [2370053.323330] usb 1-2: Ignoring serial port reserved for JTAG
Nov  7 07:29:48 itws007 kernel: [2370053.335605] usb 1-2: Ignoring serial port reserved for JTAG

    Output from 'loadti.sh'

    Output from 'loadti.sh'

hbarta@itws007:~/sample/blinky_cpu01/CPU1_RAM$ /opt/ti/ccsv6/ccs_base/scripting/examples/loadti/loadti.sh -c /home/hbarta/ti/CCSTargetConfigurations/XDS200.ccxml -x XDS200-log.xml /opt/ti/ccsv6/ccs_base/scripting/examples/loadti

***** DSS Generic Loader *****

START: 08:07:25 GMT-0600 (CST)

Configuring Debug Server for specified target...
Done
E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)
SEVERE: IcePick_C_0: Error initializing emulator: (Error -2083 @ 0x0)
Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
(Emulation package 6.0.407.6)


SEVERE: Could not start server: DebugServer.1: IcePick_C_0: Error initializing emulator: (Error -2083 @ 0x0)
Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
(Emulation package 6.0.407.6)


org.mozilla.javascript.WrappedException: Wrapped com.ti.ccstudio.scripting.environment.ScriptingException: Could not start server: DebugServer.1: IcePick_C_0: Error initializing emulator: (Error -2083 @ 0x0)
Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
(Emulation package 6.0.407.6)

 (/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js#159)
        at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1693)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:160)
        at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:204)
        at org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:76)
        at org.mozilla.javascript.gen.c1._c4(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js:159)
        at org.mozilla.javascript.gen.c1.call(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js)
        at org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
        at org.mozilla.javascript.gen.c1._c0(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js:9)
        at org.mozilla.javascript.gen.c1.call(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js)
        at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:340)
        at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2758)
        at org.mozilla.javascript.gen.c1.call(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js)
        at org.mozilla.javascript.gen.c1.exec(/opt/ti/ccsv6/ccs_base/scripting/examples/loadti/main.js)
        at org.mozilla.javascript.tools.shell.Main.evaluateScript(Main.java:503)
        at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:425)
        at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:391)
        at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:382)
        at org.mozilla.javascript.tools.shell.Main.processFiles(Main.java:179)
        at org.mozilla.javascript.tools.shell.Main$IProxy.run(Main.java:100)
        at org.mozilla.javascript.Context.call(Context.java:528)
        at org.mozilla.javascript.ContextFactory.call(ContextFactory.java:450)
        at org.mozilla.javascript.tools.shell.Main.exec(Main.java:162)
        at com.ti.ccstudio.apps.internal.scripting.RunScript$1.run(RunScript.java:88)
Caused by: com.ti.ccstudio.scripting.environment.ScriptingException: Could not start server: DebugServer.1: IcePick_C_0: Error initializing emulator: (Error -2083 @ 0x0)
Unable to communicate with the debug probe. Confirm debug probe configuration and connections, reset the debug probe, and retry the operation.
(Emulation package 6.0.407.6)


        at com.ti.debug.engine.scripting.DebugServer$SessionFactory.<init>(DebugServer.java:164)
        at com.ti.debug.engine.scripting.DebugServer.openSession(DebugServer.java:1327)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
        at java.lang.reflect.Method.invoke(Method.java:620)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:145)
        ... 21 more
hbarta@itws007:~/sample/blinky_cpu01/CPU1_RAM$

    I have tried to attach the log produced by loadti.sh as well as the .ccxml file used. The forum server/software seems to hang if I try to attach the XML log file. After canceling the upload (stuck in progress for over an hour while I went to a meeting) I cannot go back to the file upload dialog as it still says 'loading'


    The forum S/W rejected the .CCXML file so I have removed that. There are no attachments to this post. I will follow up with another post and attempt to get the attachments uploaded.

    (Note: Due to an unfortunate edit the command for 'loadti.sh' does not include the path to the .OUT file but retrying with that fixed did not change the result.)

    I also loaded the program using 'loadti.sh' and the XDS100 debugger and that worked without difficulty.

    thanks,

    hank

  • in reply to Hank Barta
    Intellectual 970 points

    TMS320F28377D.ccxml.gz

    target configuration for the testing two posts previous.


    (It baffles me that ccxml is not a valid file extension for uploads.)

  • in reply to Hank Barta
    Intellectual 970 points

    At 

    http://processors.wiki.ti.com/index.php/XDS200#Updating_the_XDS200_firmware

    I see the statement

    C:\>cd C:\ti\ccsv6\ccs_base\emulation\specdig\xds2xx - this only exists if Spectrum Digital support is installed. It is mandatory if you have a XDS220

    Looking at the Linux equivalent directory I find:

    hbarta@itws007:/opt/ti/ccsv6/ccs_base/emulation/specdig$ tree
.
├── docs
│   └── pdf
│       ├── TechNote_10.pdf
│       ├── TechNote_11.pdf
│       ├── xds560v2_quickstart_guide.pdf
│       └── xds560v2_techref.pdf
├── ReleaseNotes.txt
└── sd1.ico

    Is our installation deficient? I've isntalled CCS 6.2 twice (once an upgrade to 6.1 and the second a clean install) and installed the device drivers both times. I also installed the most recent drivers I found at 

    http://processors.wiki.ti.com/index.php/XDS_Emulation_Software_Package

     because I was not able to determine if the the installed drivers were current.

    thanks,

    hank

     

  • in reply to Hank Barta
    Guru 92251 points

    Hank Barta said:
    Output from 'loadti.sh'

    OK, from the loadti.sh output and log I can't see any more information about the cause of the failure.

    Some other options are:

    1) Run loadti.sh as sudo to eliminate any permissions problem.

    2) If running loadti.sh as sudo doesn't fix the problem, try running loadti.sh under strace and post a zip file of the strace output, as strace may recording where the failure is occurring. 

  • in reply to Chester Gillon
    Intellectual 970 points
    Hi Chester,
    Thanks for the suggestions. I had tried CCS as root and that did not help. I will try loadti.sh to see if that is different. (I thought the actual connection was via a 'debug server' so that's what really would need to run as root. Perhaps it inherits permissions from CCS/loadti.sh.)

    I did try running CCS under strace and that was a bit of a fools errand. We only have a 500GB drive. ;) Running loadti.sh under strace sounds like a better idea.

    I did have our admin reboot the Linux box. Good news: I have not been wasting TI's time chasing a problem that could be fixed by a reboot. :D Bad news: Reboot did not fix the problem. :(
  • in reply to Hank Barta
    Guru 92251 points

    Hank Barta said:
    (I thought the actual connection was via a 'debug server' so that's what really would need to run as root. Perhaps it inherits permissions from CCS/loadti.sh.)

    The 'debug server' is a collection of shared object files which get loaded by the CCS / loadti.sh processes. I.e. there isn't an actual separate 'server' process.

    Hank Barta said:
    Running loadti.sh under strace sounds like a better idea.

    loadti.sh might spawn some child processes, so best to use the strace -f option to trace child processes.

    [E.g. when I last used strace to debug a USB2000 connection problem under Linux found the the problem was that a child process was getting a SIGSEGV - https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/541444]

  • in reply to Chester Gillon
    Intellectual 970 points

    Hi Chester,

    Running loadti.sh as root made no difference. I ran as a normal user and collected output from 'strace -f' (attached.) The output to the console was

    hbarta@itws007:~/sample/blinky_cpu01/CPU1_RAM$ strace -f 2>strace.txt /opt/ti/ccsv6/ccs_base/scripting/examples/loadti/loadti.sh -c /home/hbart/ti/CCSTargetConfigurations/XDS200.ccxml -x XDS200-log.xml blinky_cpu01.out

***** DSS Generic Loader *****

START: 08:33:30 GMT-0600 (CST)

Configuring Debug Server for specified target...
Done
E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)
hbarta@itws007:~/sample/blinky_cpu01/CPU1_RAM$

    strace.txt.gz

    thanks,

    hank

  • in reply to Hank Barta
    TI__Guru**** 169874 points

    Hank,

    Thanks for sending the log. I can spot some errors accessing directories starting at line 1244977 but I have no idea why CCS is trying to access these invalid locations.

    That brings me a suspicion that either a CCS component or the entire install are corrupt.

    I just noticed I have CCSv6.2.0.00048. I will install CCSv6.2.00050 and collect some strace logs as well to see if I can reproduce this.

    I will get back with my findings.

    Regards,

    Rafael

  • in reply to desouza
    Intellectual 970 points

    Hi Rafael,

    That line does look a bit odd.

    [pid 33754] access("/opt/ti/ccsv6/emulation/drivers/NONE", F_OK) = -1 ENOENT (No such file or directory)

    The directory /opt/ti/ccsv6/emulation does not exist in my installation. It seems this stuff has been moved to /opt/ti/ccsv6/ccs_base/emulation/drivers which is accessed two lines further. Perhaps the code is checking first for older versions of the drivers. (And I do not find the file NONE under  /opt/ti/ccsv6/.)

    BTW I have already reinstalled once using a fresh download from TI.

    thanks,

    hank

  • in reply to Hank Barta
    Guru 92251 points

    Hank Barta said:
    That line does look a bit odd. 
    [pid 33754] access("/opt/ti/ccsv6/emulation/drivers/NONE", F_OK) = -1 ENOENT (No such file or directory)

    I had the same in a strace log for when was able to connect to a XDS200 under Ubuntu 16.04, so that isn't the cause of the problem.

  • Guru 92251 points

    Hank Barta said:
    This seems to be the generic 'can't communicate' with the USB debugger message. Following is what I find in dmesg output when 
    [1444128.176067] usb 4-1.2: new high-speed USB device number 12 using ehci-pci
[1444128.268904] usb 4-1.2: New USB device found, idVendor=0451, idProduct=bef0
[1444128.268909] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1444128.268913] usb 4-1.2: Product: XDS2xx USB Emulator - Composit
[1444128.268916] usb 4-1.2: Manufacturer: Spectrum Digital
[1444128.268918] usb 4-1.2: SerialNumber: S200-000E99039000
[1444128.269425] cdc_acm 4-1.2:1.0: ttyACM1: USB ACM device
[1444128.269903] cdc_acm 4-1.2:1.2: ttyACM2: USB ACM device

    Perms on the TTY devices look OK (and I am a member of the dialout group.)

    hbarta@itws007:/opt/ti/ccsv6/install_scripts$ ls -l /dev/ttyACM?
crw-rw-rw- 1 root dialout 166, 0 Oct 27 15:17 /dev/ttyACM0
crw-rw-rw- 1 root dialout 166, 1 Oct 27 15:17 /dev/ttyACM1
crw-rw-rw- 1 root dialout 166, 2 Oct 27 15:17 /dev/ttyACM2

    That output shows that the XDS200 has enumerated as the USB ACM devices ttyACM1 and ttyACM2, and that there is already an existing USB ACM device ttyACM0.

    When I looked through the strace.txt log from your loadsti.sh failure I can see the sequence of:

    1) Device ttyACM0 is opened:

    [pid 33754] open("//dev//ttyACM0", O_RDWR) = 129

    2) Some ioctl() calls are made on file descriptor for the ttyACM0 device, followed by a write of 18 bytes:

    [pid 33754] write(129, "\1f\231\0\0\22\0\0\0\r\0\177\360\0\0\0\0004", 18) = 18

    3) An attempt is made to read 8 bytes from the ttyACM0 device, but after multiply attempts no bytes are read and the file descriptor for the ttyACM0 device is closed:

    [pid 33754] read(129,  <unfinished ...>
[pid 33754] <... read resumed> "", 8)   = 0
<snip>
[pid 33754] read(129,  <unfinished ...>
[pid 33754] <... read resumed> "", 8)   = 0
[pid 33754] ioctl(129, FIONREAD, [0])   = 0
[pid 33754] ioctl(129, TCFLSH, 0x2)     = 0
[pid 33754] ioctl(129, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 -opost -isig -icanon -
echo ...}) = 0
[pid 33754] ioctl(129, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B115200 -opost -isig -icanon -echo ...}
) = 0
[pid 33754] ioctl(129, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B115200 -opost -isig -icanon -
echo ...}) = 0
[pid 33754] close(129)                  = 0

    Followed by the E_RPCENV_IO_ERROR error being reported:

    [pid 33754] munmap(0x7fdf0d3b6000, 2157672) = 0
[pid 33754] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3559, ...}) = 0
[pid 33754] write(128, "    E 10/09/16 08:36:32:870 | rp"..., 104) = 104
[pid 33754] fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 23), ...}) = 0
[pid 33754] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdf21cc9000
[pid 33754] write(1, "E_RPCENV_IO_ERROR(-6) No connect"..., 57) = 57
[pid 33754] write(1, "Failed to open i/o connection (x"..., 42) = 42

    Therefore, the problem appears to be that why theXDS200 has been enumerated as ttyACM1 and ttyACM2, the XDS200 driver attempts to communicate using the wrong ttyACM0 device and thus fails to establish communication with the XDS200.

    As a work-around can you determine what the ttyACM0 device is and try and remove it, to see if you can then make the XDS200 enumerate as ttyACM0 and ttyACM1 and then establish communication with the XDS200?

    On a Ubuntu system in which the XDS200 enumerated as ttyACM0 and ttyACM1, with no other USB ACM devices, a strace of a successful loadti.sh showed communication with ttyACM0.

  • in reply to Chester Gillon
    Intellectual 970 points

    Yes, that was it. It never occurred to me that /dev/ttyACM0 was not the XDS200 debugger.

    As a work-around can you determine what the ttyACM0 device is and try and remove it, to see if you can then make the XDS200 enumerate as ttyACM0 and ttyACM1 and then establish communication with the XDS200?

    Yes, with the other device removed, the system works as expected. I was able to test the connection and download and run code.

    How do we configure CCS to use a different TTY? This is also likely to come up when other developers need to debug on Linux as our system is shared between several of us. I expect the next XDS200 will land at /dev/ttyACM3 and /dev/ttyACM4.

    thanks,

    hank

  • in reply to Hank Barta
    Guru 92251 points

    Hank Barta said:
    Yes, with the other device removed, the system works as expected. I was able to test the connection and download and run code.

    I can repeat the failure of failure to connect to a XDS200 when enumerates as something other than /dev/ttyACM0.

    As an example:

    1) Connect a XDS200 Onboard Debug Probe, which enumerates as ttyACM0 and ttyACM01.

    Then connect a XDS100 which enumerates as ttyACM2 and ttyACM3.

    A test connection of the XDS110 and XDS200 can connect to the respective emulators.

    2) Swap the order of connecting the debug probes. i.e. connect the XDS110 first which enumerates as ttyACM0 and ttyACM1. Connect the XDS200 second which enumerates as ttyACM2 and ttyACM3.

    The test connection of the XDS110 is successful.

    However, the test connection of the XDS200 fails. It pauses after reporting:

    This utility will load the program 'xds2xxu.out'.

    And after a timeout reports:

    E_RPCENV_IO_ERROR(-6) No connection: DTC_IO_Open::dtc_io
Failed to open i/o connection (xds2xxu:0)

    In this state when the XDS200 has enumerated as ttyACM2 and ttyACM3, running strace on a failed attempt to connect to the XDS200 using loadti.sh also shows that an incorrect attempt to communicate using ttyACM0 rather than ttyACM2.

    When repeated the problem was using:

    - CCS 6.1.3.00033

    - CentOS 6.8 64-bit

    - TI Emulators 6.0.407.3

    Hank Barta said:
    How do we configure CCS to use a different TTY? This is also likely to come up when other developers need to debug on Linux as our system is shared between several of us.

    On the "Connection Properties" in the target configuration file for a XDS200 there is a "Debug Probe I/O Port Number". When a new target configuration is created the "Debug Probe I/O Port Number" defaults to zero.

    Once the XDS200 had enumerated as ttyACM2 and ttyACM3, the "Debug Probe I/O Port Number" was set to 2 in the target configuration and then the test connection could communicate with the XDS200.

    i.e. the "Debug Probe I/O Port Number" can be used to specify which XDS200 to use. However, because the USB ACM port numbers change according to the order the USB ACM devices are connected you will need to always connect multiple XDS200 probes in the same order to get repeatable results.

    The target configuration files for other debug probes, such as the XDS110, allow the debug probe instance to be specified using the USB serial number which is better since the USB serial number will always be the same for a given debug probe. It would be better if CCS allowed a consistent approach to identify multiple instances of the same debug probe.