TM4C1294KCPDT: TM4C1294KCPDT Debug

Hi,

  The difference between TM4C1294NCPDT (1024kByte flash) and TM4C1294KCPDT (512kBytes flash)  is the flash size. Please make sure your program image will fit in TM4C1294KCPDT. Look at the .map file and find out the program image size.  Next you need to find out if your program will dynamically allocate memory for heap or jump to any memory location beyond your flash size. If you dynamically allocate heap that goes beyond the amount of memory you have then you get memory fault or other faults. 

Next, for IntDefaultHandler, this normally means you did not have a vector created for the peripheral. You need to find out which peripheral is generating interrupt and plug a vector for it in the startup file. Without an associated interrupt vector for the peripheral, the processor will jump to the default ISR which is IntDefaultHandler. Look at a typical startup file below. Most of the vectors are default to IntDefaultHandler. Let's say you are using GPIOA to generate an interrupt. When processor responds to GPIOA interrupt it will jump to IntDefaultHandler. IntDefaultHandler is doing nothing but spinning in a while loop. 

//*****************************************************************************
//
// Forward declaration of the default fault handlers.
//
//*****************************************************************************
void ResetISR(void);
static void NmiSR(void);
static void FaultISR(void);
static void IntDefaultHandler(void);

//*****************************************************************************
//
// External declaration for the reset handler that is to be called when the
// processor is started
//
//*****************************************************************************
extern void _c_int00(void);

//*****************************************************************************
//
// Linker variable that marks the top of the stack.
//
//*****************************************************************************
extern uint32_t __STACK_TOP;

//*****************************************************************************
//
// The vector table. Note that the proper constructs must be placed on this to
// ensure that it ends up at physical address 0x0000.0000 or at the start of
// the program if located at a start address other than 0.
//
//*****************************************************************************
#pragma DATA_SECTION(g_pfnVectors, ".intvecs")
void (* const g_pfnVectors[])(void) =
{
(void (*)(void))((uint32_t)&__STACK_TOP),
// The initial stack pointer
ResetISR, // The reset handler
NmiSR, // The NMI handler
FaultISR, // The hard fault handler
IntDefaultHandler, // The MPU fault handler
IntDefaultHandler, // The bus fault handler
IntDefaultHandler, // The usage fault handler
0, // Reserved
0, // Reserved
0, // Reserved
0, // Reserved
IntDefaultHandler, // SVCall handler
IntDefaultHandler, // Debug monitor handler
0, // Reserved
IntDefaultHandler, // The PendSV handler
IntDefaultHandler, // The SysTick handler
IntDefaultHandler, // GPIO Port A
IntDefaultHandler, // GPIO Port B
IntDefaultHandler, // GPIO Port C
IntDefaultHandler, // GPIO Port D
IntDefaultHandler, // GPIO Port E
IntDefaultHandler, // UART0 Rx and Tx
IntDefaultHandler, // UART1 Rx and Tx

static void
IntDefaultHandler(void)
{
//
// Go into an infinite loop.
//
while(1)
{
}
}

Also look at this app note on how to diagnose software faults which is very useful. 

https://www.ti.com/lit/pdf/spma043

Hi Charles,

Thank you very much for your reply. I checked the size of the .map file and it's 157k, which is smaller than the upper limit of the flash capacity of the chip.

For the continuous operation of IntDefaultHandler, the cause has been found. After the new project is created, the peripheral vector is still the default IntDefaultHandler, so the interrupt immediately enters the IntDefaultHandler loop. I've used the correct function the corresponding for the peripheral vector. After this modification, the compilation error 'Description Resource Path Location Type: unresolved symbol SoftI2CIntClear, first referenced in ./PI2C.obj MBcodesK1 C/C++ Problem', and further debugging and compilation are needed.

Regards,

Katherine