cancel
Showing results for 
Search instead for 
Did you mean: 

APMemory APS12808 OSPI memory connection to STM32H723ZGT6

Maxim357
Associate II

Hello,

I am writing to seek advice on connecting an APMemory APS12808 OSPI memory to the STM32H723ZGT6 microcontroller.

Initially, I attempted to adapt the code from this thread ( https://community.st.com/t5/stm32-mcus-products/stm32h7-octospi-mode-hyperbus-hyperram-access-and-delay-block/td-p/143237/page/2 )  from @Alex - APMemory  to the STM32H723ZGT6. You can find the result in the attached file `main_1.c`. With this configuration, read and write operations do work, but I am encountering issues with data mismatches/corruption.

Subsequently, I tried to enable the Memory Mapped mode based on Application Note AN5050. This is where significant problems began I cannot get this mode to activate. The relevant code is in the attached file `main_2.c`.

My specific questions are:

1. Is there a known working example for enabling the Memory Mapped mode for this type of memory?

2. Why does AN5050 not cover the MR (Mode Register) configuration and memory initialization sequence?

3. Is there any functional difference in which OCTOSPI interface (OCTOSPI1 or OCTOSPI2) is used to connect the memory?

4. Is it acceptable to leave the memory's RESET pin unconnected (floating) if it is not being used?

5. Can I use pins with different Alternate Function (AF) numbers within the same OCTOSPI connection (e.g., for data lines), or must they all belong to the same predefined AF group?

6. There is a dedicated driver available here: ( https://github.com/STMicroelectronics/stm32-aps6408 ). How current and reliable is this driver? Are there any usage examples available?

7. In this thread ( https://community.st.com/t5/stm32-mcus-products/unable-to-read-reset-values-of-the-stm32h730vb-octospim/td-p/212094 ), I read about the OCTOSPIM clock being disabled by default. Is this issue still relevant for the STM32H7 series, and are any specific actions required to ensure proper memory operation?

8. On one of my PCB revisions, the memory's B1 pin is accidentally tied to ground. Is this configuration acceptable, or will it prevent the memory from functioning correctly?

Thank you for your assistance.

Best regards, Max

11 REPLIES 11
KDJEM.1
ST Employee

Hello @Maxim357 and welcome to the community,

 

You can find OSPI_PSRAM_MemoryMapped example in STM32CubeU5. This example based on APS6408L APMemory memory and describes how to write and read data in memory-mapped mode in an OSPI PSRAM memory and compare the result. I recommend you to take a look at this example and get inspired.

There is no functional difference in which OCTOSPI interface connected to the memory, you can use OCTOSPI1 or OCTOSPI2.

For the OCTOSPIM clock, the issue is solved in STM32CubeMX.

    /* Peripheral clock enable */
    __HAL_RCC_OCTOSPIM_CLK_ENABLE();
    __HAL_RCC_OSPI1_CLK_ENABLE();

8. On one of my PCB revisions, the memory's B1 pin is accidentally tied to ground. Is this configuration acceptable, or will it prevent the memory from functioning correctly?

Are you asking about PB1?

Thank you.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Maxim357
Associate II

Hello,
Thank you for your answer.
Thank you, I will make sure to check out that example.
I was referring to the B1 pin on the memory module itself. I have seen
APMemory employees here on the forum; perhaps they can provide some insight.

Screenshot_5.png

KDJEM.1
ST Employee

Hello @Maxim357 ;

 

Could you please share the memory datasheet?

 

Thank you.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Maxim357
Associate II

I have ported the code from the link for the H723 but encountered an error.

When calling the function HAL_OSPI_Receive(Ctx, Value, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) , an error occurs in the file stm32h7xx_hal_ospi.c at the following lines:

  • *((__IO uint8_t *)data_reg) = *hospi->pBuffPtr;

  • hospi->pBuffPtr++;

  • photo_2025-08-28.jpg

I am also attaching the memory datasheet.

 

Thank you.

The disassembly doesn't look viable for sure. Not sure it the core has locked out access, or the pod is not connecting. So not sure stopping or stepping here is productive at this point.

I'd also caution on placing a peripheral watch view, as this tends to interfere with the operation of FIFO and stateful registers. Add some app side dumping or telemetry if possible.

You can inspect RAM based peripheral instance structures.

For Hard Fault situations.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

4. Is it acceptable to leave the memory's RESET pin unconnected (floating) if it is not being used?
      => No issue
8. On one of my PCB revisions, the memory's B1 pin is accidentally tied to ground. Is this configuration acceptable, or will it prevent the memory from functioning correctly?

   => No issue

Alex

Thank you for your answer; it helped me make progress.

The code execution advanced further after I disabled the System Viewer window. However, it now gets stuck while comparing the values of the MR0 and MR8 registers.

Does this information from the debugger indicate a real issue, or could it just be a debugging artifact?

Furthermore, could displaying the MR register values in the Call Stack and Locals windows somehow be influencing their actual values?

Screenshot_42 1.jpg

See below comments

1. Where is the memcpy() of line 249 disassembled?

There should be something like "B 0xXXXXXXXX memcpy" right after the 0x0800065A as in 0x0800064A, then RET.

2. Run until 0x08000658 CMP instruction, so that you know the exact r0 and r1 value

Determine which is regR_MR8[0] and which is regW_MR8[0]. Compare them with those in call stack locals at bottom right.

3. Which is the right value you want? 0x44, 0x3C, or something else?
I saw regR_MR0[0] and regW_MR0[0] are different, maybe the XSPI timing is totally misconfigured?

 

AlexAPMemory_0-1756908093588.png

 

 

Thank you for helping me figure this out.

1. For the first question - pic1.

pic1.jpg

2. For the second question- pic2.

pic2.png

3. MR0 and MR8 values: I took them from the code at this link ([https://github.com/STMicroelectronics/STM32CubeU5/blob/main/Projects/STM32U575I-EV/Examples/OCTOSPI/OSPI_PSRAM_MemoryMapped/Src/main.c]):
`uint8_t regW_MR0[2]={0x24,0x8D};`
`uint8_t regW_MR8[2]={0x0B,0x08};`
The reason I used them is that I couldn't understand how to derive these values based on the memory manual. According to my interpretation of the manual, I got different values: MR0 = `0xC0, 0x01` and MR8 = `0xC0, 0x8D`.