Hard fault caused by unaligned Memory Access on STM32F769 series

[TerryFogg]

Description

SYMPTOM

If you use an STM32F7xx microcontroller with an external SDRAM,
the Cortex-M7 core may unexpectedly run into the hard fault handler because of unaligned access.
This may happen for example, when the frame buffer of an LCD, a RAM filesystem or any other data is
located into the SDRAM address range 0xC0000000 - 0xC03FFFFF (max. 4MB).
The hard fault is executed although the bit UNALIGN_TRP (bit 3) in the CCR register is not enabled.

CAUSE

In general, RAM accesses on Cortex-M7 based devices do not have to be aligned in any way.
The Cortex-M7 core can handle unaligned accesses by hardware.
Usually, variables should be naturally aligned because these accesses are slightly faster than unaligned
accesses.
STM32F7xx devices have the external SDRAM mapped to the address range 0xC0000000 - 0xC03FFFFF (max. 4MB).
According to the ARMv7-M Architecture Reference Manual chapter B3.1 (table B3-1), the area 0xC0000000-0xDFFFFFFF (32MB) is specified as Device Memory Type.
According to chapter A3.2.1, all accesses to Device Memory Types must be naturally aligned.
If they are not, a hard fault will execute no matter if the bit UNALIGN_TRP (bit 3) in the CCR register is
enabled or not.

Motivation and Context

Bitmap_decoder.cpp uses memory in this area to decompress bitmaps.
This area of memory is the start of external SDRAM on the STM32F769I_Discovery.
The SDRAM starts its address is in the same address space as the 4MB designated as device memory.
Unaligned memory access faults were hit.

How Has This Been Tested?

Bitmaps tested before were added to the Resource file which converts them to RGB565 format before
storing them in flash.
This test was performed on byte arrays of 24bit and 8 bit which required this code to be executed.

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dev Containers (changes related with Dev Containers, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).

[josesimoes]

LGTM! Thanks for the fix.