• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Subscribers 32 subscribers
  • Views 3719 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.

EK-TM4C1294XL "Frequency is out of range"

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

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 have used Uniflash to load the blinky demo, and that works fine!

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?

Is there something else I should try, either with the Launchpad or with CCS?

  • 0
    TI__Guru**** 244380 points
    Hello Brad,

    Can you check which drivers are being used for the LaunchPad in the Device manager. At the same time make sure that you post the same on the CCS Forum to let CCS Team know that there is a potential issue in the latest update,

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 630 points
    I have both libusb-0.1 and libusb-1.0 installed, if that's what you're asking; and I haven't updated them recently. I don't know what other drivers CCS installs on a Linux system.

    I will copy my post to the CCS forum; thanks for the suggestion.
  • 0 in reply to Brad Rodriguez
    TI__Guru**** 244380 points
    Hello Brad,

    I know there was a forum post in the past (could be on CCS Forum) where it was mentioned that the next drivers were causing a problem for TM4C. another approach would be to see in the Device Manager the Date of the driver. If you can post that to us it would be useful.

    Regards
    Amit
  • 0
    Guru 47900 points

    Brad Rodriguez said:
    ...went to reload my test code...got the dreaded "CORTEX_M4_0: Error ...: Frequency is out of range!

    Delightful that - don't we all just love such detailed, caring & helpful messages...    Apparently - someone - somewhere believed that the incoming JTAG/SWD clock must remain w/in bounds - but chose not to tell us if our input was too fast or too slow!  Or by how much we "missed" the acceptable input.

    Might an acceptable input frequency spec be provided - so that we could at least (maybe) - confirm the correctness of such "robot diagnosis?" 

    Dawns now - would it not be wise to (now) "capture" the JTAG data & clock activity - "before" those dreaded error messages arrive w/vengeance?   At least then there's some chance to "A-B" compare/contrast ("once" working against "disturbed" non-working.)

    Must say that the "Frequency out of range" message seems highest here - w/this vendor's MCUs & JTAG attachment devices.   Our firm uses IAR w/J-Links - have never seen that error!   (Thank God)  

    The incidence of "lock-outs" in general appears high here - hard to imagine that they (always) result from JTAG re-purposing and/or system clock miscues.

  • 0 in reply to Amit Ashara
    Intellectual 630 points
    Hello Amit, unfortunately on my Linux system there is no Device Manager in the Windows sense. If CCS required any specific drivers on installation, they must be part of the "Installed Software" that's visible under "Installation Details" in CCS's About window. Those drivers are listed by version number and don't display a date. It's not obvious which of these is relevant here; possibly "Debug Server" or perhaps "RTSC/XDCtools". The "Tiva/Stellaris ICDI Debug Probe" is version 2.1.1.14351. The list of plug-ins is even longer.
  • 0 in reply to cb1
    Intellectual 630 points
    cb1, thanks for the sympathy. :) I might have been tempted to assume that I had done something wrong with the clock configuration, if it weren't for the fact that I've loaded and run the unmodified "blinky" demo, and CCS still reports "frequency out of range." (And we're not repurposing any of the JTAG pins.)

    I'm tempted to buy a factory-fresh Launchpad and see if it has the same problem. Or perhaps I should invest in a proper debug adapter...I'm going to need one sooner or later.
  • 0 in reply to Brad Rodriguez
    Guru 47900 points

    To be fair there is a "known spec" which limits the JTAG speed to some division of the System Clock frequency. That said - should not any "reasonable JTAG/SWD pod" know that - and clamp the top frequency so as to never encroach/exceed?   (specifically the ones sold here encounter a "known system clock range" - thus it should not be that hard to "govern" F(Jtag)Max so as not to exceed (local) speed limits!)
     
    The message "out of range" is better than nothing - yet approaches "nothing" in terms of its care & value to "trapped" user-clients...

  • 0 in reply to Brad Rodriguez
    TI__Guru**** 244380 points
    Hello Brad

    In my opinion, the right course of action would be to post it to CCS Forum "mentioning that it is Linux"

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 630 points

    Thanks, Amit, I have done so.  I have already obtained some help from that forum.  It turns out that this week, a new version of the TI Emulators component was pushed to my CCS, and that may be the source of the problem.  (Uniflash uses the old version of TI Emulators, which is why it still works.)

    I am hoping that (a) I can roll back CCS to that earlier version, or (b) TI quickly releases a fix for this.  (I have already heard from another user having the identical problem.)  Failing that, I will (c) reinstall CCS from the original download, and decline all software updates henceforth.

    "Decline all software updates" would be a good idea for other TM4C users, until this gets resolved.  Unfortunately, I don't think most users will discover this until they come here searching for the "frequency out of range" error message, and then it will be too late for them.  I think it's still a good idea to keep this topic active, since those who encounter that message are probably going to look here first rather than the CCS forum.

  • 0 in reply to Brad Rodriguez
    TI__Guru**** 244380 points
    Hello Brad

    The normal course of action is that I do not update if it is working though review what the changes are for.

    Regards
    Amit
  • 0 in reply to Brad Rodriguez
    Guru 47900 points
    Brad - believe that you are, "quite terrific." Great, caring writing - you've helped many - thank you. (note we would never use CCS or any single vendor locked - yet that does not diminish my respect for your writing!)

    Beyond "frequency out of range" it would appear that, "update's testing/verification is (extremely) out of range!" Pity...
  • 0 in reply to cb1
    Intellectual 630 points

    cb1, you are too kind.  The latest news from the CCS forum is that it does *not* appear to be the TI Emulators component -- someone else is running the latest version of that, under Linux, with no problems.  So I can't fault their update testing just yet.

  • 0
    Guru 92251 points

    Brad Rodriguez said:
    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.

    That error isn't very descriptive as I have seen it reported when either:

    a) The Launchpad isn't plugged in.

    b) One of the shared library files required by the debugger under Linux isn't installed.

    In the the case of b) trying to load the program from a shell using <ccs_install_root>/ccsv6/ccs_base/scripting/examples/loadti/loadti.sh can show a more descriptive error than "CORTEX_M4_0: Error connecting to the target: Frequency is out of range". Suggest you try loadti.sh and see what the error is.

  • 0 in reply to Chester Gillon
    Intellectual 630 points

    Thank you for that suggestion!  It was substantially more informative, though I'm not really sure what I've learned.  I added the -v option for more verbose output, and below is what I got when I tried to load "blinky".  Beats me why it's having problems loading libusb-1.0.so; it is present in my system (and that hasn't changed since last week).

    brad@brads-phenom:~/workspace_v6_1/blinky/Debug$ ~/ti/ccsv6/ccs_base/scripting/examples/loadti/loadti.sh -v -c ../target_config.ccxml blinky.out

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

