• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 55 subscribers
  • Views 3018 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 won't connect to EK-TM4C1294XL Launchpad

Brad Rodriguez
Intellectual 630 points
Other Parts Discussed in Thread: EK-TM4C1294XL, UNIFLASH

I have posted this question in the TM4C forum, and it was suggested that I also post here, as it may be a problem with the latest version of CCS.

I have been using the EK-TM4C1294XL Launchpad for several weeks with no problem. I am using Code Composer Studio 6.1.0.00104 for Linux, on a 32-bit Debian Linux system.

Today I went to reload my test code into the Launchpad, and I got the dreaded "CORTEX_M4_0: Error connecting to the target: Frequency is out of range" message.

The Launchpad *is* running. The previous test program outputs debug text through UART0, and I can see that text through the virtual com port on the debug interface. I attempted to load the "blinky" demo through CCS and that failed the same way. In desperation I rebooted my computer; that did not resolve the problem.

I have followed the procedure described in the "JTAG Communication Failures" post to unlock the debug port (using Uniflash instead of LMFlash, since I'm on a Linux system). That seemed to work ok, but when I relaunched CCS I still had the problem.  I can successfully use Uniflash to load both the "blinky" demo and my own application program; it's only CCS that fails.

The *only* thing I can think of that has changed since last week, is that when I launched CCS today, I was informed that there were program updates available, and I accepted them. I'm worried that the latest updates to CCS have broken the debugger. For the time being I can use Uniflash for testing, but should I remove CCS and reinstall the original version? 

  • 0
    TI__Guru**** 421380 points

    Hi Brad,

    Brad Rodriguez said:
     I can successfully use Uniflash to load both the "blinky" demo and my own application program; it's only CCS that fails.

    This is interesting because UniFlash and CCS use the same debug engine underneath

    Brad Rodriguez said:
    I was informed that there were program updates available, and I accepted them. I'm worried that the latest updates to CCS have broken the debugger.

    There was a new TI Emulator pack update released recently. This could be the issue. What TI Emulator pack are you using? You can check by going to 'Help -> About Code Composer Studio' and press the 'Installation Details' to open the Installation Details. In the first tab (Installed Software), look for 'TI Emulators' in the list. The version number will be next to it.

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 630 points
    Hi Ki, thanks for your reply. CCS is showing "TI Emulators" version 6.0.14.0.

    I see that Uniflash also has "Installation Details." It is reporting "TI Emulators" version 5.1.641.0.
  • 0 in reply to Brad Rodriguez
    Intellectual 630 points
    Oho! I've just discovered the "Installation History" display in CCS. Clicking on "7/20/15", the date of the *previous* (working) software update, shows TI Emulators version 5.1.641.0. Clicking on "Current Installation" or "7/29/15" shows TI Emulators version 6.0.14.0. So as of last week, I was using the older TI Emulators.
  • 0 in reply to Brad Rodriguez
    TI__Guru**** 421380 points
    Brad - I updated the TI emulator pack from 5.1.641.0 to 6.0.14.0 on of my Linux machines and I am still able to connect to my EK-TM4C1294XL LaunchPad. So it is possible that it is not the emu pack that is the root cause. Just to confirm, are you using the Stellaris ICDI USB connection as the debug probe?
  • 0 in reply to Ki
    Intellectual 630 points
    Yes, that is correct, I am using the Stellaris ICDI USB connection.
  • 0 in reply to Brad Rodriguez
    TI__Guru**** 421380 points
    Brad,
    Can you try some of the troubleshooting tips in the below URL:
    processors.wiki.ti.com/.../Troubleshooting_CCSv6

    Specifically try:
    -starting CCS with -clean
    -cleaning your workspace
    -deleting debug launch files
    -deleting target cache files

    Thanks
    ki
  • 0 in reply to Ki
    Intellectual 630 points
    Ki, thank you for the suggestions, and for the URL to the troubleshooting wiki. No luck, I'm afraid. I launched CCS with -clean, and (per the Wiki) created a new workspace with only one imported project (blinky). I also deleted the debug launch configuration and the target cache files. I'm still getting "Frequency is out of range."
  • 0 in reply to Ki
    Intellectual 630 points

    I have more information, thanks to a suggestion in the TM4C forum.  Running "loadti.sh" from the command line produces some debugging out (posted here).  It looks like CCS is unable to find libusb-1.0.so.  There are repeated messages of the form

    Failed to load dynamic library: 'libusb-1.0.so' (libudev.so.1: cannot open shared object file: No such file or directory)
OSALDebugEnum: Error dynamically loading libusb (rc = -1)
Failed to load dynamic library: 'libusb-1.0.so' (libudev.so.1: cannot open shared object file: No such file or directory)
ASSERT FAILED (find_lmicdi:122): (rc == TRUE) == 0
WARNING: pfn 'libusb_get_device_list' is NULL.  Skipping call.
WARNING: pfn 'libusb_free_device_list' is NULL.  Skipping call.

    This is peculiar because (a) that driver is installed on my system, (b) CCS was able to find it last week, and I haven't changed any Linux drivers since then, and (c) Uniflash can still find it.

  • 0 in reply to Brad Rodriguez
    TI__Guru**** 421380 points

    Brad Rodriguez said:
    This is peculiar because (a) that driver is installed on my system, (b) CCS was able to find it last week, and I haven't changed any Linux drivers since then, and (c) Uniflash can still find it.

    That is really odd because, as you said, it was all working fine before and UniFlash can still find it.

    Just for grins, can you try the below:

    -sudo apt-get install libusb-0.1-4:i386

    -sudo ln -s /lib/i386-linux-gnu/libusb-1.0.so.0.1.0 /usr/lib/libusb-1.0.so

    Thanks

    ki

  • 0 in reply to Ki
    Intellectual 630 points

    I already had libusb-0.1-4 installed, but I tried the link you suggested.  That didn't seem to fix things.

    Over in the TM4C forum it was suggested that I need to load libudev.so.1.  That has changed the error message to this:

    Failed to load dynamic library: 'libusb-1.0.so' (/lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /home/brad/ti/ccsv6/ccs_base/DebugServer/drivers/../../common/bin/libusb-1.0.so))
