• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 32 subscribers
  • Views 1673 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LM4F232 EKS not getting to main() using SpectrumDig XDS560v2 STM and CCS 5.4

John Osen
Genius 3585 points
Other Parts Discussed in Thread: TM4C129DNCPDT, UNIFLASH, LMFLASHPROGRAMMER

I have just switched to CCS 5.4 and updated to the latest SD drivers and ARM compilers.  I have been regression testing the dev chain to see if I lost anything in the upgrade.  I am using the EKS to simulate my target HW that is in development itself.

This morning I was able to emulate on the EKS.  At some time the emulation stopped breaking at main().  I reverted to the project state as of the time it was working, recycled power to emulator and target, restarted CCS.  I am bouncing from "cannot connect to emulator" to the program beginning to run without breaking at main() and since there is no CAN output, I suspect it is starting somewhere else other than main().

This configuration has been stable for months using CCS5.3.  I move the emulator to another device and it emulates just fine.  Move back to the EKS and power cycle emulator, restart debug several times before getting to the "running but not from main()" issue.

When I pause and restart app I get:

Can't find a source file at "/tmp/TI_MKLIBiLt7no/SRC/boot.asm"
Locate the file or edit the source lookup path to include its location.

or

When I reset the processor via CCS's reset button I get:

CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI.
Reset the device, and retry the operation.
If error persists, confirm configuration, power-cycle the board,
and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.73.0)

I have tried 'TCLK looped-back with user...' set to 6MHz and 3MHz.  Neither of these settings worked.

It worked several times this morning as expected.

