How to reset and erase program in TM4C custom board

Would not the long standard Stellaris program, "GPIO_JTAG.c" provide a quick/eased means - for you to recover/restore JTAG - thus allowing your reuse of those boards?

It's normal to employ a single GPIO pin or other mechanism to revert those JTAG pins away from any (likely) repurposing - which usually proves the cause of such, "Unable to connect" dreaded message...

May we note the following:

• Poster is (apparently) "locked out" - thus adding any loop is not possible
• Small while loop is far more detailed w/in past sample file, "GPIO_JTAG.c" which should be universally employed to "quickly/efficiently" escape from dreaded "lock-out!"

Inadequate promotion of "GPIO_JTAG.c" causes serious user delay/frustration, lowered morale.   (makes little sense...)

Re: Second part...prevent further lock outs...

Indeed for this poster - as had been mentioned previously.

Better - and to advise/protect/arm FAR MORE Users - remains the ADEQUATE PROMOTION of "GPIO_JTAG.C"   Pity that cannot (still) be allowed!

Hi Amit,

I use "MAP_SysCtlClockFreqSet()" and store frequency globally not to call SysCtlClockGet().

For JTAG PC0-3
    /*
     * JTAG/SWD Configurations
     */
    ROM_GPIOPinConfigure(GPIO_PC0_TCK);
    ROM_GPIOPinConfigure(GPIO_PC1_TMS);
    ROM_GPIOPinConfigure(GPIO_PC2_TDI);
    ROM_GPIOPinConfigure(GPIO_PC3_TDO);


For EPIO configuration of SDRAM

	//
	// EPI0S4 ~ EPI0S7: port C4 ~ 7
	//
	ui32Val = HWREG(GPIO_PORTC_BASE + GPIO_O_PCTL);
	ui32Val &= 0x0000FFFF;
	ui32Val |= 0xFFFF0000;
	HWREG(GPIO_PORTC_BASE + GPIO_O_PCTL) = ui32Val;

As you see, PORTC is configured in only above codes.

Thanks,

Jin

Hi Amit,

Even if JTAG pins configuration is done at reset, but configuration them again should not harm anything.
"Pins Set Up" function that configures all GPIO pins is called in the beginning of main() in my project.

Earlier I mentioned, I can not access the custom board. It does not matter whether using LM flash or CCS debug.

It seems to me hardware issues  but I am not sure which one causes the issue since "lock out" takes places as adding/updating codes that has nothing to do with GPIOs.

For example, I added

xTaskGetTickCount();

on the codes that runs well, which has not shown any "lock-out" issue, but right after programming the modified codes "lock out" occurred and does not let me access the custom board anymore. I have tried to rollback codes used to run well, but it hardly responses once "lock out" has occurred.
Sometimes I can program after hundreds times of power cycling, but it does not always work.

Afterward, I
Thanks,
Jin

Hi Amit,

Here is codes that are used in other modules as well.

unsigned long StartUpTaskInit(int channels, char *cp, long csize,
		int cbsize, char *dp, long dsize, int dbsize)
{

   portTickType xTime1, xTime2;

   xTime1 = xTaskGetTickCount();

/////////////////////////////////////////////////////////////////////////////////////
//////////////////   do something that runs well before adding     //////////////////
//////////////////   xTaskGetTickCount()                           //////////////////
/////////////////////////////////////////////////////////////////////////////////////
   
   xTime2 = xTaskGetTickCount();
   xStartupExecutionTime = xTime2 - xTime1;//xStartupExecutionTime declared extern

   return(0);	/* reaching here means success */
}

Actually, codes for getting tick count difference are used in other modules without any issues.
It's one of examples that I have faced with "lock out".
If 'lock out" continues on after hundreds of power cycling, I usually gives up and re order the new board.

However, the custom board is pricey and it could be not a good idea to keep changing the board without knowing issues.

What I assume is that some codes or setting are "latched" and ignore any accesses such as LM Flash or CCS as well as "RESET" attached on the board