Hi, I am using the FreeRTOS v4.1.2 GCC version of the lwIP_Demo_Rowley_ARM7 demo in an AT91SAM7X256 based board. I am getting data abort errors within tcp.c (in the tcp_bind function) that crashes the kernel. Has anyone come across this before? Is this a FreeRTOS or an lwIP issue? Thanks in advance. Regards,

Stack issue is the first thing to look at-try increasing the stack of the task that runns tcp.c. Second there was some talk a little while back about a bug in GCC that could potentially cause a problem.  A fix was also noted.  Take a look at this thread: http://sourceforge.net/forum/forum.php?thread_id=1597532&forum_id=382005.  Maybe this is causing the issue?

I am using GCC 4.1.1 with Thumb code so I probably have the stack issue as mentioned in the previous message. I added the following line SUB R0, R0, #8 just before line 150 in portmacro.h (in portable/GCC/ARM7_AT91SAM7S). Is this a final solution to be implemented in the next stable release of FreeRTOS (v4.1.3)? Or is further investigation ongoing? As well, I continue to have data abort issues. It seems to be related to the tcp_active_pcbs variable in line 259 of tcp.c. 259   for(cpcb = tcp_active_pcbs; 260       cpcb != NULL; cpcb = cpcb->next) { 261     if (cpcb->local_port == port) { 262       if (ip_addr_isany(&(cpcb->local_ip)) || 263    ip_addr_isany(ipaddr) || 264    ip_addr_cmp(&(cpcb->local_ip), ipaddr)) { 265   return ERR_USE; Somehow when I add my user task (an interrupt based SPI driver in ARM mode) to FreeRTOS, the tcp_active_pcbs is not NULL initially. Hence the for loop causes a data abort as the cpcb pointer keeps incrementing. This occurs even when I simply add the user task code to the build without even actually creating the task. I am currently looking at the arm-elf-objdump output of the FreeRTOS executible, to see whether the global tcp_active_pcbs variable is being mangled by my user task code during the compile and linking process… What fun!

Sounds a bit hairy – like a linkage problem as you suggest.  I don’t know how lwIP allocates memory, could it be that the malloc heap is not being setup correctly?  Or does it not use a heap in this way. Regards GCC.  I don’t think this change should be in the main FreeRTOS code.  It is a bug in GCC that needs fixing.  My preference is to use the omit-frame-pointers option for now.  How anybody reported the bug? Adding 8 to the stack increases the stack usage quite a lot and only fixes the problem in FreeRTOS.  Any other code you have that uses a system/user stack from within an IRQ will also be effected.  For example the comms stack that I have.

I updated to FreeRTOS 4.1.3 containing the -fomit-frame-pointers flag and now I no longer get any tcp_bind data aborts. I guess that solves this problem. Regards,