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

Compiler/EK-TM4C1294XL: Program Persistence after Power Cycle and Reset

KnightAngel
Intellectual 335 points
Part Number: EK-TM4C1294XL


Tool/software: TI C/C++ Compiler

Hello everyone,

I was wondering what could be causing a persistence issue on the EK-TM4C1294XL during a power cycle or reset?

I load code in debug mode to the board and it runs as expected.  I cycle the power (unplug ICDI cable ... wait ... plug ICDI cable back in) or press the reset button and observe no activity happening on a pair of LEDs that have been configured in the main forever loop (placed as a debug tool).  I wait several tens of seconds, longer than necessary, before re-entering debug mode and loading the code back to the board.  I am unsure if this is a configuration issue with my project or something else.  I am running Windows 10 x64 with CCSv7.

If you require specific information about my configuration and are aware of a way for me to provide this info without screen captures, please let me know otherwise I will provide screen captures upon request.

  • 0
    Guru 13040 points
    Hello,
    I am a bit unsure of the symptom of your problem, could not understand the description quite well.
    May I just comment that when you are in debug mode and insert breakpoints, you need to exit debug mode before disconnecting or powering down your target, otherwise the breakpoints might be "left uncleared" and your MCU will be stuck (there is a warning on CCS that tells that when you unpower the target).
    If that's not the case, then actually you might be running into an ISR fault that does not occur when you run on debug mode. That is not common, but could happen, for example, if you try to access a peripheral immediately after enabling it - since it might take a couple of cycles until it is actually ready to be used, the debug mode created the "necessary delay", while the normal run did not.
    Anyway, maybe you can add some more details.
    Regards
    Bruno
  • 0
    Guru 117855 points

    This may well be the absence of - or incorrectness of your (required) "Start-Up" file.

    The Start-Up file properly directs the MCU to execute the code which has been (properly) loaded (earlier) into flash - usually upon Power Up and/or Reset.

    It is expected that your issue results from your desire to, "Create your OWN Project" - which most always - causes the LOSS of key program elements and/or  critical linkages.    

    Your use of a vendor supplied (i.e. known good) project - and confirmation of that project's correct operation from power up - seems a good move at this moment.     Once achieved & confirmed - add your test code w/in that existing project - and retest.     You may then gradually & successively "comment out" the original project code - until all remaining - is your own!      (yet now - properly integrated)

  • 0 in reply to cb1_mobile
    Intellectual 335 points
    Thank you Bruno and cb1_mobile. It was a combination of breakpoints and my startup file. I copied the startup file from the project blinky and everything is working as I expect it.
  • 0 in reply to KnightAngel
    Guru 117855 points

    Thank you for the follow up.     You appear (quite) the diplomat...

    It should be noted that it is (now) Night - and that poster Bruno - though often "at the controls & at altitude/airborne" - registers (bit far) from Angel.

    That said - Neither "Knights" nor "Angels" were harmed (no Knights could be found ("Warriors" were plentiful) & Angels (minus MVP Trout) drifted downward) during the creation of this post ... and NBA Finals - MLB regular season play...