EK-TM4C1294XL: How to reprogram a Launchpad with bad/crashing firmware loaded

Justin Reina89 said:

Didn't expect that one, sheesh! :(

And - who is to blame for your (limited) expectations?   Failures occur w/regularity - solution-searching (as opposed to complaining) proves superior.

JTAG pins AND System Clock are notorious here for, "Locking users out!"   (some vendors provide special (lost) "boot pins" to simplify recovery)

Recall that you reported (yet another thread) a mismatch between your System Clock and scope's measure.   And one here (moi) suggested that you, "Provide your System Clock and PWM code - impacted by System Clock.   It would have proved safer to present that code for "free & fast" review - prior to actually implementing and running it.

We "feel your pain" yet suggest your expectations be adjusted to (better) reflect "MCU field" reality.   System's crash w/regularity - this "comes w/the gig" - your management of the recovery (beyond complaint) is crucial...

Amit, thank you!

I used the following to correct this:

• Src: TI App Report - Using TM4C12x Devices Over JTAG Interface
• Sec: 5.3.1 (p. 21)

For convenience for future readers, here is the procedure from Sec 5.3.1 (direct copy):

• Start the LMFlashProgrammer utility and go to the tab “Other Utilities”
• Select the radio button in front of “Fury, DustDevil, TM4C123 and TM4C129 Classes”

• Power down the board containing the locked microcontroller
• Power up the board, while holding down the reset. The reset must remain pressed unless instructed by the LMFlashProgrammer to be released

• Press the “Unlock” button in LMFlashProgrammer. Press “Yes” in the pop up message box and then press “OK” in the information message box
• After some time, a pop up Information box will ask to release the reset. Release the reset and press OK in LMFlashProgrammer utility

• Finally, the board must be power cycled. At the end of this step, the TM4C12x microcontroller should return to its factory state

Thank you immensely for helping guide me towards solution. In retrospect perhaps, I should have known to look here but did not.

Thank you!! :)!

The following code produces the same error state (truncated form of OP):

• Code Source: E2E - DIVSCLK Bug found for TIVA C series pinmux utility

int main(void) {

	SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_OSC), 25000000);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ);

    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOQ));

    GPIOPinConfigure(GPIO_PQ4_DIVSCLK);

    GPIOPadConfigSet(GPIO_PORTQ_BASE, GPIO_PIN_4, GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_STD);

    GPIODirModeSet(GPIO_PORTQ_BASE, GPIO_PIN_4, GPIO_DIR_MODE_HW);

    SysCtlClockOutConfig(SYSCTL_CLKOUT_EN | SYSCTL_CLKOUT_SYSCLK, 100);

	for(;;);
}

When debug stepping through this code in CCS the code hangs at SysCtlClockOutConfig(), reporting the following info to the Console:

CORTEX_M4_0: Can't Run Target CPU: Timed out while waiting for target powerup/polling a hardware resource.
CORTEX_M4_0: Error: Connection with the target was unexpectedly lost.
CORTEX_M4_0: Failed to remove the debug state from the target before disconnecting.  There may still be breakpoint op-codes embedded in program memory.  It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

Thoughts?

Note: I tried GPIOPinTypeDIVSCLK(GPIO_PORTQ_BASE, GPIO_PIN_4); before the SysCtlClockOutConfig call and it did not solve the problem. Thought I would just desperately try ;0...

Oh my, cutting the U4.5 trace immediately corrected the problem. See below for the cut made -

A bit embarrassing that I missed such an obvious config and debug step, my strong apologies. Thank you for the help!!

Status

• Code outputs SysClk to PQ4

• Code runs through and does not hang, maintaining JTAG connection

Thank you again!