OSALDebugEnum: Error dynamically loading libusb (rc = -1)
Failed to load dynamic library: 'libusb-1.0.so' (/lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /home/brad/ti/ccsv6/ccs_base/DebugServer/drivers/../../common/bin/libusb-1.0.so))
ASSERT FAILED (find_lmicdi:122): (rc == TRUE) == 0
WARNING: pfn 'libusb_get_device_list' is NULL.  Skipping call.
WARNING: pfn 'libusb_free_device_list' is NULL.  Skipping call.
waitUntil: ENTRY timeout: infinite

    I have libc.so.6 installed, but I don't know what "version 'GLIBC_2.17" means in regards to libc.so.6.  I'll have to do some research.

  • 0 in reply to Ki
    Intellectual 630 points
    After some reading, I'm guessing that this refers to the libc6 version number, i.e., libc6_2.17. What I have (Debian Wheezy) is libc6_2.13. 2.17 doesn't seem to be available for Wheezy. The latest release, Debian Jessie, has libc6_2.19, which I assume will satisfy CCS.

    I do need to upgrade to Jessie, but am not quite ready for that. I'm starting to think the best solution is to reinstall an older version of CCS.
  • 0 in reply to Brad Rodriguez
    Guru 92251 points

    Brad Rodriguez said:
    There are repeated messages of the form 
    Failed to load dynamic library: 'libusb-1.0.so' (libudev.so.1: cannot open shared object file: No such file or directory)