Any ideas.

  • 0
    Guru 117855 points

    John Osen said:
    'TCLK looped-back with user...' set to 6MHz and 3MHz.  Neither of these settings worked.

    Feel your pain - such "connection" error/lock-outs always frustrating/maddening.

    Now we use paid IAR - and it launches JTAG/SWD @ 32KHz - then increases F.  And IAR simply works - and works.

    Doubt that you will "operationally" note such reduction in JTAG connection speed - simple/easy test would see you substantially lower JTAG speed - and repeat test.  Should this "cure" - you can incrementally dial-up such speed - determine highest, robust setting.

    As always - we heartily recommend physical (external) pull-ups on each/every JTAG line.  (although our IAR has long supported SWD - saving 2 GPIO - and is both newer and faster than JTAG...)

    Note: I've seized upon your report of, "try more reliable JTAG settings."  Unsure if this causes/contributes to failure to, "Run to Main."  This "Run to Main" sounds to me more like a "misfire" w/in latest/greatest version of your IDE - and may reveal via careful comparison between past and present version.  (W/in IAR we have a "tick-box" which enables, "Run to Main."  Default "ticks" this box - perhaps your IDE has similar - and tick has escaped?)

    Hope this works...  Good luck...

  • 0 in reply to cb1_mobile
    Genius 3585 points

    Tried to lower the clock rate to 500Hz.  No luck.

    I actually have two applications that run on this target.  The first is the monitor/bootloader; which I can no longer emulate; it is loaded into the first 20KB of memory.  The second is the target application; which is loaded into the next 106KB of memory.  The application runs and emulates just fine.

    Seeing that I have an app running on the specific target HW and being emulated at 6MHz, I gave up on the JTAG clock rate.

    I have spent probably months emulating off of this chip.  Is it possible that on A3 silicon I wore out the lower 20KB of FLASH?

  • 0 in reply to John Osen
    Genius 3585 points

    I just loaded the monitor into another legacy piece of HW and it loaded and stopped at main().  That HW had A3 silicon.  I double checked the EKS, it has A1 silicon.

    Hmm....  The only thing I haven't been able to swap out is the monitor in the lower 20KB of FLASH on the EKS. 

  • 0 in reply to John Osen
    Guru 117855 points

    Flash life issues - clearly vendor-reserved area.  From your description: "works fine using past CCS - now fails using newer" - does not IDE rise to top of suspect list?

    In over 10 years of successful- ARM MCU design/development - only time we've ever noted failure to, "Run to Main" was when IDE was not so configured.

  • 0 in reply to John Osen
    Genius 3585 points

    So now I have found a neglected EKS board, swapped that in and emulation works as expected, breaking at main().

    It would appear that the original EKS system does not emulate out of the lower 20KB.

    Has anybody actually fried an LM4F's (sorry Tiva's) FLASH due to fatiguing the FLASH through emulation?

  • 0
    Guru 117855 points

    John Osen said:
    This configuration has been stable for months using CCS5.3. 

    While requiring more effort - a return to this set-up - and observation then of today's identical failure/limitation - would be far less anecdotal - thus more convincing...

    Any failure - happening upon (or in near coincidence) with some major change - always casts doubt upon that major change.  (or should...)

  • 0 in reply to cb1_mobile
    Genius 3585 points

    Agreed, new issues after a big IDE change leave the IDE change suspect.  Thats why I gave myself a day to test the new configuration.

    Surprisingly, I launched LM Flash Programmer, erased the entire FLASH, then verified blank using the EKS ICD interface.  The program now breaks at main() and starts generating CAN messages.  So I am thinking that in this instance, the emulator fails to erase some portion of the memory.

    I wonder if the new version of emulator driver knows about the "erase page 1 and you get erase page 0 as well" issue with A1/A3 silicon.

    Guessing this, I went into the Properties -> Debug -> Tiva Flash Settings and selected "Use the erase options specified below" and "Entire Flash".  I have loaded a couple times and ran successfully.  (Geez.... It has Tiva in it!  So I know somebody has been mucking about in this area.)

    There may be a bit of my memory remaining from over a year ago when I started with the LM4F;  I needed to do this.  Upgrading to CCS 5.4 has had other issues of settings being changed in a project.  All my stack sizes were set from 2048 to 512.  I happened to notice while stumbling through settings.  That would have been an obscure way to break once working code.

    I remember that for a given chip, a given page would always have the problem of getting hacked when a neighbor was erased, other pages sometimes, and some pages seemed free of the issue.

    cb, thanks for your consideration.

    If this works for the next day, I will consider it fixed.   Back to actual development.  Most of two weeks on Tiva/CCS upgrade issues.  It makes my grand-mal changes that effect only one other engineer look tame!

  • 0 in reply to John Osen
    Genius 3825 points

    Even we are having the same issue with the new CCSv5.4 and the new Tiva C(TM4C123xx) devices.

    Sometimes when we try to stop the code through breakpoint and start again
    CCS throughs below error saying it cannot find boot.asm.

    Can't find a source file at "/tmp/TI_MKLIBiLt7no/SRC/boot.asm"
    Locate the file or edit the source lookup path to include its location.

    Should we ignore such errors...

  • 0 in reply to Prad1
    Genius 3585 points

    I saw this error as well.  But after the change above (erasing the entire area of the code being downloaded before downloading), I do not recall seeing this issue again.

  • 0 in reply to John Osen
    Intellectual 400 points

    I'm working on TM4C129DNCPDT and encountered the same problem. I don't have LM4F flash programmer to erase TIVa flash. Can I do it using XDS200 in CCS5?

    Thanks,

    Abhay 

  • 0 in reply to abhay shinde
    TI__Guru**** 244400 points

    Hello Abhay,

    Do you mean unlock the device using XDS200? Right now UNIFLASH does not support XDS debuggers for unlocking the device. You will have to use LMFlashProgrammer with Stellaris ICDI.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 400 points

    Hi Amit,

    What can be the reason device locking? I didn't anything different to cause this!

    Thanks,

    Abhay

  • 0 in reply to abhay shinde
    TI__Guru**** 244400 points

    Hello Abhay,

    Some of the common debug points

    1. Does the application code reconfigure the Port-C JTAG Pins to GPIO Function

    2. BOOTCFG register updated to disable JTAG

    3. Wrong Clock Frequency being set. This happens if a TM4C123 System Clock Configuration SysCtlClockSet is used on TM4C129

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Intellectual 400 points

    Hi Amit,

    None of the above things happened. Rather I was debugging the same code and without change in code , it started giving me the problem. As far as working of JTAG is concerned, it detects the JTAG and shows the programming window whenever I hit Debug option. then I can see debug related options are active like Run, Step in etc. It also shows error message in debug persepctive - Can't find a source file at "/tmp/TI_MKLIBiLt7no/SRC/boot.asm" 

    Thanks,

    Abhay