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.

[Tesla DeLorean]

Does it work if you memcpy() from the PSRAM into Internal RAM repeatedly? Not recommended use case, but more to demonstrated any viability.

The Memory Mapping of the XSPI needs to be seamless and transparent, if it's not, this isn't going to work.

[AQue]

---

@Tesla DeLorean wrote:

Does it work if you memcpy() from the PSRAM into Internal RAM repeatedly?

---

Yes, but only if LTDC/DMA2D is disabled. 

I did a quick test where I moved contents of internal RAM to the PSRAM followed by a compare.  I then cleared the internal RAM and copied from PSRAM into RAM followed by a compare.  I can run that in a repeated loop without issue with one caveat: LTDC/DMA2D must be disabled.  If not, the copy fails.  Seems the DMA is messing up the contents of the PSRAM.

[AQue]

Follow-up: If I disable the LTDC when I update the PSRAM, the framebuffer is functional.  That is, I can write a block of data to the framebuffer in PSRAM, then enable the LTDC and the correct data is displayed.  Seems the combination of having the DMA enabled while making changes to the PSRAM is causing data corruption.

[STOne-32]

Hi @AQue ,

 

Thanks for the follow up , so you mean that DMA2D can not work in parallel ( same time ) as GPDMA when framebuffer is in the External PSRAM. If so , that means a bus conflict at memory level with a priority is given to One controller DMA2D . Inside internal RAM this will not happen .

let us know with more details 

ST1-32

[AQue]

---

@STOne-32 wrote:

... so you mean that DMA2D can not work in parallel ( same time ) as GPDMA when framebuffer is in the External PSRAM.

---

Not exactly.  I am not using GPDMA for anything.  I am only using DMA2D.  Do I need to setup GPDMA?

[STOne-32]

Dear @AQue ,

Thanks for the clarification and sorry for the misunderstanding.  It might be a synchronization issue of the framebuffer usage  . Can you have a look to this application note :

https://www.st.com/resource/en/application_note/an4861-introduction-to-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

Hope it helps ,

STOne-32

[AQue]

Thank you for this application note as I have not seen it before.

This specific section on the 1 KiB boundary I don't see as an issue in this case.  My screen size is 1024x600 in RGB888.  Since the width is 1024, it follows that every line is on a 1 KiB boundary (as well as 64 and 128 byte boundaries as well).  

I will read the entire application note to see what addition information I can learn.  

[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.

[AQue]

It has been months without a response or solution on this issue.