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,