FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [November 2006 Threads] tcp_bind data abortPosted by Nobody/Anonymous on November 11, 2006 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,
RE: tcp_bind data abortPosted 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 abortPosted 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 abortPosted 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 abortPosted 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.
Regards,
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|