lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] lwip + sam7x = udef exception


From: B B
Subject: RE: [lwip-users] lwip + sam7x = udef exception
Date: 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 should
look at measures to keep my memory usage low on the other tasks ?

regards,
Martin





> Date: Thu, 15 Feb 2007 17:34:49 +0200
> From: address@hidden
> To: address@hidden
> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users



Get connected - Use your Hotmail address to sign into Windows Live Messenger now. Connect now!
reply via email to

[Prev in Thread] Current Thread [Next in Thread]