instruction access violation memory fault - stack corruption on interrupt return?

[comsosysarch]

My K60 code is hanging. Could use some help from anyone with more experience with K60 exception handling and stack usage.

I am using the PK60N512VMD100 on a custom system development board we designed and built.

I am developing the firmware using IAR EWARM-CM.

Almost all C code although I have a wee bit of assembly in one routine.

This is my first project ever using any kind of ARM, or anything that was not 8/16-bit microcontroller. Hence I am almost certain it is programmer error (certainly not the first on this project), but not 100% certain.

I am running from flash using the 50MHz EXTAL (flash clock is divided by 2). Same parts etc as on the tower module.

I have 3 UARTS with all the RX using interrupts and 2/3 of the TX using interrupts (the other TX uses DMA). I have 1 I2S (read-only from ADC) running over another DMA channel - and the DMA channels both have interrupts. I have 1 I2C using an interrupt. So possible total of 2 DMA channels and 6 interrupts if everything were enabled at once.

My UART interrupt handlers have worked fine for a couple months now. One piece of my code does some math on two very large arrays, storing the results in a third array. This has also worked for a couple months now. In fact the whole project was working with all those interfaces running unti just recently.

Recently I made a change to use flash for one of the two input arrays, which has a boatload of constant data. I worked out how to program flash (done before on 8/16-bit world) on the K60, and flush the cache afterward, and it works. I also changed my IAR linker cfg file to prevent the linker from putting code in the upper half where I am keeping my data tables (saves me from switching flash banks just to write the table - I am not using much flash for the size of the device just a ton of RAM).

I tested this mostly without my UARTs connected to anything. Then I went back to develop the middleware for the third UART interface. Doing that turned on the second UART interface as well (the way the system works) and lo and behold I am suddenly getting hard faults.

I have isolated the hard fault to being a memory fault due to instruction access violation occurring somewhere in a pareticular for loop that I spoke of above doing the math on the arrays. Actually, the access violation is obviously not in that loop per se but results from some error intruduced entering and exiting from the UART interrupt handler. All "working" code. And my stack size is set for 2k bytes or apparently about 8x what is actually being used at the time of the fault.

The odd thing is when I trap the memory fault exception and look at the RAM contents just above the stack pointer, I can see the program counter value from when the fault occured... it is the data value written all over my array (something like 0xffffb2dc or some such). This is sitting in register R3 during the for loop execution as it is being loaded each iteration for doing math operations on the arrays.

If I disable that one particular UART so it does not give me any receive data then I never get the memory fault. That is how I have theorized it is the ISR which is responsible. My most likely suspect was originally my assembler code, which runs in the function call prior to the for loop mentioned. But when I entirely remove that from my project by commenting out the call to the assembler file, I still have the exact same error. So it seems unlikely at this point.

I have put some code at the start and end of the UART interrupt handler and used to examine the contents of the stack and verify they are correct going into the ISR and immediately prior to return. I have not seen the error within the high-level code contenxt of the UART interrupt and its call stack.

Anyone ever see anything where the stack contents get corrupted by a hardware push and pop into or out of an interrupt?

I only have a IAR J-Link not the J-Trace. So I can not see the exact sequence of event leading up to the fault step by step, at least I do not know of a way in my limited experience with the ARM tools.

[comsosysarch]

A possible workaround which seems to point towards a flash caching problem was given in this thread...

Accessing the FLASH causing BUS fault

The gist is to disable flash caching.