STM32H723 OctoSPI with APS51208N: Deadlock and Debugger Crash

[Luca G.]

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!

[TDK]

I assume this is on custom hardware. Is everything done correctly on the layout? Can you show it?

Does the same issue occur if you slow down the clock rate by an order of magnitude?

There are definitely some issues with some STM32H7 devices and some APS memory. Perhaps @Alex - APMemory can weigh in. There is a spreadsheet but it's incredibly hard to find by searching. Ahh, here it is:

Re: H723 - OCTOSPI: device's page size and wrap se... - STMicroelectronics Community

Related:

Memories compatible with QUADSPI, OCTOSPI, HSPI, a... - STMicroelectronics Community

[Luca G.]

Hi,

Thank you so much for the reply! I will definitely go through it right away to verify if my specific STM32H7 and AP Memory combo falls under any known silicon errata or incompatibility.

Regarding the clock rate: I am already running it quite low. Currently (only for debug), the OctoSPI clock is set to around 40 MHz. This should be a very conservative speed and well within the safe margins for signal integrity, which is why this deadlock behavior is so puzzling.

As for the layout, yes, this is a custom board. Let me check what we can share regarding the design.

Thanks again, I'll do these verifications and report back shortly!

About the code are there some fix to do?

Regards

[LCE]

I'm working with that H7 family, but using an Infineon HyperRam at 3.3V in memory mapped mode. Works great, at 100 MHz I get reliable >= 50 MByte/s read & write.

Some basic stuff to check:

- port settings / MUX (register OCTOSPIM) - that is hardware dependent

- timings (recovery, latency, ...), delay block setup

- supply voltage: the APS51208N only works with 1.8V ?

- in case you are in memory mapped mode, I think you have to turn that off before reading registers "manually"

- linker file addresses

- PCB layout: equal trace lengths - though at the current 40 MHz this should not be an issue

I'd go through all OCTOSPI registers, compare to the RAM datasheet.

[giulio_iselqui]

Hello TDK,

Luca, who has started the topic, is developing the firmware on the custom board hosting STM32H723 and APS51208N.

I am in charge of developing the hardware of the same board. I have tried to follow the best practice according the APM_PSRAM OPI x8 BGA PCB Layout Guidelines-Rev 1.2.pdf  document file.

I managed to keep all the tracks going from the BGA to the microcontroller on the TOP layer only (no vias, so no crossing tracks on overlapped layers), I made sure to maintain a solid continous ground plane on the second layer under the top in order to obtain the microstrip single-ended lines, I used tuned length tracks to keep the lenght difference much less than the recommended maximum value.

Please find attached two pictures taken from the layout, the grey color is the groundplane on layer 2, in yellow instead the top overlay. I also uploaded the pinout for the memory BGA chip. 

In case you find any critical point in the layout any feedback would be truly appreciated.

Thank you

Giulio

[AE_APMemory]

Hi @Luca G. ,

The read/write latency should be default value after

Application_ResetMemory() so that you should set read/write latency as 5 in Application_Init():

unsigned int Application_Init(void *memory_ptr)
{
    bool failure = false;
    unsigned int ret_value;
    read_layency_code = APS512XX_READ_LATENCY_5;
    write_layency_code = APS512XX_WRITE_LATENCY_5;

    if (false == Application_ResetMemory())
...

AP Memory - Panda

[Luca G.]

Thanks for the reply.

It seems we've resolved the communication issue. Now I don't remember what the problem was, I'll check. It's been a long time.

Regards