OSALDebugEnum: Error dynamically loading libusb (rc = -1)
Failed to load dynamic library: 'libusb-1.0.so' (libudev.so.1: cannot open shared object file: No such file or directory)

    I found that a CCS 6.1.0.00104 installation on CentOS 6.6 64-bit was suffering the same errors when trying to use a Stellaris-ICDI following updates. It been a while since last used that CCS 6.1 installation with a Stellaris-ICDI so not sure which update caused the problem - but TI Emulators 6.0.14.0 is currently installed.

    On a quick investigation:

    a) The CCS 6.1 installation includes a ccsv6/ccs_base/common/bin/libusb-1.0.so, which ldd reports the following errors for:

    $ ldd /opt/ti/ti_ccs6_1/ccsv6/ccs_base/common/bin/libusb-1.0.so
    /opt/ti/ti_ccs6_1/ccsv6/ccs_base/common/bin/libusb-1.0.so: /lib/libc.so.6: version `GLIBC_2.17' not found (required by /opt/ti/ti_ccs6_1/ccsv6/ccs_base/common/bin/libusb-1.0.so)
    linux-gate.so.1 => (0x00d01000)
    libudev.so.1 => not found
    libpthread.so.0 => /lib/libpthread.so.0 (0x007ec000)
    libc.so.6 => /lib/libc.so.6 (0x008ab000)
     /lib/ld-linux.so.2 (0x4e8c2000)

    i.e. the libusb-1.0.so in the CCS 6.1 installation refers to GLIBC_2.17 and udev.so.1 which are not installed as part of CentOS 6.6. yum showed that libudev.so.1 is not available in a base CentOS 6.6 package.

    b) A CCS 6.0 installation which could still access the Stellaris ICDI doesn't contain a libusb-1.0.so in the CCS 6.0 installation, and is therefore using the CentOS 6.6 provided /usr/lib/libusb-1.0.so

    c) The CCS 6.1 ccsv6/ccs_base/common/bin/libusb-1.0.so was renamed to ccsv6/ccs_base/common/bin/libusb-1.0.so.orig, to force CCS 6.1 to use the CentOS 6.6 provided /usr/lib/libusb-1.0.so. This allowed CCS 6.1 to access the Stellaris ICDI again, in that could debug a EK-TM4C129XL.

    Therefore, it appears that CCS 6.1 now installs a ccsv6/ccs_base/common/bin/libusb-1.0.so: /lib/libc.so.6, but which is incompatible with the base packages on some Linux installations.

  • 0 in reply to Brad Rodriguez
    TI__Intellectual 2010 points
    Brad,

    I believe the problem you are having is due to the version of libusb that is shipped with the most recent TI Emulators update. The new version of libusb requires a libc runtime higher than what you is installed on your system. We are currently working on updating the TI Emulators release to minimize the version of GLIBC that is required by libusb. If you are still blocked, I would suggest building libusb and replacing the libusb files in ccs_base/common/bin. Alternatively, I can send an updated version of libusb for you to try.

    Thanks,
    Mark
  • 0 in reply to Chester Gillon
    Intellectual 630 points

    Chester, thanks!  You have pinpointed the problem.  I had not realized that CCS installed its own copy of libusb.  I got a result similar to yours (except that I have libudev.so.1 installed):

    $ ldd ~/ti/ccsv6/ccs_base/common/bin/libusb-1.0.so
/home/brad/ti/ccsv6/ccs_base/common/bin/libusb-1.0.so: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by /home/brad/ti/ccsv6/ccs_base/common/bin/libusb-1.0.so)
	linux-gate.so.1 =>  (0xb7746000)
	libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb76ff000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76e6000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7596000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7592000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb7589000)
	/lib/ld-linux.so.2 (0xb7747000)

    I decided to see if I could get CCS to use the system libusb rather than its own (per your option "c").  So, in the ~/ti/ccsv6/ccs_base/common/bin/ directory, I renamed the three libusb-1.0.so* files to libusb-1.0.so*TI.  (It may have been sufficient to rename just libusb-1.0.so, but I decided to be sure.)  And that fixed it!  Both the command line "loadti.sh" and CCS are now able to communicate with the target, and install software.

    Thank you very much for your detective work!  (Sorry to take so long replying, but we've just had a long holiday weekend here.)

  • 0 in reply to Mark Garrett
    Intellectual 630 points
    Mark, thanks for your reply. I can confirm what Chester Gillon has reported -- the TI-supplied libusb is not compatible with my Linux system (Debian 7 "Wheezy"), but if the TI-supplied libusb files are removed, CCS apparently will use the system-provided libusb.