• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 31 subscribers
  • Views 2504 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.

TM4C123GH6PM: program loss on power down

Franklin ascarrunz
Prodigy 65 points
Part Number: TM4C123GH6PM

I am using the TM4C123GH6PM on a custom board. The issue I have is that after a few power cycles the program stored in flash will become corrupt and the part will need to be reprogrammed after which it works well for a few power cycles before failing again.

What could be the cause fo this behavior? I have tried replacing the part with the same results.

  • 0
    Guru 117850 points

    Far more facts are required prior to a "proper analysis" being formed & presented.

    You provide NO detail as to your - or your board producer's, "Focused Skill Level and experience."     That's important - is it not?

    This vendor has presented a most comprehensive, "Board Design Guidelines Document" - have you, "Read, Understood & Complied" with it?      Note that "Ignorance of the law" provides NO defense for law's violation; likewise "ignorance of that vendor document" (also) provides no defense.    (You must avail yourself of "every Tech Advantage, Signpost - prior to launching such a design!")

    The fact that you claim "some period of successful operation" proves quite good.    

    That said - is your failure, the result of:

    • the number of power cycles
    • simple passage of time (i.e. as if the capability to perform, "drifted away")

    Such cannot be gleaned from your writing.

    On a fresh board - "everything" is suspect.     Power and proper treatment of each/every MCU pin (especially power pins) is mandatory.    

    Was your board's schematic professionally reviewed - and approved?    Were components employed, "all known good?"    Was the board properly soldered - was the MCU properly "ESD Guarded" throughout each/every aspect of MCU handling & assembly?

    These are (just) some of the questions - demanded by (any) new board design.    As you may note - many "hard & current facts" are required for thoughtful & effective analysis...

    Such a board's creation (surely "Multiples of the cost of an LPad") in light of the MANY Challenges incurred - may NOT make "great sense!"    

    Development instead - of an (LPad connected) pcb (such added pcb - limited to the specific (added) features you require) - often provides a, "FAR MORE SOUND & REACHABLE GOAL!"

    As always - building "just one pcb" - provides a VERY FALSE Economy.    (i.e. NO economy!)     Multiple boards enable the detection of hated, "Single Board Anomaly" - single boards - offer such anomalies as a FEATURE!     (NEVER Good!)

  • 0 in reply to cb1_mobile
    TI__Guru 72500 points
    Is the program on the device trying to do any flash programming or erasing? Something like a boot loader? Have you compared the flash contents of the device after it has failed, with the expected contents? Are sectors erased or are extra bits programmed?
  • 0 in reply to Bob Crosby
    Guru 117850 points

    Wow - such a "difference" in approach!     Yet - do not (each) have their place?

    "MCU-Centric" (from vendor) versus "Pcb/Assembly/Component" issue - (from outsider.)      Due to the "demands" upon a "fresh" pcb - I'd bet on a "board design/assembly/component issue" maybe 10:1...

    Solely from post's construction/content - and poster's newness - use of any "BootLoader" seems remote...     (we shall see - analysis of ALL the facts (as taught beyond Eng. school) often proves highly useful...)

  • 0 in reply to Bob Crosby
    Prodigy 65 points

    Hi Bob,

    The program on the device does not do any flash programming or erasing. I will check the flash contents as you suggest and get back with you.

    Best regards,

    Franklin

  • 0 in reply to cb1_mobile
    Prodigy 65 points
    Hello, the board and program function as expected for several months without degradation or loss of functionality. The problem arises after power cycle. The issue is not constrained to one assembled board nor was it a defective chip. A description of the design/assembly/quality procedures seems unproductive. Bootloader has been stripped from the code in attempt to isolate the issue hardware vs code.

    What I would like to know is what mechanism protects flash from being erased/written and can transient on one of the JTAG pins cause this problem.
  • 0 in reply to Franklin ascarrunz
    Guru 117850 points

    There is "so much" - new & useful in this 2nd posting - best to include such, "initially."

    You note the board (singular) functions for several months - w/out degradation.     Are we to assume that power is ON (constantly) - for the entirety - of those "several months."     (pardon - such seems unlikely - really deserves confirmation)

    You now note, "Not one board" - yet provide no indication of the "lot size" produced.    Does not the "frequency of the issue and/or percentage of boards affected" come into play - thus prove useful to reveal?

    Finally - the "design/assembly/quality" description - to you - seems "unproductive."     May we ask, "How you come to such conclusion?"    

    Does the fact that your board - or boards - suffer this (rare malady) while so many other, "professionally designed/assembled/qualified boards" do not - clearly point towards, "design/assembly/quality" as, "Prime Suspects?"    If not that - then "all burden" falls upon the MCU" - and such defect would have been "long noted" - is that not likely?

    If you have not, "Re-Purposed the JTAG pins" - it proves "best practice" to avoid the introduction of stray signals.    It may prove useful to, "Switch the JTAG pins to GPIO inputs - and then ground each one."     Such should remove "Transients upon JTAG" as a cause.

    Your reported issue is "rare" - all of our firms (thousands) of custom boards expose JTAG/SWD routings to board-edge headers - and I cannot recall "ANY" boards falling victim - as you report...    As one of the longest forum participants - I also cannot recall any issue (landing here)  - highly similar to yours, either.     Somehow - no matter your (unexplained) resistance - "Design/assembly/quality" - unique to your boards - (continues) to Bubble Up!

  • 0 in reply to Franklin ascarrunz
    Guru 27665 points
    I agree with cb1, from your present description it looks like a hardware issue but I want to ask a question that might shed light elsewhere.

    You say you are not writing to flash, are you writing to the on board EEPROM?

    And somewhat relatedly, you say the problem only occurs on your custom board but not the Launchpad, do the two boards run different programs, or run the same program differently? IE dos the Launchpad execute differently because it does not have the same peripherals/is not in the same environment?

    Robert
  • 0 in reply to Robert Adsett
    Guru 117850 points

    Well conceived & presented Robert - nicely done.

    Posters here - "coming to conclusion" - yet w/out explaining or justifying their logic/thought process - weaken their credibility.   Unexplained "defense" - of a "highly suspect" area or event - does not ease/enable, "Efficient Problem Resolution!"

    And once again - poster arrives here - unable to "self-resolve" - yet (somehow) attempts to "dictate" the diagnosis process...

  • 0 in reply to Robert Adsett
    Prodigy 65 points

    I am not writing to the EEPROM. It most likely is a hardware problem, however I am trying to understand what could affect the MCU flash integrity as I have not seen this problem before. Any issue involving flash integrity is concerning. I am not running the program on a Launchpad as the peripheral mapping is completely different, however it is something I will try on a similar design/ board that does not have this issue.

  • 0 in reply to cb1_mobile
    Guru 117850 points

    cb1_mobile said:
    It may prove useful to, "Switch the JTAG pins to GPIO inputs - and then ground each one."     Such should remove "Transients upon JTAG" as a cause.

    Poster (today) notes, "I am trying to understand what could affect the MCU flash integrity."

    Does not this (earlier) posted suggestion - meet your (latest & earlier) similar request?

  • 0 in reply to cb1_mobile
    Prodigy 65 points
    I am trying that as well thanks.
  • 0 in reply to Franklin ascarrunz
    Guru 117850 points

    Thank you (thanks) always appreciated.

    Note too - that vendor's directive of (many) bypass caps - very close to MCU power pins - is most valid! I don't know/use your MCU - but those which include "LDO" pin - have (very) tight (external capacitor) specification. You (must) comply.

    From (too many) years in MCU trenches - proper MCU POWER is "JOB #1" - thus remains (most always) "Prime Suspect."    (which explains WHY: Board's "design/assembly/components" so often cause issues!)