2008-05-07 12:33 PM
2011-05-17 12:53 AM
Hi Friends.
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... :oCode:
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. TudaDocHell2011-05-17 12:53 AM
The str9 should signal a data abort with an unaligned half-word/word access.
What does the asm look like, as that would be the real clue. Cheers sjo2017-06-29 06:31 PM
I think it is the same issue I experienced yesterday.
I want to send 8 bit base SPI communication, but the cube library would not run by my wish.
When the data is over 1 byte, the API of STM32F0 cube library sends 16bit data.
If the buffer points the misaligned memory, the MCU can not access the 16bit data at once.
At this situation, the mcu generates the hard fault by unaligned address access.
So I think the library should check the misaligned address before sending data.
As a result, I think the MCU would not support the misaligned memory access.
I think the optimization level for compilation or manual address alignment of data access would be important for misaligned memory access.
2017-06-30 01:02 AM
A thread from 2008, got to be a record...
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.