EmbDev.net

Forum: ARM programming with GCC/GNU tools misalignment access


Author: Alexander Khromykh (xelax)
Posted on:

Rate this post
0 useful
not useful
I move the code from avr to arm. There is a problem: because of
architectures difference there are a lot of pieces into the code
where there is an access to misalignment addresses. ARM goes to data
abort mode.In Data abort interrupt in registers of Memory Controller
(MC)
I can look through the address of the last aborted access, abort size
status and abort type status. In order to finish access in bytes mode
for fullness of information there is lack of address where it is
necessary to write data (misalignment read) and address from where
data were written (misalignment write).

Where can I read these addresses? Is there a simple solution of this
problem?

P.S. at91sam7x256(atmel evalution board) + gcc4.2.1(yagarto)

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Alexander Khromykh wrote:
> I move the code from avr to arm. There is a problem: because of
> architectures difference there are a lot of pieces into the code
> where there is an access to misalignment addresses. ARM goes to data
> abort mode.In Data abort interrupt in registers of Memory Controller
> (MC)
> I can look through the address of the last aborted access, abort size
> status and abort type status. In order to finish access in bytes mode
> for fullness of information there is lack of address where it is
> necessary to write data (misalignment read) and address from where
> data were written (misalignment write).
>
> Where can I read these addresses? Is there a simple solution of this
> problem?
>
> P.S. at91sam7x256(atmel evalution board) + gcc4.2.1(yagarto)

I am not sure what your question is. However to have ported code cause a
data abort it was probably wrong or at least unsafe and non-portable in
the first instance. You might post an example of the code in question so
you we might address the cause rather than the symptom.

Clifford

Author: Jim Kaz (ancaritha)
Posted on:

Rate this post
0 useful
not useful
I had a problem with misalignment when writing to flash using the ARM
when I had no such issue on the AVR.  The AVR is an 8-bit processor, so
any address in range is a valid address to write to, but the ARMs are
32-bit, so when writing/reading to an address it has to be word aligned
(32-bit boundaries/multiples of 4).  If you are running in thumb mode it
must be half-word aligned (16-bit/multiples of 2).

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
Jim Kaz wrote:
> I had a problem with misalignment when writing to flash using the ARM
> when I had no such issue on the AVR.

Ah, that makes more sense. An ARM7 can perform 8 and 32bit addressing in
ARM mode and 8/16 in Thumb mode. I too had a problem once when a
hardware cost-down changed a 32bit data path to external Flash to 16bit.
In my case it was a simple matter of correctly setting the architecture
to ARM9 which has 8/16/32 bit addressing in ARM mode, but it stumped me
for a while - the Flash could not be programmed because the  programming
command sequence was being messed up by 16bit writes being compiled as
two 8 bit writes. I guess if I had not had an ARM9 the solution would
have been to do the Flash programming in Thumb mode.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.