• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 1298 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.

CCS/CCSTUDIO: "Ignoring serial port reserved for JTAG" when using Blackhawk USB100v2

cmannett85
Prodigy 130 points
Part Number: CCSTUDIO

Tool/software: Code Composer Studio

Upon connecting a Blackhawk USB100v2 (an XDS100v2 compliant device) to my 64bit Linux machine, I get this output in dmesg:

[ 1179.587536] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[ 1179.762059] usb 1-2: New USB device found, idVendor=0403, idProduct=a6d0
[ 1179.762063] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1179.762066] usb 1-2: Product: Texas Instruments Inc.XDS100 Ver 2.0
[ 1179.762068] usb 1-2: Manufacturer: TI
[ 1179.762070] usb 1-2: SerialNumber: USB100V2
[ 1179.766634] usb 1-2: Ignoring serial port reserved for JTAG
[ 1179.770505] ftdi_sio 1-2:1.1: FTDI USB Serial Device converter detected
[ 1179.770603] usb 1-2: Detected FT2232H
[ 1179.771219] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1179.788275] usb 1-2: Ignoring serial port reserved for JTAG
[ 1179.795431] usb 1-2: Ignoring serial port reserved for JTAG
[ 1179.796409] usb 1-2: Ignoring serial port reserved for JTAG
[ 1179.800150] usb 1-2: Ignoring serial port reserved for JTAG
[ 1179.806793] usb 1-2: Ignoring serial port reserved for JTAG

And ttyUSB0 duly appears in /dev/.  However according to this forum post, I should have two serial devices - which I assume is what the 'Ignoring serial port reserved for JTAG' output is referring to.

I have ran install_drivers.sh in the install_scripts directory under root (twice), and the rules files were put into /etc/udev/rules.d.  It should be noted that there is an error in the installation scripts resulting in service udev restart being called on systemd systems.

I'm asking this because I'm trying to connect via JTAG to an AM3358-based board to debug a PRU module, but it gets stuck in the 'Connecting' phase, despite passing the 'Test Connection' tests.  I'm not entirely sure that this post is the cause of the problem, but it's the first step to diagnosis.

  • 0
    TI__Guru**** 168377 points

    Hi,

    Regarding the USB port enumeration and the absence of two ttyUSBn devices, I can tell that I see the same thing in my setup when using specifically the Blackhawk XDS100v2 probe, which works correctly: i.e., the xds100serial utility acknowledges the JTAG debugger and I am able to connect to the device. 

    Different debug probes (such as the one mentioned in the thread you linked, which is built into a F28x development kit) can enumerate differently. 

    From your description you are able to connect to the Cortex A8 core of your board but not the PRU, is that correct? If so, there is an issue with CCS releases 6.2.0 and 7.0 that, under certain circumstances not yet fully characterized, lock or crash CCS when connecting to PRU cores in Ubuntu 16.04 (reported in a few other threads such as this one).

    Some people were able to workaround this issue by creating a new workspace, while in my case I could connect normally with CCSv7.1. 

    If you don't have this release, you can try to update the TI Emulators component of your existing CCS to the latest version - go to menu Help → Check for Updates and locate the TI Emulators component:

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 130 points

    I can connect to the A8 without a problem, but the PRU just stays stuck at 'Connecting : Running' - however CCS does not crash.  I did suffer the issue previously and I narrowed it down to an out of date initialisation script, once I used the latest from the TI repo the problem went away.

    I'm running the latest version of the TI emulators.

    I ran CCS with TI_DS_ENABLE_LOGGING enabled, and attached the compressed logfile.  All I did was run CCS, attempt a connection to PRU0, wait about 3 seconds before cancelling and exiting.  It generated a 6.6MB log...  According to the log PRU0 went into a running state, but nothing seems to happen from that - it stays in the polling loop.

    output.txt.7z

  • 0 in reply to cmannett85
    Prodigy 130 points
    This is a different issue to the question title, so I'll create a new one.