stm32: tests: drivers : fix mpu faults by enabling SRAM clocks and configuring MPU regions on stm32h7rsx #97731
Conversation
zephyrbot
added
area: Clock Control
platform: STM32
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
erwango,
etienne-lms,
gautierg-st,
marwaiehm-st,
mathieuchopstm and
nordic-krch
| /* Region 4 */ | ||
| MPU_REGION_ENTRY("SRAM_1", 0x30000000, REGION_RAM_ATTR(REGION_16K)), | ||
|
|
||
| /* Region 5 */ | ||
| MPU_REGION_ENTRY("SRAM_2", 0x30004000, REGION_RAM_ATTR(REGION_16K)), |
There was a problem hiding this comment.
Let's make use of dt attribute zephyr,memory-attr instead
| #if defined(CONFIG_SOC_SERIES_STM32H7RSX) | ||
| LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_AHBSRAM1); | ||
| LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_AHBSRAM2); | ||
| #endif |
There was a problem hiding this comment.
Should ideally depend on RAM activation via dts (activated by default but still)
There was a problem hiding this comment.
Updated with DT macro
| /* Special region */ | ||
| MPU_REGION_ENTRY("SPECIAL_REGION", 0x08fff000, REGION_FLASH_ATTR(REGION_4K)), |
There was a problem hiding this comment.
Should not be inside the XIP condition (this region can be accessed whatever the configuration used)
…tion Adds an MPU region named SPECIAL_REGION at address 0x08FFF800 with a size of 2 KB in Flash memory. The region was previously unprotected, leading to an MPU fault when accessed. By marking it as executable and readable with appropriate flash memory attributes, the test now completes without triggering a fault. This change resolves a data Access Violation observed during multiple tests, where the faulting address was 0x08FFF808. Signed-off-by: Fabrice DJIATSA <[email protected]>
enables the AHB2 peripheral clocks for SRAM1 and SRAM2 on STM32H7RSX series using LL_AHB2_GRP1_EnableClock. These clocks are required to access the corresponding SRAM regions during runtime. Fixes potential access faults when using SRAM1 and SRAM2. Signed-off-by: Fabrice DJIATSA <[email protected]>
adds the `zephyr,memory-attr` property to the SRAM1 and SRAM2 memory nodes to explicitly define their MPU attributes as normal RAM. This ensures proper memory protection and caching behavior when these regions are used by the kernel or application. Resolve a Data Access Violation encountered during test, where the faulting address was 0x30000000. Signed-off-by: Fabrice DJIATSA <[email protected]>
djiatsaf-st
force-pushed
the
ztb_fix_h7rs_issue
branch
from
66d1877 to
8b9ef67
Compare
|
| compatible = "zephyr,memory-region", "mmio-sram"; | ||
| reg = <0x30004000 DT_SIZE_K(16)>; | ||
| zephyr,memory-region = "SRAM2"; | ||
| zephyr,memory-attr = <DT_MEM_ARM(ATTR_MPU_RAM)>; |
There was a problem hiding this comment.
My PR #97364 most likely gets a problem with adding the memory attribute to sram2, because the order of MPU region initialization (see arm_mpu.c):
- elements from
mpu_regions.c - entries from the device tree with
zephyr,memory-attrproperty - entries resulting from
CONFIG_USERSPACE,CONFIG_NOCACHE_MEMORYetc - dynamic entries
As later defined regions overlapping earlier ones have a higher priority (called region overlay), the ATTR_MPU_RAM from dt will overlay the REGION_RAM_NOCACHE_ATTR / REGION_PPB_ATTR from my PR's mpu_regions.c. Never tried to overlay a smaller region with a bigger one, so maybe this is even illegal? Anyway, I need to figure a way to define my DMA memory regions after it is configured as standard memory.
I see the point of this change (and use it in my custom boards dts for other mem nodes), but how can I solve this?
4 participants
This pull request addresses multiple MPU-related faults observed during runtime tests on the
STM32H7RSXseries by introducing the following changes: