Hi all,
I just wanted to finish off this topic, since i found the solution for the
problem.
We were debugging the program, so the application was compiled with -O0.
Apparently though this was the cause for the exceptions we saw. And the
application runs
fine with -O1.
thanks to all who tried to help.
this topic is now closed.
best regards,
Martin.
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: [lwip-users] lwip + sam7x =
udef exceptionDate: Fri, 16 Feb 2007 09:03:29 +0000
Hi, Ok it seems that i have jumped to a conclusion on the stack overflow.Now i
searched the memory area, and started with the end of the memory area, which
triggered meto write the mail below. But now i have found that it just seemed
to have been mirrored there.Because the 0xa5 values also appears from address
0x0020024C to 0x002006BC. Which leaves me still with one question, why do i end
up in the undef_handler.My call stack as i described in an earlier mail seems
weird.But i am running dry of ideas to what could be the cause of this.
regards,Martin
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: RE: [lwip-users] lwip + sam7x =
udef exceptionDate: Fri, 16 Feb 2007 08:46:04 +0000
Hi again Caglar, I am able to see the 0xa5 values, but they appear on a weird
address.On the sam7x256 the SRAM area goes from 0x00200000 to 0x00210000
(64kb). I am no expert on this part, but the values appear from address
0x0021024C to 0x002106BC,which to me indicates that the SRAM has been overshot.
So am I correct in the assumption that, the memory area has been overflown, and
i shouldlook at measures to keep my memory usage low on the other tasks
?regards,Martin
> Date: Thu, 15 Feb 2007 17:34:49 +0200> From: [EMAIL PROTECTED]> To:
> [email protected]> Subject: Re: [lwip-users] lwip + sam7x = udef
> exception> > B B wrote:> >> > Hi Caglar and everyone else :)> > > > I am
> using FreeRTOS v4.1.3 + lwip 1.2.0 + Rowley CrossWorks.> > Hi,> > As I said
> before, I'm using also this configuration and it is working in > a perfect
> harmony for me.> > > > > Upon further investigation, it actually seems to be
> a stack overflow, > > which is> > the root for my problem > > I have
> increased the value for lwipTCP_STACK_SIZE from 600 to 800,> > and now the
> application has run straight for over an hour.> > I think this stack size is
> well suited for most kind of operation. > However, since you are encountering
> a> stack overflow issue, it is strongly probable that there is something >
> wrong with the code. How do you handle ethernet> tasks. Sockets api , raw api
> ? If you can post your ethernet task, then > you may find better support than
> me :)> > > > > I read up on the undef exception handling in the ARM
> archtecture > > reference manual.> > Which says that the instruction pointed
> to by LR is the instruction > > after the instruction that caused> > the
> exception.> > I thought as per the Atmel datasheet that the failing address
> would be > > present in the MC_AASR,> > but the value in LR - offset, doesn't
> match the value in MC_AASR.> > I think there is nothing important to be
> concern of this mis-alingment > error. Since there is a fact like stack
> overflow> you should concentrate on it.> > Can you investigate your stack
> when you face the undef exception. If you > don't see 0xa5 values at the end
> your stack,then you> have a stack problem. If you can't debug your stack, you
> can try > avaliable options in the FreeRtos code.> > Kind Regards,> Caglar
> AKYUZ> > > _______________________________________________> lwip-users
> mailing list> [email protected]>
> http://lists.nongnu.org/mailman/listinfo/lwip-users
Get connected - Use your Hotmail address to sign into Windows Live Messenger
now. Connect now!
Get connected - Use your Hotmail address to sign into Windows Live Messenger
now. Connect now!
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users