2026-05-10 11:11 PM - last edited on 2026-05-11 3:23 AM by mƎALLEm
I am working on SDRAM execution using FMC on STM32H563ZI (NUCLEO-H563ZI board) with external SDRAM connected through FMC interface.
Our target is:
We are facing an issue where:
Below are the detailed steps and observations.
Reset_Handler
→ SystemInit()
→ PLL/System clock configuration
→ FMC GPIO configuration
→ FMC SDRAM initialization
→ SDRAM command sequence
→ __main()
→ scatter loading
→ main()
We intentionally moved FMC/SDRAM initialization into SystemInit() so that SDRAM becomes available before scatter loading.
We configured PLL through direct register-level programming.
Configuration:
PLL configuration registers used:
We observed:
However, execution from SDRAM still fails.
We suspect there may be an FMC kernel clock stabilization issue immediately after SYSCLK switching from HSE/HSI to PLL.
All FMC pins are configured through direct register-level configuration (without HAL).
Configured pins include:
GPIO configuration:
GPIO clocks enabled:
FMC clock enabled through RCC->AHB4ENR.
SDRAM configuration:
Timing configuration used:
These values are based on CubeMX-generated settings.
The following sequence is executed:
Refresh rate currently configured approximately around:
683 (based on 90 MHz FMC clock)
MPU region configured for SDRAM:
Observed results:
However:
This suggests SDRAM works during later runtime but may not be stable during early startup/scatter loading.
We suspect one or more of the following:
We request support regarding:
Please let us know if you need:
Thanks & Regards,
2026-05-11 2:16 AM - edited 2026-05-11 2:18 AM
Hello @shashank78Khandve and welcome to the ST community,
I cannot help you in the SDRAM calculation timings and parameter, meanwhile you can refer to this article / example: How to set up the FMC peripheral to interface with the SDRAM IS42S16800F-6BLI from ISSI
Also, I'm wondering how are you connecting an SDRAM to the NUCLEO. You need to take care about the signal integrity aspects as high frequencies are involved. Refer to this article: How to avoid signal integrity issues on the STM32H7R7/S7 and AN4803 "High-speed SI simulations using IBIS and board-level simulations using HyperLynx® SI on STM32 MCUs and MPUs".
For scatter loading, your process seems to be correct. SDRAM and its respective GPIOs need to be initialized before main(), i.e. in SystemInit(). Unfortunately there is no example available on STM32H5 for this scenario but STM32H743, has such implementation in the HAL, especially in system_stm32h7xx.c
You need to look at blocks where DATA_IN_ExtSDRAM is defined.
Meanwhile, the SDRAM region in STM32H5 is in the range of 0xC000 0000 to 0xDFFF FFFF, according the reference manual RM0481:
While, by default, the region is in execute never configuration (XN), according to the programming manual PM0264:
So most probably that's why you are facing a hard fault while executing from SDRAM. You should configure that region to make it executable using the MPU before jumping to the main.
Hope that helps.
2026-05-11 6:46 AM - last edited on 2026-05-11 7:13 AM by mƎALLEm
Hi ST Community, @mƎALLEm ,
I really can’t thank you enough for the help. I was honestly struggling to figure this out on my own, and it was stressing me out. Having you step in and guide me through it means a lot. I’m so glad you’re part of this community I really needed this.
Actually I need some more help on the same topic as I am working on executing code from external SDRAM on STM32H563 using FMC + SDRAM Bank1.
Currently, SDRAM initialization works correctly when everything is initialized from main() using CubeMX generated HAL functions:
- MX_FMC_Init()
- HAL_SDRAM_Init()
- DrvSDRAM_Init()
In this case:
- SDRAM read/write works correctly
- code can be copied to SDRAM using memcpy()
- functions placed in SDRAM section can execute successfully
I am using a scatter file section similar to below:
; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************
LR_IROM1 0x08000000 0x00200000 { ; load region size_region
ER_IROM1 0x08000000 0x00200000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
.ANY (+XO)
}
RW_IRAM1 0x20000000 0x000A0000 { ; RW data
.ANY (+RW +ZI)
}
RW_IRAM3 0xC0000000 0x002C0000 { ; SDRAM 3MB RAM is used as HEAP area
startup_stm32h563xx.o (HEAP)
}
ER_IRAM5 0xC0200000 0x00000200 { ; SDRAM: User Application Code (2 MB)
;.ANY0 (+RW +ZI)
*(.user_app_code)
}
}And code section example:
void SDRAM_LED_Task(void) {
while (count<=10) {
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_0);
HAL_Delay(500);
count++;
}
count=0;
}The problem starts when I try to initialize FMC + SDRAM before main() from SystemInit().
My actual requirement is:
- initialize SDRAM before main()
- move heap/stack into SDRAM
- support scatter loading/runtime sections in SDRAM
- eventually execute application code directly from SDRAM
I tried two approaches inside SystemInit():
1. Calling HAL-based initialization
- HAL_Init()
- SystemClock_Config()
- MX_FMC_Init()
2. Pure register-level initialization
- RCC configuration
- FMC clock enable
- GPIO AF12 configuration
- SDCR/SDTR setup
- SDRAM command sequence
- refresh programming
- MPU configuration
In both cases I am not able to achieve stable SDRAM execution before main().
I already verified that:
- SDRAM command sequence works correctly
- SDRAM works correctly from main()
- MPU executable region configuration is added
- ICACHE invalidation is also attempted
I also replicated the same initialization sequence used internally by HAL for:
- FMC_SDRAM_Init()
- FMC_SDRAM_Timing_Init()
- FMC enable sequence
- SDRAM mode register sequence
But execution from SDRAM before main() is still failing.
I referred to STM32H7 examples and ST forum discussions mentioning that SDRAM should be initialized before main() for scatter loading use-cases, but I could not find any official STM32H5 example demonstrating:
- SDRAM initialization in SystemInit()
- heap/stack relocation to SDRAM
- executing code from SDRAM before main()
Could someone please clarify:
1. What is the correct initialization order on STM32H5 for:
- clocks
- FMC
- GPIO
- MPU
- ICACHE/DCACHE
when SDRAM must be usable before main()?
2. Is it officially supported/recommended to call HAL initialization functions from SystemInit()?
3. Are there any HAL/FMC dependencies on:
- SysTick
- interrupts
- HAL internal state
- cache state
which prevent SDRAM initialization before main()?
4. Is there any official STM32H5 example available for:
- scatter loading to SDRAM
- heap/stack in SDRAM
- executing code from SDRAM
Any guidance would be very helpful.
Also i have attached some files for your reference ..
Again Thank you for the help!!!
Regards,
Shashank k.
2026-05-11 7:06 AM
HI @mƎALLEm ,
I forget to tell the clock configuration i did for this setup, it is as per the below
also i an running the SDRAM on the 45 Mhz and did the confuguration as per below in mxcube ide
please let me know if i am doing it in wrong way or anything more required for the analysis..
Regars,
Shashank K.
2026-05-11 7:10 AM
I've already provided some hints previously and as said I can't really help you in the SDRAM configuration. You need to follow the article I have shared previously.
Meanwhile, you need to disable the eXecute Never (XN) from that region using MPU.
You can inspire from the implementation provided in the X-CUBE-PERF-H7 cube package especially the configuration 10 - D1_SDRAM_Swapped - D1_DTCM : execution from SDRAM and data on DTCM RAM.
The target is STM32H7 but the principle is the same.
Attached the files (the linker file which I change the extension to .txt and the system_stm32h7xx.c) where to look at. The associated application note to that CubePackage is the AN4891 "STM32H72x, STM32H73x, and single-core STM32H74x/75x system architecture and performance".
What I suggest is to start by validating the read/write to the full range of your SDRAM. If all is OK translate that as direct access to the registers in the SystemInit() and don't forget to configure the MPU to disable the XN. Don't use HAL in the SystemInit(). You need just to program in bareMetal there...
Good luck.