Implement a workaround for STM32H743VI (Rev. Y) - preventing unexpected memory corruption when reading from AXI SRAM #38933
Description
Is your enhancement proposal related to a problem? Please describe.
I run into unexpected crashes (arm fault diagnosed as bus fault) when running a simple program on my out-of-Zephyr-tree board (OpenMV Cam H7 - STM32H743VI - Rev Y) from PlatformIO.
No problem with the same code but running on a Nucleo-H743ZI (a supported board in Zephyr tree, using STMH743ZI - Rev V).
I created a bug report to investigate this issue with all the details about it.
https://community.platformio.org/t/fw-built-around-zephyr-linking-to-c-static-library-unexpected-crash-at-runtime/23672
My initial understanding was that my static C++ libraries were actually causing the problem, which was partially true because they were intensively reading from AXI SRAM which actually triggers the memory corruption causing the crashes.
The problem is actually well-known and referred in the errata for this particular revision (Rev Y) as:
2.2.9 Reading from AXI SRAM may lead to data read corruption
https://www.st.com/resource/en/errata_sheet/es0392-stm32h742xig-and-stm32h743xig-device-limitations-stmicroelectronics.pdf
Describe the solution you'd like
A simple workaround is also proposed and worked for me.
(*(uint32_t*)0x51008108) = 0x000000001; // Set READ_ISS_OVERRIDE bit in the AXI_TARG7_FN_MOD register
In this case it could be applied in let's say:
https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/arm/st_stm32/stm32h7/soc_m7.c
static int stm32h7_init(const struct device *arg)
Only for the particular Rev. Y which has REV_ID = 0x1003 according to Table 2. Device variants in the Errata PDF
However, I know that for now this particular revision might not be used in any of the supported boards (Nucleo-XXXXX like).
I am also considering pushing my custom board description (OpenMV Cam H7) to the supported boards, in this case it would be necessary to implement the fix somewhere in Zephyr STM32 Hal for compatibility.
Describe alternatives you've considered
There is no real alternatives except avoiding to use AXI SRAM "intensively" (like in multi-threaded context or from heavy-computational library)
By the way AXI SRAM is the default section where every code, symbols, heap, stack memory will be located when using the default linker script. So it's very likely to happen and difficult to understand the root cause of the problem especially when using Zephyr which is supposed to abstract/hide the HW dependencies.
Additional context
By looking specifically for this error I actually found the same patch applied on OpenMV Github repository which makes sense.
https://github.com/openmv/openmv/blob/fb51ee685a83150911c10dd73f09715b5832f8c7/src/hal/cmsis/src/st/system_stm32fxxx.c
#if defined(MCU_SERIES_H7)
/* Change the switch matrix read issuing capability to 1 for the AXI SRAM target (Target 7) */
// See Errata 2.2.9 "Reading from AXI SRAM may lead to data read corruption"
*((__IO uint32_t*)0x51008108) = 0x00000001;
#endif // defined(MCU_SERIES_H7)