Hi there,
I'm trying to describe the problems I'm facing with configuring dual direct OctoSPI chips on a custom board based on the STM32H7R7I8T.
The setup includes:
ISSI IS66WVO32M8DBLL PSRAM connected to XSPI Port 1.
Macronix MX25UW25645GXDI00 NOR Flash connected to XSPI Port 2, configured in XIP mode via EXTMEM_MANAGER, which works fine during boot.
“Try” is the key word here — because there are many issues.
The PSRAM works fine on its own using a custom driver based on HAL — I'm able to configure it, read its ID, and enter memory-mapped mode. The problems arise when I try to use both memories together (e.g., in a basic TouchGFX setup with assets in Flash and the framebuffer in PSRAM).
When both memories are initialized in the Boot context, everything works fine (no hard faults, I'm able to jump to Application). However, to use the custom PSRAM driver, I also need access to the hxspi1 handle in the Application context (or so I think — feel free to correct me). I’ve tried entering memory-mapped mode in Boot and accessing it in Application just using the XSPI1 base address — but that doesn’t work.
When I enable XSPI1 in the Application context, I get a hard fault at the call to
HAL_XSPIM_Config(&hxspi1, &sXspiManagerCfg, HAL_XSPI_TIMEOUT_DEFAULT_VALUE)
Swapping XSPI ports doesn’t help. Enabling XSPI1 in both Boot and Application contexts doesn’t help either.
The only option that semi-works is enabling the PSRAM via EXTMEM_MANAGER in Boot. I say semi because ST’s implementation doesn’t allow proper configuration of the CONFIG register of this particular chip — it exposes just a single CONFIG address (2 bytes), while EXTMEM_MANAGER only edits a single byte at a time. In this scenario, I can access the memory from the Application context, but the data is garbage because it was never configured properly (obviously).
My most recent attempt was to create an EXTMEM_USER driver for the PSRAM — which turned out to be as painful as expected and also resulted in a hard fault. Some issues I encountered:
extmem_user_driver.c lacks USER CODE protection and gets overwritten every time CubeMX is regenerated.
EXTMEMORY_2 isn’t declared in extmem_manager.c, and any changes to the enum get overwritten.
extmem_list_config[] is initialized with only one item, but later in the code extmem_list_config[1].MemType = EXTMEM_USER is used — which obviously throws an error.
And I won’t even go into the complete lack of proper documentation for EXTMEM_MANAGER.
At this point, I’m completely out of ideas — aside from rewriting the EXTMEM_PSRAM routine entirely for my specific chip, which I’m pretty sure wasn’t the intended workflow. So far, this has been pure frustration, even by ST standards.
What’s even more frustrating is finding year-old posts from users facing the same problems — and this dual memory functionality is one of the key advertised features of the H7R/H7S series for advanced graphical applications.
I'd be truly grateful for any suggestions on how to solve these issues.
Thank you!
Update:
I was able to get extmem_user_driver.c and extmem_manager.c working. I can't really delete the post, but the issues with properly configuring custom PSRAM via EXTMEM_PSRAM — and the lack of adequate documentation for these new features — still remain.
