typedef struct TestAbort
OutString("Trying pointer... ");
Trying pointer... 0x13121110 Ok.
Trying pointer... 0x10131211 Ok.
Trying pointer... 0x11101312 Ok.
Trying pointer... 0x12111013 Ok.
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.
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.
Retrieving data ...