Lpc2000

I am new to this group and arm processor also.Has anyone ever faces 
the deadly data abort error.I have gone through a length document by 
David Seal but to no good use.Still have problem with data abort.

implemented simple stuff like SUBS PC,LR,#8
adjusts link register by 8 places(considering the pipelined 
architecture)and loading the Program counter with the same.

My data abort occurs at STR  R12,[R14,#RVCT_AicEoicr]

It seems that this has something to do with Base Update Abort Model.

which is the instruction I use to acknowledge the end of interrupt  
at the end of the interrupt subsroutine.

Please let me know if any one as faced this problem before.

Jens

--- In lpc2000@yahoogroups.com, "Jenish" <jenish@g...> wrote:
> 
> I am new to this group and arm processor also.Has anyone ever faces 
> the deadly data abort error.I have gone through a length document 
by 
> David Seal but to no good use.Still have problem with data abort.

A data abort occurs when you try to access a non-existant chunk of 
memory as data.

> 
> implemented simple stuff like SUBS PC,LR,#8
> adjusts link register by 8 places(considering the pipelined 
> architecture)and loading the Program counter with the same.

It does not help to have a data abort handler unless you do something 
to fix up the aborting reason. In "larger" ARM processors you can do 
this by using the MMU (ie. change the MMU to handle the aborting 
address properly). THis is how you do things like grow the stack on 
demand. ie.

1) Attempt to access address xxx. THis fails and causes a data abort.
2) Data abort handler kicks in and maps the appropriate memory to xxx.
3) Same instruction as in (1) is tried again and works this time.

On smaller CPUs like the LPC2xxx with no MMU this makes no sense. If 
you just implement the return then you get.

1) Attempt to access address xxx. THis fails and causes a data abort.
2) Data abort handler does nothing.
3) Same instuction as in (1), fails again because nothing hase been 
changed.
4) Data abort handler does nothing.
Forever...

There are only really two meaningful things to do:

1) If you're running a debugger, then just make an infinite loop

DataAbortHandler: b DataAbortHandler

Now you can detect DataAbortHandlers and find where they happened.

2) Write some exception processing code that outputs the registers 
etc.


> 
> My data abort occurs at STR  R12,[R14,#RVCT_AicEoicr]
> 
> It seems that this has something to do with Base Update Abort Model.
> 
> which is the instruction I use to acknowledge the end of interrupt  
> at the end of the interrupt subsroutine.

The coding of this instruction looks slightly wierd, depending on how 
it was set up. Make sure that (R14+ RVCT_AicEoicr) is a valid address.

> 
> Please let me know if any one as faced this problem before.

Sure. Data aborts happen to everybody :-). It is the ARM's way of 
telling you that you have not set up your pointers properly.

hello ,

thanx for the advice to Micheal and " embeddedjanitor ".I forgot to
put on the group message but my data aborts were sorted out on Friday
and had a rocking weekend followed by that  and my system has not
failed for 48hours (no data aborts).

Base register and negative offset resulted to Base Updated Abort model
and now the base register value is initialized to zero and Offset is
positive so no aborts generated.
Chaio
Jens


On Sun, 31 Oct 2004 21:09:05 -0000, embeddedjanitor
<manningc2@...> wrote:

> 
> --- In lpc2000@yahoogroups.com, "Jenish" <jenish@g...> wrote:
> > 
> > I am new to this group and arm processor also.Has anyone ever faces 
> > the deadly data abort error.I have gone through a length document 
> by 
> > David Seal but to no good use.Still have problem with data abort.
> 
> A data abort occurs when you try to access a non-existant chunk of 
> memory as data.
> 
> > 
> > implemented simple stuff like SUBS PC,LR,#8
> > adjusts link register by 8 places(considering the pipelined 
> > architecture)and loading the Program counter with the same.
> 
> It does not help to have a data abort handler unless you do something 
> to fix up the aborting reason. In "larger" ARM processors you can do 
> this by using the MMU (ie. change the MMU to handle the aborting 
> address properly). THis is how you do things like grow the stack on 
> demand. ie.
> 
> 1) Attempt to access address xxx. THis fails and causes a data abort.
> 2) Data abort handler kicks in and maps the appropriate memory to xxx.
> 3) Same instruction as in (1) is tried again and works this time.
> 
> On smaller CPUs like the LPC2xxx with no MMU this makes no sense. If 
> you just implement the return then you get.
> 
> 1) Attempt to access address xxx. THis fails and causes a data abort.
> 2) Data abort handler does nothing.
> 3) Same instuction as in (1), fails again because nothing hase been 
> changed.
> 4) Data abort handler does nothing.
> Forever...
> 
> There are only really two meaningful things to do:
> 
> 1) If you're running a debugger, then just make an infinite loop
> 
> DataAbortHandler: b DataAbortHandler
> 
> Now you can detect DataAbortHandlers and find where they happened.
> 
> 2) Write some exception processing code that outputs the registers 
> etc.
> 
> 
> > 
> > My data abort occurs at STR  R12,[R14,#RVCT_AicEoicr]
> > 
> > It seems that this has something to do with Base Update Abort Model.
> > 
> > which is the instruction I use to acknowledge the end of interrupt  
> > at the end of the interrupt subsroutine.
> 
> The coding of this instruction looks slightly wierd, depending on how 
> it was set up. Make sure that (R14+ RVCT_AicEoicr) is a valid address.
> 
> > 
> > Please let me know if any one as faced this problem before.
> 
> Sure. Data aborts happen to everybody :-). It is the ARM's way of 
> telling you that you have not set up your pointers properly.
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Sponsor
> 
> ADVERTISEMENT
> 
> 
> ________________________________
> Yahoo! Groups Links
> 
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/lpc2000/
>   
> To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
>   
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.