Hi all
I'm using an ARM7 on an Olimex dev board (SAM7-EX256), FreeRTOS 6.0 and UIP (on ARM-GCC). The problem is that after a period of time (5 min+) all processes seem to freeze. I've reduced the network task (vuIP_Task) down to a bear minimum in trying to locate the failure, it now just polls the PHY and checks a few timers (no lEMACSend() e.t.c). The failure is down to the xQueueGenericReceive itself, somewhere in this routine every thing stops.
The failure does not appear to be caused by the PHY's interrupt.
Any ideas?

Always first thing to check is for stack overflow. Are you using the stack checking features?

No, not as yet. Do you have any suggestions on the best way to do this?

http://www.freertos.org/Stacks-and-stack-overflow-checking.html

Thanks, but still freezing - the stack overflow functions are never called on failure. After these tests I've allocated a lot more memory to the stack and the problem still happens. I'm now slowly working through the QueueGenericReceive function itself.

Update: This is the last bit of code called before freezing -

//Within xQueueGenericReceive()
..............
/* Update the timeout state to see if it has expired yet. */
if( xTaskCheckForTimeOut( &xTimeOut, &xTicksToWait ) == pdFALSE )
{
............
vTaskPlaceOnEventList( &( pxQueue->xTasksWaitingToReceive ), xTicksToWait );
prvUnlockQueue( pxQueue );
if( !xTaskResumeAll() )
{
HERE ->portYIELD_WITHIN_API();
}
....................
Strange this is that portYIELD_WITHIN_API() is called successfully elsewhere?

The stack overflow checks only check the task stack. The line you are crashing on on calls SWI, which will cause a switch to using the Supervisor stack. Are you setting up a Supervisor stack? Are you setting up an IRQ stack? Both these are normally done from the startup code before main() is called.

Also, the SWI can cause a switch to another task, so you would need to step into the SWI handler to see where the real problem was, it might be that lots of code executes in other tasks before execution continued past the SWI instruction.

Regards.

In fact, the Yagarto main page itself has the following written:

Information

In case you get some linker errors like:

error: no memory region specified for loadable section `.eh_frame'

you must add the following part to your linker script:

. = ALIGN(4);
.eh_frame :
{
     KEEP (*(.eh_frame))
} > ram

The examples you can find at the howto pages was updated too.

Thanks Richard. I haven't touched the supervisor or ISR stacks, I was hoping that that the code was ready to go after I down loaded it for the ARM (v6.0.0) and I'd just have to change the PHY #defs to suit Micrel on the Olimex board. What confuses me a little is that I've written a large block of code for running an interrupt driven biometric scanner (removed at present) and it worked hard and worked well (using FreeRTOS - the same demo). The Ethernet side which is giving me the grief is relatively slow and straight forward in comparison.

Regarding the linking errors, that side seems to be O.K. But I did have to comment out "-fno-dwarf2-cfi-asm" as my compiler (arm-elf-gcc v4.2.2) did not recognise the command. Currently I'm not using Eclipse and the debugging side, just a basic editor (EditPlus) with commands to call the compiler and to load the ARM using OpenOCD and JTag; this all seems to work well.

Update: I've just built and ran up another demo (Demo/lwIP_Demo_Rowley_ARM7), built via the GCC command line. Again it ran for 5-10 minutes then froze. Web page was working, everything, all that was changed was the PHY ID "#define MII_KS8721_ID 0x00221610 "
I assume its nothing to do with OCD programming script?

Just a thought, but some recent GCC versions contain bugs in the ARM/THUMB interworking within interrupts. If this was the cause I would expect it to crash every time and not run for a few minutes first. The easy way to tell is to build everything to ARM mode.

Thanks, tried compiling it in ARM, didn't like it at all, I've kept the Rowley demo going for 3 hours this time, started up another browser on the ARM stats then within 5-10 min the ARM crashed.

I would encourage to create a simple application with basic queue features and then see if it crashes. Try to boil down the problem. Also, check how long it will take for the tick to overflow. Are you sure you are setting correct OS Tick interrupt? Does it clear on MATCH?

Cheers, I've recently downloaded GCC 4.4.2 and FreeRTOS v6.0.3, did the same PHY changes and its been going for days.
Thanks all.