Hi all,

I have included both FatFS with MMC card support (Thanks Joel!) and
FreeRTOS in my application and now I keep getting data abort
interrupts...

I have only one interrupt source (uart) and that runs completely
independent of the rtos (no system calls). The compiler is the IAR
embedded workbench. The optimization is set to off.

It appears that without either of the systems the other runs fine...
I can do disk init and mount without problems, but when I try to open
a file using FatFS f_open the exceptions occurs.

The LR register reports the exception to have occurred at different
places inside the kernel - at the end of the vTaskSwitchContext
function (sometimes), in the portRESTORE_CONTEXT function (most of the
time) or in vListInsertEnd function (sometimes).

I have tried to increase both the stack size in the linker file and
increasing the heap for freertos without any changes.

Any suggestions?

Thanks

Thomas Augustinus Start a New Thread

> I have tried to increase both the stack size in the linker file and
> increasing the heap for freertos without any changes.

Quite likely a stack overflow in a task. Increasing the heap size not
effect this - try increasing the size of the stack allocated to the task
when the task is created.

The task stacks are filled with 0xa5 - try watching the memory around that
pointed to by the stack pointer as you call the problematic function to see
if it wipes off the last few 0xa5's. If so then you definitely require more
stack.

Regards,
Richard. Start a New Thread

--- In l..., nospam@... wrote:
>
> > I have tried to increase both the stack size in the linker file and
> > increasing the heap for freertos without any changes.
>
> Quite likely a stack overflow in a task. Increasing the heap size not
> effect this - try increasing the size of the stack allocated to the
task
> when the task is created.
>
> The task stacks are filled with 0xa5 - try watching the memory
around that
> pointed to by the stack pointer as you call the problematic function
to see
> if it wipes off the last few 0xa5's. If so then you definitely
require more
> stack.
>
> Regards,
> Richard.
>

I know from experience that FreeRTOS stack overflows are sometimes
tough to spot without using a debugger or the vTaskList function. How
hard would it be to cause some sort of software interrupt, where you
can increase the task stack space automatically (or spit out an error).
Or what about having a memory manager that could dynamically adjust
the stack during runtime.
Or have a super stack space that all tasks use and the rtos manages
it. I know I waste like 10-50 bytes per task just for safty sake.
OR what about an overflow area. if a stack is going to overflow into
another task, instead it goes into the overflow area, which the rtos
can manage and save an overflowed task? Start a New Thread

Thanks Richard,
Despite that I was sure that I had checked the stacks then that turned
out to be the case anyway... So, thanks for the advice!

Is there an easy way to get hold of the current tasks "top-of-stack"
pointer and stack-size? I think of implementing a simple warning via
the uart if the a5 a few bytes from the top is overwritten...

Regards
Thomas Augustinus Start a New Thread

>Is there an easy way to get hold of the current tasks "top-of-stack"
>pointer and stack-size? I think of implementing a simple warning via
>the uart if the a5 a few bytes from the top is overwritten...

The current task top of stack is just the current stack pointer. The limit
of the stack can be obtained from the TCB for the task - the TCB for the
currently running task is pointed to by pxCurrentTCB. A quick calculation
can be performed to determine the risk of overflow.

The SafeRTOS code base does some cunning things with the stack to trap
overflows.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * Start a New Thread