2024-07-25 10:46 AM
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:
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.
2024-07-25 10:59 AM
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.
2024-07-25 12:20 PM
@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.
2024-07-25 12:36 PM
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.
2024-07-25 02:11 PM
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
2024-07-25 02:35 PM
@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?
2024-07-25 03:03 PM
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 :
Hope it helps ,
STOne-32
2024-07-25 03:17 PM
Sounds like a processor Write conflicting with a DMA driven Read, whilst in Memory Mapped mode
2024-07-25 07:31 PM
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.
2024-07-25 07:33 PM
I agree with your assessment. Do you have any ideas as to what I can do to mitigate this conflict?