Random Task Crashes in K10 project

[Thad]

I've created a K10 BSP based on the existing K60.  I have an project I'm running on it that does three main things: 1) It starts up sdcard and mfs services.  2) It starts up WiFi services using a RedPine radio. 3) It opens a connection to UART3 and listens for serial data coming over it.  One or two of these tasks seem to work fine on their own, but when I run all three, I experience random task crashes.  One of the tasks will crash but the other two will continue running.  When the task crashes, the debugger will break and stop in dispatch.s in the kernel interrupt handler (_int_kernel_isr).

The crash seems to happen only when one of the tasks makes a function call that generates multiple stack frames, so my suspicion is that I am over-running the stack.  I've increased and played with the stack allocations for each task and even tried consolidated everything into one task.  I've managed to reduce the frequency of the crashes, but they still occur.  I even tried increasing various values in the .lcf linker file without any luck.

My attempt to figure out what exactly is happening is hampered by the development environment not working as expected.  I've recompiled the PSP, BSP, and application with  MQX_KERNEL_LOGGING defined to 1, and I've installed the MQX tools that should allow me to examine the stack etc... but they remain disabled when pause execution the as they would if kernel logging was not turned on.

Does anyone have any suggestions.  Why might the kernel logging / debugging not work as expected?  Any suggestions on why the crash is happening or how I might tackle it?

Thanks,

Thad

[Thad]

OK, a bit more debugging and here is what I see... I am definitely smashing the stack in some way.  I have a function that opens and reads a file with no problems most of the time, but after I've accessed a UART from a different thread or processed a larger than average packet in the wifi thread, the following happens:  I go into that function, and the call stack all looks normal up until I try to read from the file again.  After I come out of the read function, all the calling stack frames been smashed, and the debugger shows that I've my parent frame is address 0x00000000.  Consequently, as soon as try to return from this function, the task crashes.

The weird thing is, whatever is causing this seems to be having a delayed effect.  A particular function that reads files works fine repeatedly.  A different function is called that also seems to work fine.  Then the first function is called, the stack looks fine until the file read() function is called, then the stack is smashed.  Weird.  Normally I would expect that middle function to smash the stack immediately if it was going to cause problems.  There is something about how MQX tasks and their individual stacks work that I am missing.

Anyone have any thoughts on this?

Thad