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.

sprintf with %u hard fault after copying/pasting code

Other Parts Discussed in Thread: TM4C123GH6PM

Microcontroller: TM4C123GH6PM
OS: Windows 8
IDE: CCS 5.5.0.000077

Hello,

I am experiencing an issue where an sprintf call causes a hard fault after I moved the code section to a different function using copy/paste.

A few things that are important to note:
- The code worked fine in its original function and wasn't changed
- sprintf works without %u format parameters (%s is not causing a fault, either)
- I erased the board's flash memory using the LM Flash Utility, but the issue remains

Below is the code. The process jumps into the FaultISR() routine at the FIRST sprintf statement. 

void InitGPS()
{
	// Declare Variables
	uint32_t bufSize = 32;
	uint32_t nmeaChecksum;
	uint32_t loopCnt;
	uint32_t rate;

	char psrfCore[] = "PSRF103,%02u,%02u,%02u,01";
	char psrfWrap[] = "$%s*%x\r\n";

	// Turn on LED while we process 
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, 0x02);

    // Allocate space for buffers
    char* psrfBuffer = malloc(bufSize);
    char* psrfFinal = malloc(bufSize);

    // Disable NMEA messages 0-4 (GGA,GLL,GSA,GSV)
    for(loopCnt = 0; loopCnt < 5; loopCnt++) {

    	if(loopCnt == 4)
    		rate = 5;
    	else
    		rate = 0;

    	// format the core string
        // THIS IS THE INSTRUCTION CAUSING THE HARD FAULT
    	sprintf(psrfBuffer, psrfCore, loopCnt, 0, rate);

    	// get checksum for nmea message
    	nmeaChecksum = NMEAChecksum(psrfBuffer);

    	// format the complete NMEA command string
    	sprintf(psrfFinal, psrfWrap, psrfBuffer, nmeaChecksum);

    	// Debug output to console
    	puts(psrfFinal);

    	SendToGPS(psrfFinal);

    }

    // Clean up heap
    free(psrfBuffer);
    free(psrfFinal);


    SysCtlDelay(2600000);

    // turn led back off
    GPIOPinWrite(GPIO_PORTF_BASE, GPIO_PIN_1, 0x00);

}

I tried to debug the issue following Application Report AN01286 - "Diagnosing Software Faults in Stellaris Microcontrollers", but wasn't able to resolve it.

Here's what I found:
- NVIC_FAULT_STAT is 0x0000.8200, so it's a bus fault.
- The BFARVALID and PRECISERR are set.
- NVIC_FAULT_ADDR is 0x1FFF.FFF8

I understand that NVIC_FAULT_ADDR should be pointing to the address that triggered the fault. But according to the TM4C123GH6PM Datasheet's Memory Map this address is in a "Reserved" space and I don't really know where to go from here.

Any suggestions would be appreciated!

Thanks,
Hans

  • Hans Luther said:
    I am experiencing an issue where an sprintf call causes a hard fault after I moved the code section to a different function using copy/paste.

    Is the stack size for the program sufficient?

    I have seen difficult to diagnose "crashes" if there is insufficient stack space.

    See http://processors.wiki.ti.com/index.php/Stack_issues#Finding_out_static_stack_usage for a technique to find out the worst case stack in a program, so sufficient stack space can be allocated in the CCS project properties for the linker.

    Hans Luther said:
    But according to the TM4C123GH6PM Datasheet's Memory Map this address is in a "Reserved" space and I don't really know where to go from here.

    If all else fails, you can try and single step into the sprintf call to see at what point the hard fault occurs.

  • Thanks for the quick response, Chester.

    It was indeed the stack issue.  I will follow the procedure the to find out the stack usage of my code, but just to test it I increased the stack size from 1KB to 16KB and the fault disappeared.

    I guess this is where it shows that I am a newbie in embedded development :-) Development in most desktop and mobile environments just doesn't require us to worry about the stack size anymore!

    I appreciate your response and pointing me in the right direction -- it saved me hours worth of frustrating debugging.