TM4C123GH6PZ: Fault Address = 0x2000.8000

May I commend the care, detail, & effort you've devoted to your post?    Very well done.

Now - to the issue - it is assumed (MCU you've listed appears upon LPad) that you're using UART_0 - via an on-board ICDI MCU - might you confirm?

The fact that so many messages arrive safely - and are well processed - (may) shift some blame to your "data-source chain."   (originating device (PC?) and board's ICDI MCU)

Have you tried:

• reducing the baud rate
• reducing the arriving message rate (below the 1000 Hz noted
• determining the (repeating) characteristics of the "fault triggering message"  (i.e. length, presence of repeated or "illegal" characters)   

Is it possible that a "new message" arrives "Prior to full/complete processing" of an earlier message - and that the "overlap" creates (or contributes to) your issue?

Hello CamK

The SRAM being accessed is outside of the 32KB SRAM available on the TM4C123x device. What is the size of SRAM specified in the linker command file of your project?

Hi Amit,

As ~1500 such messages (appear) to be well handled - are you thinking that SRAM gradually fills - and overflows (eventually) into "forbidden zone?"

Hello cb1

That would be on how the memory is being handled by the application. Has a large array been created (possibly pointing to the SRAM size being incorrect) which allows the application to assume a large SRAM. I am first weeding out the usual suspects.

Hello,

Thank you both Amit and cb1 for the insightful comments. I want to give some more relevant information that could help clear up the situation.

- I'm sending messages to the microcontroller on UART0 at 1000Hz. Messages are 7 bytes long. The micro processes the messages and generates 30-40 byte replies for each message. The baud rate for UART0 is set as 115200bps.

- At the same time, I'm also receiving datagram messages (from a gyro) approximately 40 bytes in length on UART2 at a frequency of 1000Hz. The micro processes these messages but doesn't reply to any of them. This is a hard-coded baud rate of 921600bps. I can't change this baud rate.

- When I'm not sending any messages on UART0, the microcontroller handles the communication from the gyro on UART2 just fine. When I start to send messages on UART0 (comm. on UART2 still occurring), I hit the FaultISR somewhere after 1000 messages. If I only send about 1000 messages @1000Hz on UART0, I'm in the clear and there is no fault. If I wait a second and then send another 1000 afterwards, no fault. The number of messages before I hit the fault seems to vary widely from 1250-2000.

- I did notice that if I slow down and send messages on UART0 at 500Hz (instead of 1000Hz), I never hit a faultISR.

- I also tried slowing the baud rate on UART0 down to 9600bps while maintaining 1000Hz message rate and while I no longer generate any faults, my micro doesn't seem to be able to keep up with the messages and some replies from the microcontroller are lost. I need to keep a baud rate of 115200bps on UART0.

- The link files specifies the following
SRAM (RWX) : origin = 0x20000000, length = 0x00008000

So the SRAM does end at 0x2000.8000.

- When bytes are received on either UART0 or UART2, they are put in a ring buffer. Then a task is started. That task creates a buffer and pulls the received bytes from the ring buffer to process. UART0 creates a receive buffer and a transmit buffer, each of size 180. This is because UART0 also handles a wide variety of other messages besides this test case. No other messages on UART0 will ever be at 1000Hz, just this test case status command. UART2 creates a buffer of size 64 for receiving datagrams from the gyro. The data should always fit within this buffer, so that's not an issue.

These don't seem like very large buffers in SRAM. If this is a fault generated because of SRAM "overflow," I'd guess the microcontroller hasn't finished processing the first command when a second command comes in. Then a third command comes in before the first and and second have finished. And so on.

Regards,
CamK

This second response "tops" your first in terms of (needed) detail and clarity - again very well done.

May I suggest that you place a short piece of test code - perhaps as close as 200 bytes or so - above the "Top SRAM location" you believe your buffers to require. Have the code "Halt your process" should this SRAM location be reached. In this manner you should be able to determine, "How, Where & Why" your buffers are (leaking - exceeding their prescribed range.)

Should not one of your "Buffer Design Goals" be the, "Prohibition from exceeding that Buffer's dedicated SRAM range?"   Such enforcement does NOT appear to be (yet) resident - inviting (in time) such SRAM overflow...

Hello Cam

My first thought was when creating a buffer are you releasing the used buffers for the pool. Since slowing down the UART rates seems to arrest the problem (though a doubt remains as to how long before the FaultISR shows up), it may not be the case, but cb1's post does show it to be reasonable to see if a memory leak is there.

Thanks cb1. Just trying to give the appropriate information so your time (and my own!) isn't wasted. I appreciate the responses. 

In terms of creating a check/halt...

	uint8* overflowptr = (uint8*) 0x20007F38;
        uint8 tempRxBuffer[180];
        if (tempRxBuffer >= overflowptr)
        {
            while(1); // halt

        }

Is this the proper way to do it? Would I do the same for each large array declaration?

Regards,

CamK

Believe you've "got the idea" and it was vital that you tested w/ ">=" rather than "=" alone!

I'd locate the overflowptr 10-20 bytes (beyond/above) the "max expected buffer fill location" so that you more quickly can detect such "leakage" & thus identify your issue's cause.

As we "know" (now) that baud rate & message rate impact your issue's occurrence - would it not pay for you to "Raise both" so that the issue occurs sooner & more dramatically?