I worked a lot with ARM920T (from Atmel) in the past and used to deal with misaligned memory access due to bad coding (unaligned structures and data types). However, with STR912FW44, i am running a code with no data abort exception being raised and i can figure out whats happening or if it is some kind of ARM926J architecture characteristic. Take a look.
Code:
typedef struct TestAbort { char a[8]; } TestAbort; TestAbort T; long *ptr; int i; T.a[0]=0x10;T.a[1]=0x11;T.a[2]=0x12;T.a[3]=0x13; T.a[4]=0x14;T.a[5]=0x15;T.a[6]=0x16;T.a[7]=0x17; for(i=0;i<4;i++) { OutString(''Trying pointer... ''); ptr=(long*)&T.a[i]; OutHex(8,*ptr);OutString('' Ok.rn''); } I trapped all exceptions on another part of the code (91x_it.c). Running on the hardware, here are the results... :o
Code:
Trying pointer... 0x13121110 Ok. Trying pointer... 0x10131211 Ok. Trying pointer... 0x11101312 Ok. Trying pointer... 0x12111013 Ok. Ok... the data is not crossing the dword boundary, but where, god damned :-Y, is my favorite data abort exception ? :-? I was expecting to halt the system or so... :| Thanks a lot for your patience. Any comments are very well appreciated. TudaDocHell
The ARM7 and ARM9, and more recently the CM0, have alignment issues. The latter will Hard Fault. This represents an issue for PC C programmers who are used to more liberal policies afforded by the x86 architecture, and makes porting code from these environments a little more challenging. Depending on how well you exercise various code paths this can result in latent failure in the field when just the wrong data arrives at the wrong time.
The compiler can catch some things, but usually gets caught out by casting, especially void or char pointer cast into words, or doubles, etc. The trick in these cases is to memcpy() the data of unknown alignment into a local/auto variable that would, and then access the local copy.
On the CM3/CM4 the alignment faults typically come from LDRH/STRH operations pulling 64-bit int or doubles via a dual register load/store. Frequently this occurs with tightly packed file data structures, or 8-bit binary packets streaming from other devices.
The SPI, and some other peripherals, on the STM32 parts use the width of a read/write operation to determine how many bytes/bits they need to consume or provide.
I seem to recall issues reported on the SPI peripheral related to some *((uint16_t *)ptr) casts of pointers with arbitrary alignment.