ISS66WVH8M8 PSRAM as TouchGFX framebuffer

[AQue]

Working with a custom STM32U5F9ZJT6Q board that has an ISS66WVH8M8 (Octo-SPI 166 MHz 64 Mbit PSRAM) that we would like to use for the framebuffer to a 1024x600 RGB888 LCD.  The RAM sits on the HSPI1.  With that as a reference I was able to configure the PSRAM in memory-mapped mode.  A basic test of filling the RAM a pseudo-random pattern and reading it back convinced me the device is functioning.  However, when I try to use it with DMA2D and LTDC, I just get garbage on the screen.  When I use internal MCU RAM as the framebuffer, the setup shows my TouchGFX screen as expected.

Project is setup in CubeIDE 1.16.0.  TouchGFX Designer 4.24.0 generats the user interface.

I've read the following:

• Section 30 (Hexadeca-SPI interface) of the RM0456 (STM32U5 Series Reference manual).
• AN5050 Application Note on XSPI interface.
• STM32U59xxx STM32U5Axxx Errata sheet.

I can share any setup or memory initialization code if it is helpful. 

I have concerns the RAM might not fully work with the U5.  One item of concern is the setting the memory type.  I used to "AP Memory" (based on someone who had a ISS66WVS4M8 part on a NUCLEO H7 board).  The PSRAM datasheet shows a split between the upper 5 and lower 4 bits of the column address, which sounds like the AP memory mode.  It also shows byte ordering in D1/D0 format like Macronix memory.

I'm not sure where the problem comes from and looking for items to check.

[AQue]

After reading through the application note AN4861, the only item I could think to try was enabling the MMU so I could control the caching of frame buffer memory.  Sadly, it had no appreciable effect.  The U5 also has a GFXMMU, but I was unable to set this up--always resulted in compiler errors.

One other item I tried was slowing down the screen refresh from 60 Hz down to 20 Hz.  The idea is the lower bandwidth needed by the LTDC might unburden writes to the PSRAM.  Sadly, this too had no appreciable effect.

[AQue]

It has been nearly two weeks with no feedback.  Is there anything else I should look at?

[STOne-32]

Dear @AQue ,

Is that possible to have the ISS66WVH8M8  configuration with Our HSPI Controller and the code associated ?

@KDJEM.1  may help .

Thank you.

STOne-32.

[KDJEM.1]

Hello @AQue ,

The IS66WVH8M8 memory is  H–Hyper RAM. For that could please try to use the HyperBus mode.

Thanks to the HyperBus protocol support, several HyperRAM and HyperFlash memories are supported by the STM32 devices. Some memory manufacturers (such as Infineon, Winbond, or ISSI) provide HyperRAM and HyperFlash memories.

I recommend you to take a look at OSPI_RAM_MemoryMapped example and get inspired to configure the HSPI interface with IS66WVH8M8 memory. Note that this example describes how to write and read data in memory-mapped mode in the OSPI HyperRAM memory "IS66WVH8M8BLL-100BLI ISSI" and compare the result in a forever loop.

I hope this help you.

Kaouthar

[AQue]

The IS66WVH8M8 memory is  H–Hyper RAM. For that could please try to use the HyperBus mode.

I made a mistake in copying the memory part name.  I am using a ISS66WVO8M8, the octo-SPI version.  I found this library on the STMicroelectronics Git page which I used as a reference.  That library is for the Hyper RAM part, but seems to work fine with the Octo-SPI part.  When I copied the part number from my notes, I mistakenly used the HyperBus part number.  I could post the modifications I made to the library if it helps.

As stated previously, the memory mapped-mode works fine.  I can read and write to the RAM device without issue.  For testing, I fill the entire device with a pseudo-random pattern, and then read it back.  This is done using a pointer to the memory at 0xA0000000, not calling read/write SPI functions.  Data cache is not enabled.

The problem is only when the LTDC is setup to use this RAM as the frame buffer source and writes are done to the RAM while the LTDC is running.  If the RAM is filled first, and then the LTDC enabled, the image on the screen (generated by the LTDC) is fine.  However, any attempt to write to the RAM while the LTDC is running, and the RAM become corrupted and garbage is displayed from that point forward.  It is the memory-mapped write operations that are the problem, and only when the LTDC is running.