Hard fault caused by unaligned Memory Access on STM32F769 series (#2820)

***NO_CI***

Author: TerryFogg

targets/ChibiOS/ST_STM32F769I_DISCOVERY/target_external_memory.c

@@ -69,6 +69,8 @@
 #define SDRAM_SIZE  (16 * 1024 * 1024)
 #define SDRAM_START ((void *)FSMC_Bank5_MAP_BASE)
 
+void SetupDeviceMemoryToEliminateUnalignedAccess();
+
 // SDRAM driver configuration structure.
 static const SDRAMConfig sdram_cfg = {
     .sdcr = (uint32_t)FMC_ColumnBits_Number_8b | FMC_RowBits_Number_12b | FMC_SDMemory_Width_32b |
@@ -92,11 +94,67 @@ static const SDRAMConfig sdram_cfg = {
 
 void Target_ExternalMemoryInit()
 {
+    SetupDeviceMemoryToEliminateUnalignedAccess();
     fsmcSdramInit();
-
-    // FIXME
-    // this swaps SDRAM address to 0x60000000 and makes it L1 cacheable
-    // SYSCFG->MEMRMP |= SYSCFG_MEMRMP_SWP_FMC_0;
-
     fsmcSdramStart(&SDRAMD, &sdram_cfg);
 }
+
+void SetupDeviceMemoryToEliminateUnalignedAccess()
+{
+    // ARM: STM32F7: hard fault caused by unaligned Memory Access
+    // reference https://www.keil.com/support/docs/3777%20%20.htm
+    // 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.
+
+    // Solution recommended by KEIL
+
+#define MPU_REGION_ENABLE              ((uint8_t)0x01U)
+#define MPU_REGION_SIZE_4MB            ((uint8_t)0x15)
+#define MPU_REGION_FULL_ACCESS         ((uint8_t)0x03U)
+#define MPU_ACCESS_NOT_BUFFERABLE      ((uint8_t)0x00U)
+#define MPU_ACCESS_NOT_CACHEABLE       ((uint8_t)0x00U)
+#define MPU_ACCESS_NOT_SHAREABLE       ((uint8_t)0x00U)
+#define MPU_ACCESS_NOT_SHAREABLE       ((uint8_t)0x00U)
+#define MPU_REGION_NUMBER0             ((uint8_t)0x00U)
+#define MPU_TEX_LEVEL1                 ((uint8_t)0x01U)
+#define MPU_INSTRUCTION_ACCESS_DISABLE ((uint8_t)0x01U)
+#define MPU_PRIVILEGED_DEFAULT         ((uint32_t)0x00000004U)
+
+    // Disable the MPU
+    __DMB();
+    SCB->SHCSR &= ~SCB_SHCSR_MEMFAULTENA_Msk;
+    MPU->CTRL = 0;
+
+    // Configure the region
+    MPU->RNR = MPU_REGION_NUMBER0;
+    MPU->RBAR = 0xC0000000;
+    MPU->RASR = (MPU_INSTRUCTION_ACCESS_DISABLE << MPU_RASR_XN_Pos) | (MPU_REGION_FULL_ACCESS << MPU_RASR_AP_Pos) |
+                (MPU_TEX_LEVEL1 << MPU_RASR_TEX_Pos) | (MPU_ACCESS_NOT_SHAREABLE << MPU_RASR_S_Pos) |
+                (MPU_ACCESS_NOT_CACHEABLE << MPU_RASR_C_Pos) | (MPU_ACCESS_NOT_BUFFERABLE << MPU_RASR_B_Pos) |
+                (0x00 << MPU_RASR_SRD_Pos) | (MPU_REGION_SIZE_4MB << MPU_RASR_SIZE_Pos) |
+                (MPU_REGION_ENABLE << MPU_RASR_ENABLE_Pos);
+
+    // Enable the MPU
+    MPU->CTRL = MPU_PRIVILEGED_DEFAULT | MPU_CTRL_ENABLE_Msk;
+    SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk;
+    __DSB();
+    __ISB();
+}