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

CCS/TM4C129ENCPDT: Losing firmware on reset

Allef Silva28
Intellectual 365 points
Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: EK-TM4C129EXL, UNIFLASH

Tool/software: Code Composer Studio

Hi,

I'm using the TM4C129 in my board who is based on EK-TM4C129EXL. I'm using the interface XDS100V2 to program.

When I load the firmware, it starts running correctly, but when I power cycle the board, the firmware is lost.

When I load the same firmware in Launchpad, it is not lost.

Can i have some help with this, please?

  • 0
    TI__Guru**** 191296 points
    Hi Allef,
    After you power cycle the board can you still connect to the board? If you use memory browser to view the content of the flash do you see your program image?
  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Hi Charles,

    Yes, I can connect the debugger after power cycle. I change the Debug Configurations, to Load symbols only. It is correcty if i want to reconnect only, right?

    But I can't see anything in Memory Browse.
  • 0 in reply to Allef Silva28
    TI__Guru**** 191296 points

    Hi Allef,
    Yes, if you had successfully load the program image before then you can just load the symbol for debugging. But were you successfully loading the program image? Can you reload the program image (either the .out or the .bin) and try to see if you can see the program image from the memory browser from address 0x0 and up. Reset the device, is the image still there? Power cycle the device, is the image still there?

  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Charles, I'm sorry. I'm not doing this the right way.
    Yes, I can see the data in Memory Browse now. When I power off the board, the data disappear, but after power on and reconnect, I can see the data again and the program still running.

    Looks like the program is loaded in flash, but it doesn't run from main after power cycle. If I connect the debugger again, the program runs correctly.
  • 0 in reply to Allef Silva28
    TI__Guru**** 191296 points
    Hi Allef,
    So the identical (same .out or .bin) code running from the LaunchPad is ok after a power cycle without debugger. Is this still a true statement? I kind of remember that when ingflash the code using CCS, it will jump to _c_int00 after flashing and run from _c_int00 instead of starting from 0x0. If there is some issue jumping from 0x0 after reset to your reset vector then this may be why it does not work after a reset or power cycle but only works after flash using debugger. But this does not exactly fit your problem description either.

    Can you also confirm again what is the result if you only reset the device (not power cycle)?
  • 0 in reply to Charles Tsai
    TI__Guru**** 191296 points
    Hi Allef,
    I will also suggest you start with something simple like a know working TivWare example and see if you can get it working on your board compared to the LaunchPad. This way we can better isolate the problem whether it is the board level or software or even the emulator.
  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Hi Charles,

    1. Yes. Exactly the same program is running normally from flash in launchpad.
    2. If I reset the cpu in Code Composer, I can see the same result in Memory Browse.

    I found this post here. I think it is the same problem.

    e2e.ti.com/.../157042

    I'm looking for this boot configuration pins in TM4C129 to check if they are ok.
  • 0 in reply to Charles Tsai
    Intellectual 365 points
    My project is based in the Blinky project from Tivaware.
  • 0 in reply to Allef Silva28
    TI__Guru**** 191296 points
    Hi Allef,
    I want to confirm one more thing. When you said the firmware is lost after power cycle. Are you saying you will see all 'F' as in erased state in the memory browser?

    The post you refer to is for a different MCU platform. It does not apply to TM4C. There is no boot pin to allow you booting from internal flash or external memory.
  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Hi Charles,

    It is not all 'F'. I can see the firmware now in Memory Browse. After some tests, I have more info.

    The firmware is running just with the debugger connected. When I disconnect the debugger and power cycle, the firmware don't run. If I connect the debugger again, the firmware start running.

    I can't run the mcu standalone.
  • 0 in reply to Allef Silva28
    Guru 117855 points

    I was going to suggest such, "Test w/debugger (remaining) on/connected."

    Often this signals that MCU reset pin - (on your custom board) is not properly managed by your pcb layout.    The debugger supplies proper "reset pin" management.

    Also - all custom boards do best w/external pull-up Rs placed at JTAG pins & MCU Reset.    (this also provided by debugger's attachment)

    Does this (same) failure occur on, "More than one custom board?"    That's important - each/every "new" custom board contains "infinite suspects" - testing "just one" gravely limits the diagnostic process...    (i.e. welcomes dreaded, "Single Board Anomaly!")   (i.e. bad solder joint, solder short, improper component value etc.)

  • 0 in reply to Allef Silva28
    TI__Guru**** 191296 points

    HI Allef,

      When you connect, where does the MCU end up in the code? Where is the program counter?

      On top of the suggestion by cb1, can you insert some while(1) code in your program. First put the while (1) in the ResetISR. I want to know if the CPU will jump to the reset vector. When you connect tot the MCU, it will just stay in the while loop. This way you know where and how the code is progressing. If it comes to the ResetISR then you can remove the while(1) and then put a new while(1) in the beginning of your main(). 

  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    May I note that staff/I enjoyed the video, "Charles treading water!"    (he's in water-logged Houston, folks...)

    Do note that poster (claims) that EXACT CODE runs properly upon the LPad!

    Thus - is it not (more) likely that a "Board Issue" (hardware) rather than software - proves our culprit?    

    Your methods are quite proper (but) for poster's note that the EXACT CODE runs properly - upon DIFFERENT HARDWARE!

  • 0 in reply to cb1_mobile
    TI__Guru**** 191296 points
    Hi cb1,
    The water (up to 31" on my street) receded Wednesday afternoon. No more water to play with. :-)

    Yes, I understand that the poster stated that the same code runs fine on the LaunchPad after each power cycle. This is an indication that hardware difference makes a difference. But I still like to know where the CPU PC is. If the reset pin as you have suspected might be the culprit, the location of the program counter will give us additional clues.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    With 31" of water - one suspects your "basement AirBNB rentals" - may not prove the "income adjunct" desired...

    Seriously - what a disaster - on my visits to Houston I recall the "sparseness" of grass-land - almost everything "paved" - thus water (of that magnitude) cannot be (safely) absorbed.

    Indeed extra clues may be helpful.    Yet - as stated - every "client pcb proves an adventure" - hardware issue (I believe) is always, "Main suspect."

    Code tests (have) some value - yet (so too) a proper (hardware) monitoring of MCU's Reset pin - both with & without the debugger attached!

  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Hi Charles,

    I put while(1) in ResetISR, the I power cycle the board again and connect the debugger. It is not going to ResetISR. The program counter is going to a position who I can't recognize. It is showing "0x0100BD7C (no symbols are defined)".

    In Disassembly, I can see it stopped in this line:

    -> 0100bd7c: ???? Memory map prevented reading 0x0100BD7C [code=0x20000]

    When I restart the CPU in Code Composer, the program starts running normally.

    I am very grateful for your attention.
  • 0 in reply to Allef Silva28
    Guru 117855 points

    Replacing, (I am grateful) "for your attention" (i.e. singular) - with, "for the attention" (i.e. plural) proves (properly) inclusive - less dismissive to the (repeat) efforts of others...

  • 0 in reply to Allef Silva28
    TI__Guru**** 191296 points

    Hi Allef,
    The 0x0100xxxx will be the ROM area. The CPU was executing code out of the ROM. The question to ask is if you have already placed the while(1) in the ResetISR then how can it not trap inside the while. This suggests that after reset the CPU did not properly load the PC with the value stored at the reset vector at 0x04. You mentioned that everything is normal if you "restart". Please don't use "restart" in the CCS. The restart will force the PC to the entry point. Please use the system reset instead.

    How many other boards do you have? Can you repeat the same problem on every one of your boards? Can you monitor the reset pin and see how it behaves and compare between when standalone vs when debugger connected.

  • 0 in reply to cb1_mobile
    Intellectual 365 points
    I'm sorry cb1_mobile. I'm not a native english speaker.

    I appreciate your attention too.
  • 0 in reply to Charles Tsai
    Intellectual 365 points
    Hi Charles,

    I have just one custom board for now. I'm preparing more boards.

    I will do more tests and reply soon.
  • 0 in reply to cb1_mobile
    Guru 117855 points

    cb1_mobile said:
    Does this (same) failure occur on, "More than one custom board?"    That's important - each/every "new" custom board contains "infinite suspects"

    Re: "How many boards do you have?"

    Great minds (at least yours so qualifies) may eventually converge upon the same guidance.    (pity that "KISS" as well as "LIKE" are both (improperly) banned here!)

  • 0 in reply to cb1_mobile
    TI__Guru**** 191296 points
    Hi cb1,
    Yes, if all custom boards will exhibit the same problem then it is most likely a board design problem. If other custom boards are fine then need to look at any loose components or any bad soldering on the questioned board.

    Hi Allef,
    Do you have an on-board XDS100v2 emulator or an external XDS100v2? I should have asked you earlier. I will assume you have an external emulator. Below link is a reference schematic for on-board XDS100v2 emulator incase yours is on-board.

    software-dl.ti.com/.../XDS100v2Schematic(rev2)-Setup.zip

    Please also look at the map file and find out where the the ResetISR is allocated and whether the value at reset vector at 0x4 is pointing to the proper address according to the map file. If not, what does it show? You can use the Uniflash or even from CCS to dump out the content of the flash and you can compare with the content of the Launchpad as a sanity check.

    Also check if proper power supply and noise on the supply and proper pullup (10K) on TMS/TCK/TDO/RESET pins per suggestion by cb1.
  • 0 in reply to Charles Tsai
    Intellectual 365 points

    Hi Charles and cb1,

    The problem is solved.

    The board are using a circuit for JTAG based on other board with Concerto microcontroller.

    29/5000
    I just adapted the circuit as described in this document:
    I found this because of the indications to check the pull up resistors.

    Thank you very much for the attention!

  • 0 in reply to Allef Silva28
    Guru 117855 points

    Thank you - glad that you followed the "pull-up R suggestions" I provided."    (see line below - this the first answering post, 01 Sept '17 @ 08:08)

    "Also - all custom boards do best w/external pull-up Rs placed at JTAG pins & MCU Reset.    (this also provided by debugger's attachment)"

    Note that your R170 (2.21K) between Reset & Gnd - will "HOLD your MCU in Reset" - (assuming you employed 4K7 - 10K R as Reset pull-up.)  

    It is suspected that you (removed) R170 - while insuring that Reset IS pulled up... Would you be so good as to confirm?    (your issue was assumed to be hardware due to the (claimed identical) SW running well on a similar board)

  • 0 in reply to cb1_mobile
    Intellectual 365 points

    Yes, I removed R170 in initial tests, but doesn't work!

    I need to change all the circuit.

  • 0 in reply to Allef Silva28
    Guru 117855 points

    You need a 10K pull-up on MCU's Reset!   (small cap from Reset to Gnd also helps)  

    It could not hurt to add similar pull-ups to your JTAG pins - as well...    MCU's (internal) pull-ups are TOO HIGH in value - not to be trusted...

  • 0 in reply to cb1_mobile
    Intellectual 365 points
    Hi cb1, we have a 10k pullup on microcontroller reset, like in launchpad schematic.
    I agree with you about the resistors, but i'm not the hardware designer. We learn with this mistake.
  • 0 in reply to Allef Silva28
    Guru 117855 points

    I wish you well.   Beware of HW guy's desire to save 0.20 (USD) by using MCU's (internal) pull-ups.

    Time the SW & Development team then "WASTES" - costs many multiples of any "HW Savings."     ALL costs must be considered!

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    I wish you well.   Beware of HW guy's desire to save 0.20 (USD) by using MCU's (internal) pull-ups.

    Time the SW & Development team then "WASTES" - costs many multiples of any "HW Savings."     ALL costs must be considered!

    Like!

    Or offloads high-speed, low latency responses to the S/W for the same reason.

    Robert