Lpc2000

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> wrote:
>
> On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > ee_gary wrote:
> > >Hello,
> > >
> > >I'm having a problem where my code goes into the bushes after ~10
> > >seconds.  Running it in the simulator results in a "Non-aligned
> > >Access" error, ARM Instruction at 00000200H, Memory Access at
> > >40000241H.  Any idea what that means?  Simple code, just an interrupt
> > >driven timer and interrupt driven SPI…
> >
> 
> What instruction was this accessing?

The instruction at 200H was:
LDR R3,[R1]

It was part of this function:
void wait (void)  {
  unsigned long i;

  i = timeval;
  while ((i + 10) != timeval);
}

where 'timeval' is incremented by an ISR.

> 
> The following things can give you non-aligned accesses:
> 
> 1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
non-2byte 
> boundary. This might raise a data abort.
> 
> 2) Trying to execute an ARM instruction at a non-4-byte location or
a thumb 
> instruction at a non-2-byte location. This might raise a prefetch abort.
> 
> 
> 
> > You can run into this when mixing Thumb with ARM code. When interrupt
> > routines are entered, the processor is in ARM mode, either write your
> > handlers in ARM or switch to THUMB mode, process the interrupt, then
> > exit THUMB mode and return from interrupt.
> 
> Yes, this is possible since thumb addresses are marked by setting
the least 
> significant bit.  If you try executing the address by using a
regular branch 
> or bl then this will break. You need to use a bx.
> 
> >
> > FWIW, Thumb, and thumb-internetworking, is too much trouble to deal
> > with, I run strictly ARM mode.
> 
> To each their own, but I strongly disagree. I use thumb and
interworking a 
> lot. gcc support for this is great.
> 
> I always write all my assembly with interworking (ie using bx)
regardless.

I'm using all ARM code, with the interworking option enabled in the
compiler/linker.

> 
> For an example you might look at the example stuff I posted on the
AT91SAM7 
> group.
>