tcp_bind data abort

nobody wrote on Saturday, November 11, 2006:


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.


nobody wrote on Saturday, November 11, 2006:

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:  Maybe this is causing the issue?

nobody wrote on Monday, November 13, 2006:

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!

nobody wrote on Tuesday, November 14, 2006:

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.

nobody wrote on Thursday, November 30, 2006:

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.