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

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).

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.