[参考译文] SW-TM4C：用于确定程序为何最终出现在FaultISR中的简化方法

static void
FaultISR(void)
{
	volatile int i = 1;
    while(i)
    {
    }
}

//*****************************************************************************
//
// This is the code that gets called when the processor receives a fault
// interrupt.  It prints any queued debug messages (including tracepoints)
// then enters an infinite loop, preserving the system state for examination
// by a debugger.
//
// If have trouble figuring out why we get here, check to see if there is a
// way to see which vector was used.  Could also make multiple ISRs and make
// each suspect vector point to a different one.  Update: it looks like FaultISR(),
// unlike IntDefaultHandler(), is pointed to by only one vector.  Might still
// be able to look at register values and determine what triggered the "hard fault".
// - Also consider setting a global to different values at various places in the
//   code so can check its value here and see which of those places it was last set.
//   Perhaps use a macro that sets a "checkpoint" (pointer to the filename or
//   maybe function name and an int to the line number).  Search for
//   "ktowyawesctlcic".  Todo.
//
//*****************************************************************************
static void
FaultISR(void)
{
	// Print messages before going into infinite loop.  If the COP watchdog is
	// enabled, this printing probably would have happened in a bit anyway when
	// watchdogTimeoutISR() got called.
	extern volatile uint32_t sysTickMillisecondCount;												// defined in sysTick2.c
	blockWhilePrintAllDebugMessages( sysTickMillisecondCount, "FaultISR" );

    //
    // Enter an infinite loop.
    //
	// There are a couple of ways to (sometimes) determine which code was running
	// when the fault occurred:
	// - Exit this loop and single-step out of this ISR to the calling code.
	//   To trace back out of this ISR, use debugger to change the value
	//   of i to 0, then click the "Assembly Step Into" button several times
	//   (usually 4 to 6) or try the C step-into button.
	// - See "Debugging - tracing how got into ISR.docx" for how to inspect
	//   the stack by hand and modify the PC to make the debugger show the calling
	//   code.
	//
	// If unable to trace back out, it may be because the stack got hammered.
	// - It could be that the stack is too small and is overflowing.
	//   - There is a process for checking the available stack space documented
	//     in the firmware release procedure.
	//   - You can set a watchpoint on __stack as described in
	//     processors.wiki.ti.com/.../Watchpoints_for_Stellaris_in_CCS
	//     to get the debugger to stop at the point the stack overflows.
	// - It could be that the stack frame is being overwritten even if the stack
	//   itself is not overflowing.
	//   - Can hammer the stack frame without overflowing the stack.  For
	//     example, could have a local array on the stack and overflow it.
	// - The stack pointer itself could get changed to an invalid location.
	//
	// Other possible ways to get clues about the cause:
	// - Look at contents of stack for clues (like strings).
	// - Enable IF_DEBUG_LOCKUPS_USING_TRACEPOINTS_MAIN_LOOP and similar code
	//   to help track down where the buffer overflow is occurring.  Search for
	//   "ktowyawesctlcic".
	// - Acquire a "reverse debugger" (perhaps using debug hardware with trace)
	//   so can look back to the point it all went wrong.
    //
	volatile int i = 1;
    while(i)
    {
    }
}