Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


tcp_bind data abort

Posted by Nobody/Anonymous on 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.


RE: tcp_bind data abort

Posted by Nobody/Anonymous on 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: http://sourceforge.net/forum/forum.php?thread_id=1597532&forum_id=382005. Maybe this is causing the issue?

RE: tcp_bind data abort

Posted by Nobody/Anonymous on 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!

RE: tcp_bind data abort

Posted by Nobody/Anonymous on 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.

RE: tcp_bind data abort

Posted by Nobody/Anonymous on 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.0 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner