Hi, I am trying to use the lwIP demo for the SAM7x and have been getting some strange behavior. I am using FreeRTOS 4.1.3 with GCC 4.1.1 (with the -fomit-frame-pointer flag). I have created two tasks UserTaskA and UserTaskB and added them to the lwIP_Rowley_demo example as shown according to the Webserver URL: Task       State    Priority    Stack   # WEBSvr     R        1           25      1 IDLE       R        0           84      4 lwIP       B        3           338     0 UserTaskA  B        2           62      2 UserTaskB  B        2           68      3 Eth_INT    B        4           297     5 However when I add a simple declaration, static xQueueHandle xWebQueue to main (see below), the WebSvr runs for about 10 page hits and then hangs due to a data abort error within tcp_in.c. Am I missing something? int main() {    static xQueueHandle xWebQueue   //statement added here    prvSetupHardware()    vPIOinitialize()    lwIPinit()    sys_thread_new( … )    vStartUsertasks( … )    vTaskStartScheduler()    return 0 } My goal is to pass the xWebQueue into the spawned webserver and user tasks so that they can communicate. Regards,

Odd.  The static declaration will not use stack space so this is not the problem.  Could it be that the linker script does not correctly define the memory layout of your processor?

WEBSvr looks short on stack too.

Ugh…I simply reduced the max Heap size (in FreeRTOSconfig.h) from 22000 to 15000 and now the WebSvr works correctly. I guess my user tasks and lwIP were using a lot of RAM which was overlapping with the FreeRTOS heap thereby causing the problems. Is there a way to detect this problem during the build or at runtime?  I am using the default linker file atmel-rom.ld that came with the Rowley GCC demo. Regards, Hitaish

I ran in a similar Problem. I have tasks running using UART0 as debug shell und UART1 for communication with another board. I could invoke a command to send a message to the other board for a certain number of times. Now with reducing heap it worked for about 3 times more than before. It would be great to detect something like that easier.