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: LM Flash Programmer Unable to initialize target

Part Number: EK-TM4C1294XL
Other Parts Discussed in Thread: SEGGER, TM4C1294NCPDT, UNIFLASH

Hello,

The EK-TM4C1294XL, connected to a custom EPI adapter card, had been running successfully.

With the adapter card card installed it had been CSS/LM programmed multiple times.

Problems with the arrangement developed so the adapter card was removed to test the EK-TM4C1294XL in stand alone mode

CSS was no longer able to program the EK-TM4C1294XL.

The original program running on the EK-TM4C1294XL permitted LM command line Ethernet programming which continued to work.

Using the Ethernet method, TI's gpio_jtag program was loaded and verified running through the COM port. It showed "Pins are JTAG".

Both CSS and LM were unable to program the EK-TM4C1294XL but were able to program other EK-TM4C1294XLs.

Signal capture shows no activity on TDO on the problem EK-TM4C1294XL but activity on the other EK-TM4C1294XLs.

Obviously no activity on the TDO is symptomatic. LM is not able to retrieve "Current Values"

If the gpio_jtag program is running showing "Pins are JTAG" why is it not possible to CSS/LM program the EK-TM4C1294XL?

LM Flash Programmer Build 1613

Thanks for your help,

Victor

  • Hi Victor,

      I think the gpio_jtag starts out printing "Pins are JTAG" initially and also both g_ui32Mode and ui32Mode are are both initialized to zero. After you press the switch, the interrupt ISR with change g_ui3232Mode to 1 and that will cause the message "Pins are GPIO". 

      If you have already proved that TDO has no activities then the target is inaccessible by the debugger/emulator. Please try to go through the unlock sequence and see if you can recover the device. 

    int
    main(void)
    {
        uint32_t ui32Mode;
    
        //
        // Set the clocking to run directly from the crystal at 120MHz.
        //
        g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                                 SYSCTL_OSC_MAIN |
                                                 SYSCTL_USE_PLL |
                                                 SYSCTL_CFG_VCO_480), 120000000);
        //
        // Enable the peripherals used by this application.
        //
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC);
        ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
    
    
        //
        // Initialize the button driver.
        //
        ButtonsInit();
    
        //
        // Set up a SysTick Interrupt to handle polling and debouncing for our
        // buttons.
        //
        SysTickPeriodSet(g_ui32SysClock / 100);
        SysTickIntEnable();
        SysTickEnable();
    
        IntMasterEnable();
    
        //
        // Configure the LEDs as outputs and turn them on in the JTAG state.
        //
        ROM_GPIOPinTypeGPIOOutput(GPIO_PORTN_BASE, GPIO_PIN_0 | GPIO_PIN_1);
        ROM_GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0 | GPIO_PIN_1, GPIO_PIN_0);
    
        //
        // Set the global and local indicator of pin mode to zero, meaning JTAG.
        //
        g_ui32Mode = 0;
        ui32Mode = 0;
    
        //
        // Initialize the UART, clear the terminal, print banner.
        //
        ConfigureUART();
        UARTprintf("\033[2J\033[H");
        UARTprintf("GPIO <-> JTAG\n");
    
        //
        // Indicate that the pins start out as JTAG.
        //
        UARTprintf("Pins are JTAG\n");
    
        //
        // Loop forever.  This loop simply exists to display on the UART the
        // current state of PC0-3; the handling of changing the JTAG pins to and
        // from GPIO mode is done in GPIO Interrupt Handler.
        //
        while(1)
        {
            //
            // Wait until the pin mode changes.
            //
            while(g_ui32Mode == ui32Mode)
            {
            }
    
            //
            // Save the new mode locally so that a subsequent pin mode change can
            // be detected.
            //
            ui32Mode = g_ui32Mode;
    
            //
            // See what the new pin mode was changed to.
            //
            if(ui32Mode == 0)
            {
                //
                // Indicate that PC0-3 are currently JTAG pins.
                //
                UARTprintf("Pins are JTAG\n");
            }
            else
            {
                //
                // Indicate that PC0-3 are currently GPIO pins.
                //
                UARTprintf("Pins are GPIO\n");
            }
        }
    }

  • Hello Charles,

    Thanks for the quick reply.

    I toggle SW1 a few times just to make sure I wasn't being fooled. No change.

    For the last step Power Cycle, is that with the Reset switch asserted?
  • Hi Victor,
    yes, hold the reset while clicking the OK button when it is prompted by LM flash programmer.
  • Hi Charles,

    I successfully unlocked a good board.

    The last step...Power Cycle...does not need the Reset switch to be asserted.

    I also noticed the bad board LEDs are not toggling when switching between gpio/jtag modes as they are on my good board.

    I think this bad board has left the building with Elvis.

    Any other suggestions?

    Thanks,

    Victor
  • Hi Victor,

      Are you able to successfully run the unlock sequence on the bad board? We need to isolate the problem between unable to program the board and LED not toggling. If you are able to unlock the device and load other programs then you can check what might have caused the LED to not toggle. You can do some resistance check. I hope the bad board is like Elvis's songs which will still live on. :-)

  • Multiple, "mentions of Elvis" may prove sufficient for the "King" to emerge (surface, really) from his (just lightly flooded) "Key West/secret abode"  - and  join cb1/others  - in the (fair/proper/on-going) protest of, "LIKE" having (unjustifiably), "left the building..."     (unlike Elvis - who has simply, "left (only) the mainland...")

  • Hi cb1,
    This post marks your 80k points milestone. Congrat! What an achievement!
  • "Thank you - thank you (very) much!" (voiced in my (very) best "Elvis")
    Note that "1K+" such (past) points resulted from "LIKEs" - which have been recently "pulled" - for the most (suspect/unjustified) of reasons...
  • Hello Charles,

    I agree with you that some additional checking is needed and will follow up.

    Understanding the unlock process is important. From what I can figure out it is necessary to remove a rogue program which is holding the JTAG I/O captive. In this scenario a complete power cycle, which defaults PC0 - PC3 back to JTAG is ineffective since the rogue is then executed, reprogramming these ports.

    The Unlock wipes this program from Flash which booting up defaults to...?

    Wiping the MAC prevents...?

    Clicking the OK button at the "Assert and hold reset while powering up the device." causes the ICDI to attempt to erase the Flash and the MAC address.

    On my good board you can see activity (the reply back?) on the TDO line and the rogue is gone. On my bad board no activity occurs and the rogue remains.

    A chance to earn your points cb1.

    Thanks to all in helping to revive Elvis.

    Victor
  • Have you considered that (just maybe) the more mature - more focused - and more capable "J-Link from Segger" also has the proven capability to, "Restore Order?" As the J-Link is the "top selling" JTAG/SWD Probe - was designed by a group specializing in such designs - and is the "JTAG Probe of choice" for most "pro/seasoned users" - it (well) warrants your consideration.

    "Lock Out" - as you are now experiencing - is SO hard to accept - yet seems to occur SO often here. And - might that clear "weakness" far more deserve "rectification/correction" - than the (claimed) forum upgrade - which has dispatched "LIKE?"

  • You will note that...

    Elvis (the bad EK-TM4C1294XL) is a developed product from TI.
    Formerly he was fully programmable through his onboard ICDI.
    He has no other hardware attached to him apart from the debug USB and five Saleae logic probes on the JTAG.
    Currently he Is running TI's gpio_jtag program but is unable? to toggle the LEDs.
    He does not respond to the LM's commands...
    There is no activity on the TDO line during the unlock process.
    The current program is not erased.
    How will attaching (Bob) Segger wake Elvis up if he is deaf or cause him to sing a TDO song if he is mute?

    The purpose here is to determing why the onboard TI ICDI is unable to restore the EK-TM4C1294XL to a known/factory state.
  • With reference to Tiva™ TM4C1294NCPDT Microcontroller DATA SHEET SPMS433B...
    4.3.4.1 refers to a lockout situation through reprogramming the JTAG to GPIO
    4.3.4.3 Recovering a "Locked" Microcontroller indicates the lockout process needs to be repeated several times with reset asserted
    Might I assume this is what the LM is doing during the unlock process?
  • Hi Victor,
    Yes, this is what LM is doing.

    When you use the LM programmer to unlock the board, what does it say?

    If the good board was previously loaded with gpio_jtag you could still recover by running the unlock sequence, correct?
  • Hi Victor,
    Uniflash can also be used to unlock the device. Uniflash supports ICDI as well as other emulators.

    Do you also have an external emulator? If yes, can you successfully connect to the MCU? If you could connect then you can erase the flash either via CCS or Uniflash.
  • Hello Charles,

    I am not with my board at the moment. This evening I will walk through the process using both the bad and a good board then get back to you.
  • I think the clue lies with the non responsive TDO line.

    If you desire I could capture some good/bad logic traces for you. I am using a Saleae which saves the capture in it's own format. It can also export data as Binary, Csv, Vcd and Matlab.

    Granted it's an easy to toss away $30 board but discovering why this is happening might be important down the road.

    Thanks,

    Victor
  • Might you "discount" the "effectiveness of the far superior J-Link" in rescuing your 30 (USD) investment?    And "preventing" yet another "HARD LANDING!"

    Have you not noted the LARGE NUMBER of users - like yourself - becoming "Locked-Out?" Does that not "signal" something?    Which tools (most always) are they using?

    JTAG/SWD Probes - designed to support MANY (likely ALL) ARM MCUs - (likely) have received FAR more development time/design insight and investment than the (lesser ones) you have chosen - is that not true?

  • I know in the past I have not had a problem with TI's ICDI on both the 123 and 129 Launchpads.
    I know this particular board has proven fault free through many loads.
    I have replacement board already in place so getting this board going is not critical.

    I have spent over 20 years working with hardware engineers bringing up and debugging systems. Is it a design flaw, a programming error or simply a damaged MCU. My objective here is to work with TI, who have been outstanding in supporting me in the past, to determine where the Launchpad stands.
  • Hello Charles,

    I did some captures last evening running the LM Unlock cycle on both a good and the bad EK-TM4C1294XL LaunchPads. Each test was performed after a power-cycle.

    Note that the ICDI asserts the reset so it is unecessary for the user to do so (at least when TM4C1294XL LaunchPad is selected from Quick Set). It is required that the board be power-cycled up after the unlock process is complete.

    Good board showing just the LM Unlock, JTAG <-> SWD toggle part

    Bad board showing just the LM Unlock, JTAG <-> SWD toggle part

    Good board showing the full LM Unlock process

    Bad board showing the full LM Unlock process

  • Hi Victor,
    Ok, looks like the device may be bricked. But I'm not sure if this is worth trying for one more experiment. You can use the ICDI on your good board to debug the bad board or if you have an external emulator such as XDS200 in conjunction with Uniflash you can try to see if you can connect and go through the unlock sequence.
  • Hello Charles,

    Good to know when to hold and when to fold. For the moment I will place Elvis on the shelf. When I move to my own design and acquired an XDS I'll give him another exploration. Conversely would your engineers welcome doing a post mortum on him?

    Since my current project focus is on the TM4C129 is there any benefit to spending three times the price on a XDS200 rather than a XDS100?

    Has Amit moved on?

    Once again thanks for your help,

    Victor
  • Hi Victor,
    I was wondering if you already have a XDS200 that you can try. XDS100 will do as well. If you don't have them then it is not worth the money to buy an emulator just to try the bad board unless you are purchasing for the long haul to have better debug capability. I think cb1 will recommend J-link and IAR though. :-)

    Amit is still our go to person if we need further assistance.
  • Victor L-S said:
    I have spent over 20 years working with hardware engineers bringing up and debugging systems. Is it a design flaw, a programming error or simply a damaged MCU.

    My background is similar - have realized (some) success (co-founded, VP Eng. took past tech firm PUBLIC - work now w/"VCs") and "Autonomous Auto."  

    You may note that I am "NOT your enemy" - instead seek to provide support (sometimes) outside this vendor's (any vendor's) "comfort level."    Firm/I have NO DOUIBT that Segger's J-Link is superior to all implementations found here!    (neither firm nor I receive compensation from Segger)

    You've been active here long enough - surely you must have noted the NEAR DAILY ARRIVAL of posters - suffering from "JTAG Lock Out!"    (and most always - it is "vendor tools" ONLY "in play.")    Does that not "ping your radar?" 

    Firm/I/clients employ many ARM MCUS - from multiple vendors - hard to (even) imagine that "One Vendor - always & only - provides the "optimum solution."   (this proves why even "giants" engage our firm)   It is our "repeated finding" that use of the "J-Link" substantially (appears) to "Prevent such JTAG issues" and on multiple occasions we have "restored JTAG by use of our J-Link!"    Indeed that's anecdotal - yet you remain silent as to the "presentation of fact in (vast) favor of the J-Link" - when compared to the newer, less capable, vendor restricted JTAG "implementations."    (might that (unnecessary) "vendor restriction" cause or contribute to such ISSUES?     Such "restriction" is not at all present upon the "ALL VENDORS WELCOME J-Link!")   Yet - you (appear) to have ruled such facts out - while your suffering/doubt remains...   (perhaps builds)

    While your objective appears proper - you may note your issue as (long) on-going - and (appears) not to have received "full/proper & corrective" attention.

  • Hello CB1,

    Agreed that "JTAG Lock Out" is a constant here. Would Segger solve an RBias issue. Can Segger bring a brick back to life? I think presenting the problem/solution/resolved incidents tabularized on their own page might lessen the search/miss/post syndrome we see here.

    And I am quite willing to send Elvis to you to explore all possibilities in getting him to sing again.

    All the best to you.
  • Greetings Victor,

    So - as hoped - you TOO (really who does not) recognize the too often occurrence of JTAG Lock-Out!       Yet - there appears "insufficient time/effort to repair - or at least - safeguard/work-around!"     Yet there WAS time to perform a "self-proclaimed" forum upgrade (vastly disputed btw - especially the reprehensible BANNING of LIKE!)

    As to Rbias - firm/I have NO interest in 129 class (there ARE M4's which have run 180MHz+ - include Graphic Accelerators - and DACs - and better accommodate newest TFT Displays) so I am unable to comment - although it appears doubtful to correct an "absent component."

    Yet (again) we have witnessed "DEAD "4C123s" and before they (DEAD LX4Cs) "Return to LIFE" due to the replacement of the (pardon) "cobble" w/J-Link.     That's rather conclusive (my time @ UCLA law, believes)...

    While it would be a "delight" (not to travel to the "Keys" to hear Elvis) would it not prove more beneficial to YOU - to acquire a J-Link (available at special, student discount (and without your having to "fabricate" student status!) for your own, superior use?    (you will NOT "go back" to mediocrity...)   

    As you noted - the issue appears to be from among (alone or in combination):

    • undue MCU "sensitivity" among (certain/multiple) of the JTAG pins
    • signalling errors (which may be transient) and/or other "weakness" w/in the ICDI implementation.   (likely developed w/out the benefit of J-Link's: development time, fund investment, focused skills and (possibly) further "impeded" by vendor efforts to "restrict usage" of (so flawed) a tool!

    Being "locked out" (either from JTAG) or from house/car (as cb1 found himself, last night) is NEVER pleasant.    By great fortune I was able to secure a "bolt-cutter" and "break in" - in the dark 21:00 (to our off-site warehouse - which held my car/house keys!)     Pity that vendor here (able to BAN the LIKE) appears (rather completely) unable and/or unwilling to ADMIT the ISSUE and SOLVE IT!

  • In addition to cb1's notes you might observe the additional supporting tools that come with the JLink.

    Robert
  • It should be noted that (expert) poster Robert also:

    • is a fan (and user) of J-Link
    • also feels intense dissatisfaction w/forum's recent (claimed) upgrade - which has accomplished (almost) nothing - WHILE banning the "uber-motivating LIKE!"

    The cost of "lesser" tools (especially "suspect" tools) is "borne every day" - at each/every programming/debug session - thus is NOT the "place" to save!     (and - may we ask - what has "been saved" when JTAG (AGAIN) crashes?     Are users expected to "LIKE" that - even though this situation has been LONG ON-GOING - GREATLY INCONVENIENCING & FRUSTRATING?      

    Yet - somehow - there IS time to attempt (mirage like) forum upgrade - while Banning the useful/motivating/long-standing, LIKE!

  • I'm not objecting to JLink. Here is an opportuntity to show the "superiority" of JLink in restoring what the onboard TI ICDI could not do. I'll cover the shipping charges. cb1 declined the offer. Do you wish to pick it up Robert?
  • Victor L-S said:
    Here is an opportuntity to show the "superiority" of JLink in restoring what the onboard TI ICDI could not do.

    I'm assuming it's probably done for.  I've not run into JTAG lockout (maybe because I don't try to re-purpose the JTAG pins) so I don't have any experience using it to recover from such an event.

    My only point was that besides any such benefits that cb1 has experienced with lockout and besides the decided advantage of avoiding vendor lock-in there are tangible benefits to the J-Link over the TI offerings*.

    Robert

    * And, I think I probably mentioned the least of them but that's rather subjective.

  • So are we all in agreement that after viewing the logic captures the board seems to be "done for" and that the wisdom here was in investing in a proper logic analyser that allowed us to see such?

    I agree repurposing JTAG pins is a bad idea and why that was ever permitted escapes my thinking. My experience has been with the 123 and 129 which have a built in escape plans to exit from rogue programming. If you look at the first trace capture you will see that the LM Flash Programmer with the onboard ICDI does exactly what the documention requires to get out of a hijacked JTAG situation.

    As cb1 has no interest in the 129's I fail to see why he even bothers to comment in my thread except to complain that nobody can LIKE him any more. If he doesn't like the forum arrangement start another thread for that! If he truly was a debug specialist he would have asked for trace captures to see what was going on.

    What you and cb1 both have missed in my original statement is that I had a EPI daughter card installed. It was purposed as an Flash array reader. Although it was sucessful in reading numerious times on several external arrays, could there be a design flaw that corrupted the GPIO/JTAG arrangement?

    The board was limping along. The UART was outputting messages but the LEDs were not lighting. Elvis was not dead but some internal organs seem to have been damaged. I admit disappointement that Charles didn't say.."hey yes send it in" only that he could reply back that I blew out the GPIOs.

    Let's not forget the newbies among us (of which I was once) entering the TI realm. I believe this forum is to support TI and it's products. Do you agree?
  • @Victor,

    Victor L-S said:
    cb1 declined the offer.

    First year law teaches that (any) contract must include (both) an "offer" followed by an "acceptance."    

    You've "made an offer" - I've NOT "accepted."    Why might that be?

    • is it not true that - even if successfully recovered - you will revert to the same (limited/restricted) vendor tools - which likely caused the disruption?    What then has been gained?    You'll (likely) characterize my "fix" as "not lasting" - even though "vendor tools" prove the clear cause...
    • have you not (repeatedly) attempted to recover the device - each/every time "FAILING" (via use of vendor tools) - might that have rendered (that) particular MCU (even) more damaged?    (possibly beyond repair - that's not an especially FAIR Test for the J-Link - don't you agree?)
    • J-Link's greatest benefit - beyond "preventing and/or greatly reducing JTAG lock-out" and being (often) "able to recover a failed MCU" may be the extent & detail of its "diagnostics."    Do the cryptic messages provided by vendor tools provide much/any real value?
    • clearly - "vendor's restriction methods" (to their MCUs only) prove OUTSIDE normal/customary JTAG protocol!    (you/others appear to have "missed" this.)    Is it not possible that "dreaded Lock-Out" results from (any) disruption to this "MCU verification" process - or some "vendor code limitation" - thus "disrupting/halting" the JTAG sequence?     Note that the J-Link/similar "pro" JTAG Probes "have no knowledge" of vendor's "unique" verification process - thus proceed (only) in full/proper compliance w/"normal/customary JTAG operations."   

    The responsibility here is (clearly) yours!     Off-loading to "non-vendor" others - while reducing your time/effort commitment - adds to ours - and our "reward" for time/effort expended (remains) unspecified.   Note that both Robert & I work @ "profit seeking" enterprises - may not "welcome" such "one-off, low level, projects..."

    As past presented (and repeated) best practice sees "you" starting anew w/J-Link & "unsullied" MCU - and monitoring to see if this "Lock Out" condition can be, "reduced and/or avoided!"

    I believe the presentation here to be sound & considered - presents facts not (generally known/in play) and YOUR Acquisition & Effort (rather than ours) registers, "most appropriate!"

  • You are empty verbage. Stand up and say yes I will give it a try. You are a coward but refuse to admit. it 80000 worthles points!
  • Hi Victor,
    Let me find out the return flow in the event as such and I will get back to you privately.
  • Please all, can we focus on the technicals only.
  • Certainly Charles. I apologize to the forum for my outburst.
  • Victor L-S said:
    You are empty verbage. Stand up and say yes I will give it a try. You are a coward but refuse to admit. it 80000 worthles points!

    "Somehow" - one gets the impression that poster, "May not LIKE me!"    Might "venom" flow - bit too strongly?    (i.e. far out of proportion to the alleged "sin!")

    What backup has been produced to justify ANY of the above?     Are (many) other "baseless/unsupported" such claims poster's "norm?"    Are we not "free" to accept/reject (unusual/overly demanding) request?

    My tour of duty as (past) US Army combat officer may operate against your charge of, "coward."

    Working for you - for FREE - proves NEVER high upon firm/my agenda...    And is outside of my interest - as I significantly documented.
    Despite your attack - I (continue) to wish you well...    (and friends/family/fellows will "steer clear"...)

  • Charles Tsai said:
    Please all, can we focus on the technicals only.

    With the exception of, "one - admitted outburst - for which the poster has apologized" have not the "technical" issues received central focus?

    Documenting one's point of view - especially when such "does not meet poster's wish/hope/expectation" is necessary (as it explains/justifies) is it not?

    Use of "all" (as quoted) seems too broadly aimed - and "offending poster (likely) had "heat of the moment" (outburst - his word) - already forgiven...

  • A point about the forum

    Victor L-S said:
    I believe this forum is to support TI and it's products.

    Well, no. It's to support the TM4C line of products. TI's representatives may be constrained in their ability to suggest supporting products from others or in their ability to point out the weaknesses in their supporting products. I'm not so constrained and indeed would consider myself remiss in my responsibilities if I did not point out alternatives to hobbyist tools (and worse vendor locked hobbyist tools). I've benefitted from such in the past from others. So while I won't, and don't, make a point of doing so at every mention I will still continue to do so politely when I think it may be of use to either the person inquiring or other readers.

    It's this ability to drift beyond a strict vendor only/register only discussion that makes such forums useful.

    Robert

    You will note I also suggest PC-Lint from time to time for much the same reasons