• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 3748 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

UARTprintf triggers FaultISR in Buffered Mode

Michael Roussin
Prodigy 50 points


I am running code on the LM4F120H5QR Launchpad Board.  I have just updated one of my programs to run in UART_BUFFERED mode (Originally I was running without the UART_BUFFERED mode configured) 

1) I have initialized UART0 to transmit and receive data.

2) I have predefined UART_BUFFERED under the project predefined symbols

3) I have defined "extern void UARTStdioIntHandler(void)" and "UARTStdioIntHandler" in the vector table in the startup_ccs.c file.

My problem is when I try to run a UARTprintf() statement.  The code will allow me to print two characters, for example UARTprintf("12").  When I try to include more the two charters in the printf string, for example UARTprintf("123"), the debugger will trigger a FaultISR.  When I look at the NVIC Fault Status I get the following:

NVIC_FAULT_STAT    0x00008200    Configurable Fault Status [Memory Mapped]    

I look at the memory address which caused the fault and get the following

NVIC_MM_ADDR    0x02002F94    Memory Management Fault Address [Memory Mapped]   

From looking at the data sheet, this appears to be the location reserved for ROM.

When I step through the program, the fault seems to be triggered when running the following statement in the uartstdio.c file.

MAP_IntDisable(g_ulUARTInt[g_ulPortNum]);

Any help on solving this issue would be greatly appreciated.  I thought I had the UART_BUFFERED code figured out, but there is something I am missing.  Below I have my UART initialization code just in case there is something I missed.  If there is more code that is needed to resolve this issue please let me know.

    /****************************************************
     * UART Configuration
     ***************************************************/
    SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    //Configure UART port for
    //BAUD RATE = 115200
    //Stop bits = 1
    //Parity = None
    UARTConfigSetExpClk(UART0_BASE, SysCtlClockGet(), 115200,
        (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE | UART_CONFIG_PAR_NONE));

    //UARTFIFOLevelSet(UART0_BASE, UART_FIFO_TX4_8, UART_FIFO_RX4_8); //set FIFO level to 8 characters
    UARTFIFOEnable(UART0_BASE); //enable FIFOs

    IntMasterEnable(); //enable processor interrupts
    IntEnable(INT_UART0); //enable the UART interrupt

Thank you for your help,

Mike

  • 0
    Prodigy 50 points

    Sorry, I should add that I have enabled the UART and UARTstdioInit.  THis is further down in the under Main.

    UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT); //enable Receiver interrupts

    UARTStdioInit(0); //tells uartstdio functions to use UART0

    Thanks,
    Mike

  • 0 in reply to Michael Roussin
    Guru 26105 points

    Hi,

    Two steps to be done, order is not important, but needed for your projects based on Cortex micro:

    a) search TI application notes - there is one related to debugging Fault ISR - read it and practice it for this case, since you may be hit by this fault another time.

    b) for this particular case, the stack is to small - increase it up to 2KB (printf routine needs that).

    Petrei

  • 0 in reply to Petrei
    Prodigy 210 points

    To set the stack size, right click on the project name and click on 'properties'. Click on ARM Linker then on Basic Options. There will be a field to enter your system stack size. I had similar issues to yourself so I put 3000. Problem gone.

  • 0 in reply to Petrei
    Prodigy 50 points

    Petrei,

    Thank you for the response.  I will try adjusting the stack size to see if this helps.  I will follow up with the results.  I did find the TI application note regarding debugging the Fault ISR.  It led me to the following memory fault location.  If I recall, this was the area reserved for ROM.

    NVIC_MM_ADDR    0x02002F94    Memory Management Fault Address [Memory Mapped]

    I assume this is related to the issue with the stack size as you stated earlier.

     

    Thank you for the feedback.


    Mike

  • 0 in reply to Michael Roussin
    Prodigy 50 points

    Just an update. 

    I updated the stack size which solved the issue I was having.  I should probably start a new thread, but it goes along with the issue I was having above.  What would be the best way to know if the stack overflows.  I was looking at some of the literature and it looks like you can set a hardware watchpoint to break when the stack overflows, using "__stack" in the location field.

    1) Is this the best way to find a stack overflow issue?

    2) If not, what is the best way so I do not run into this issue again?

    Thanks to all who helped resolve my issue.


    Mike

  • 0 in reply to Michael Roussin
    Prodigy 210 points

    Mike,

    If there is hardware in the chip that can detect this, then I'd like to know as well. I haven't looked at the memory protection unit yet. The classic way to see what the stack growth is, fill the stack area with a known pattern, run your program then have a look where the stack grows to - where the pattern disappears. Or you can put known values in known locations and check them in a timer interrupt. This can give you an early warning of stack growth although it doesn't tell you who is causing the stack to grow that far. Things like recursion, nested interrupts and printf can cause the stack to grow significantly. I'm using C++ at the moment so you have the additional issue of running out of heap as well as stack.

  • 0 in reply to Russell Bull
    TI__Genius 10405 points

    Hi,

    Wanted to add a link to the app note mentioned above:

    http://www.ti.com/lit/an/spma043/spma043.pdf

     

    Excellent reference on the dreaded faultISR() handler. 

     

        Best,

              Rick