STM32H723 OctoSPI with APS51208N: Deadlock and Debugger Crash
- February 26, 2026
- 2 replies
- 411 views
Hi everyone,
I am currently facing a very frustrating issue while trying to interface an AP Memory APS51208N (Octal PSRAM) with an STM32H723 via the OctoSPI peripheral.
To avoid reinventing the wheel, I recently refactored my initialization code to use the official ST aps512xx library (https://github.com/STMicroelectronics/stm32-aps512). I'm using read and write latency set to 7.
Unfortunately, the peripheral is still not working properly, and I am experiencing three distinct, highly erratic behaviors:
1. Weird Register Read Pattern When I try to read the memory control registers using the BSP functions, the returned values are incorrect and seem to form a repeating sequence rather than actual register data. Here is what I get for MR0 to MR8:
Array[0] (MR0) = 0x08
Array[1] (MR1) = 0x89
Array[2] (MR2) = 0xDA
Array[3] (MR3) = 0xA0
Array[4] (MR4) = 0x08
Array[5] (MR8) = 0x89
2. OctoSPI Deadlock (Free-running) If I execute the initialization and read sequence continuously (free-running), the OctoSPI peripheral completely locks up. The CPU stalls and gets permanently stuck in an infinite loop inside the OSPI_WaitFlagStateUntilTimeout function during the HAL OCTOSPI receive routine.
3. Debugger Crash (Memory-Mapped Mode) If I slowly step through the code with the debugger to bypass the timeout/deadlock issue, I am able to reach the Memory-Mapped mode activation. However, the exact moment I attempt to access the external memory at address 0x90000000 (either via a Watch window or a simple pointer write in C), the debugger crashes entirely and the AXI bus seems to fault.
What I suspect: It feels like a fundamental protocol mismatch or a timing issue. The memory boots natively in OPI mode, and I suspect the HAL/library might be misaligning the commands (e.g., sending 8-bit STR commands instead of 16-bit DTR) or mishandling the 32-byte Wrap limitation or a wrong use of ST library, causing the bus to stall.
My questions:
Has anyone else encountered these symptoms with the STM32H7 + APS51208N combo?
Did you manage to find a reliable initialization sequence, or do you have a patched version of the ST library that handles the native OPI DTR mode correctly?
Any insights, workarounds, or working code snippets would be massively appreciated.
Attached is the CubeMX file and the "cleaned" file (Application_ticket.c) where I call the ST library functions to perform the initialization.
Thanks in advance!