START: 18:11:18 GMT-0400 (EDT)

Configuring Debug Server for specified target...
getServer: ENTRY sServerName: DebugServer.1
getServer: Getting definition for: DebugServer.1
getServer: Constructing server
getServer: RETURN com.ti.debug.engine.scripting.DebugServer@1a5ddbb
setConfig: ENTRY sConfigurationFile: ../target_config.ccxml
setConfig: RETURN
Done
debuggerOpen: ENTRY sBoardName: * sCPUName: *
start: ENTRY
start: Firing: onServerStarting()
start: Connecting to XPCOM DebugServer
start: Initializing DebugServer using specified configuration: "/home/brad/workspace_v6_1/blinky/target_config.ccxml"
waitUntil: ENTRY com.ti.ccstudio.scripting.environment.ScriptingEnvironment@14b02f timeout: infinite
<init>: CPU Name: CORTEX_M4_0
<init>: PartNum: TM4C1294NCPDT
<init>: Family: 470
<init>: SubFamily/MajorISA: e
<init>: Revision/MinorISA: 0
<init>: Platform: EMULATOR
<init>: Processor ID: 1971337216
<init>: DBName: ArmAdvancedFeatures
waitUntil: RETURN com.ti.ccstudio.scripting.environment.ScriptingEnvironment@14b02f
start: Firing: onServerStarted()
start: Searching for devices
listDevices: ENTRY
listDevices: Found debuggable device: Stellaris In-Circuit Debug Interface_0/CORTEX_M4_0
listDevices: RETURN
start: RETURN
debuggerOpen: RETURN Stellaris In-Circuit Debug Interface_0/CORTEX_M4_0
setString: ENTRY ID: FileIODefaultDirectory Value: undefined
setString: RETURN
TARGET: Stellaris In-Circuit Debug Interface_0
Connecting to target...
connect: ENTRY
isConnected: ENTRY
isConnected: Target is not connected
isConnected: RETURN false
connect: Requesting target connect
waitUntil: ENTRY timeout: infinite
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.
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.
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.
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.
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.
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.
SEVERE: CORTEX_M4_0: Error connecting to the target: Frequency is out of range.

log: Error when connecting to target
waitUntil: RETURN
isConnected: ENTRY
isConnected: Target is not connected
isConnected: RETURN false
SEVERE: emulation failure occurred
SEVERE: Error connecting to the target: emulation failure occurred
Error code #4001, could not connect to target!
Aborting!
terminate: ENTRY
terminate: Firing: onSessionTerminating()
terminate: Unregistering this session from the DebugServer
terminate: Firing: onSessionTerminated()
disposeAndUnload: Firing: onServerStopping()
disposeAndUnload: Stopping DebugServer
terminate: ENTRY
terminate: RETURN
waitUntil: ENTRY com.ti.ccstudio.scripting.environment.ScriptingEnvironment@14b02f timeout: infinite
waitUntil: RETURN com.ti.ccstudio.scripting.environment.ScriptingEnvironment@14b02f
disposeAndUnload: Firing: onServerStopped()
terminate: RETURN
stop: ENTRY
stop: RETURN

END: 18:11:20 GMT-0400 (EDT)

  • 0 in reply to Brad Rodriguez
    Guru 92251 points

    Brad Rodriguez said:
     Beats me why it's having problems loading libusb-1.0.so; it is present in my system (and that hasn't changed since last week).

    Brad Rodriguez said:
    Failed to load dynamic library: 'libusb-1.0.so' (libudev.so.1: cannot open shared object file: No such file or directory)

    I think that message means that libudev.so.1 can't be found (as opposed to not being able to find llbusb-1.0.so).

    Is libudev.so.1 present on your system?

    Does running either of the following report any missing dependencies?

    ldd /usr/lib/libusb-1.0.so
    ldd /usr/lib/libudev.so.1

  • 0 in reply to Chester Gillon
    Intellectual 630 points
    Ah, thanks, I had interpreted that message differently. No, libudev.so.1 was not present on my system (only libudev.so.0). I have now installed it. Alas, loadti.sh is still reporting the same errors.

    libusb-1.0.so and libudev.so.1 are both reporting no missing dependencies.
  • 0 in reply to Chester Gillon
    Intellectual 630 points

    My mistake, it is *not* reporting the same underlying error.  Now what I am seeing is this, six times:

    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

    So it looks like loading libudev.so.1 made a difference.

  • 0 in reply to Brad Rodriguez
    Intellectual 630 points

    Problem solved!  Thanks to Chester Gillon who posted the solution over in the CCS forum.  To make a long story short, the latest update to CCS installed a TI-compiled version of libusb-1.0 (the Linux USB library), which is not compatible with my system.  The fix is to remove TI's libusb files (found, in my case, in ~~/ti/ccsv6/ccs_base/common/bin/libusb-1.0* ).  Once those files are removed, CCS will use the system-provided libusb-1.0.

  • 0 in reply to Brad Rodriguez
    Guru 54588 points
    Hi Brad,

    So the frequency out of range message is no longer an issue and your original question is answered?

    If so seems to me CG came the closest to the issue and should get the question answered so people like me don't get caught in the web.
  • 0 in reply to Genatco
    Intellectual 630 points
    BP101, yes, the frequency out of range message is gone, and my original question is answered. I marked Chester's post in the CCS forum as "answered." I wasn't sure what post to mark here as the answer, but I see that someone has marked my post here that links to the CCS forum post.