cancel
Showing results for 
Search instead for 
Did you mean: 

External SDRAM Placement (Framebuffer, FrontendHeap)

nonoriri
Associate III

Thank you for reading.

I'm developing a GUI application using TouchGFX on an STM32H750-based board with a 1024 x 768 display using double buffering.

As the UI became more complex, the FrontendHeap instances exceeded 300KB, causing RAM_D1 region insufficiency. To solve this, I implemented the following:

  • Placed FrontendHeap instances in external SDRAM

However, when the bitmap cache was placed in external SDRAM, screen tearing occurred.
My final solution was to allocate only the View instances that are members of FrontendHeap to external SDRAM.
(View instances accounting for more than 80% of the total FrontendHeap instance size)

The resulting SDRAM configuration is:

  • Framebuffer[0]:Bank 0 (TEX=1, C/B/S=1/1/1)
  • Framebuffer[1]:Bank 1 (TEX=1, C/B/S=1/1/1)
  • FrontendHeap views:Bank 2 (TEX=1, C/B/S=1/1/0)
  • Outer and inner Write-Back. Write and read allocate.

Q1: For FrontendHeap views, I set Shareable to 0 since this area isn't accessed simultaneously by CPU and DMA/LTDC. Is this understanding correct? How do you think of my solution?


Q2:
According to AN4861, it's recommended to place framebuffers in different banks for optimal performance (section 5.5.3 "Optimizing the LTDC framebuffer fetching from SDRAM").
Is it correct that the remaining space in the same bank as the framebuffer should not be used for other purposes?


Q3:
To place framebuffers in different banks, I must set TouchGFX's Buffer Location to "By Address" instead of "By Allocation":

  • Start Address: 0xD0000000
  • Start Address 2: 0xD0400000

However, the auto-generated TouchGFXGeneratedHAL.cpp contains:

setFrameBufferStartAddresses((void*)0xD0000000, (void*)0xD0400000, (void*)0);

Does the TouchGFX Simulator ignore the framebuffer addresses and allocate memory separately for simulation?

For Double buffer with "By Allocation" in STM32CubeIDE, shouldn't TouchGFX be modified to use separate sections like "TouchGFX_Framebuffer" and "TouchGFX_Framebuffer2" instead of placing them sequentially?

2 REPLIES 2
GaetanGodart
ST Employee

Hello @nonoriri ,

 

Can you share your linker script please?

Usually it is recommended to keep the framebuffer location to "by allocation".
When running into memory limitations you should rather place your assets in external ram, nor the framebuffer.
Furthermore, it is also recommended to keep the bitmap and texture mapper in internal memory for quicker access because they require a lot of computation.

Can we first try to keep the framebuffer location to "by allocation" and move the assets to external RAM and only then consider MPU configuration?

 

Regards,

Gaetan Godart
Software engineer at ST (TouchGFX)

Dear GaetanGodart,

Thank you for your response and suggestions!

 

Can you share your linker script please?

Here is a portion of my linker script for reference:

MEMORY { RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K SDRAM (xrw) : ORIGIN = 0xD0000000, LENGTH = 16M QSPI (xr) : ORIGIN = 0x90000000, LENGTH = 256M } TouchGFX_Framebuffer 0xD0000000 (NOLOAD) : { *(TouchGFX_Framebuffer) } >SDRAM TouchGFX_Backbuffer 0xD0400000 (NOLOAD) : { *(TouchGFX_Backbuffer) } >SDRAM TouchGFX_FrontendHeapView 0xD0800000 (NOLOAD) : { *(TouchGFX_FrontendHeapView) } >SDRAM

My SDRAM is 16 MB and divided into four banks:

  • Bank 0: 0xD0000000 – 0xD03FFFFF
  • Bank 1: 0xD0400000 – 0xD07FFFFF
  • Bank 2: 0xD0800000 – 0xD0BFFFFF
  • Bank 3: 0xD0C00000 – 0xD0FFFFFF

Usually it is recommended to keep the framebuffer location to "by allocation".

When using "by allocation" for a double framebuffer, both buffers are placed contiguously in Bank 0 (starting at 0xD0000000). My current framebuffer size is 1024 × 768 × 2 bytes.

However, according to AN4861, Section 5.5.3 ("Optimizing the LTDC framebuffer fetching from SDRAM"):

The framebuffer must be placed in an independent bank accessed only by the LTDC. This action reduces the external memory latency and leads to a higher throughput. As a consequence, when the double-framebuffer technique is used, it is recommended to have these buffers in two separate banks.

In my experience, when I placed a bitmap cache (using CacheableContainer) in SDRAM alongside contiguously allocated framebuffers in Bank 0, I observed screen tearing may due to insufficient SDRAM throughput. However, when I placed the framebuffers in separate banks (Bank 0 and Bank 1), the tearing issue disappeared, even with the bitmap cache in SDRAM.

To achieve this separation, I currently have to use "by address" placement for the framebuffers. Do you think there’s a better way to handle this while keeping the double framebuffers in separate banks?

 

Furthermore, it is also recommended to keep the bitmap and texture mapper in internal memory for quicker access because they require a lot of computation.

I currently store assets like bitmaps and fonts in external QSPI Flash. Could you clarify what you mean by "bitmap and texture mapper"? Are these related to the contents stored in the FrontendHeap instance?

 

I’d also like to ask about the FrontendHeap. My FrontendHeap size currently exceeds 350 KB, which is causing a shortage of RAM_D1.

To address this, I moved only the views in the FrontendHeap to external SDRAM.

touchgfx::Partition< CombinedViewTypes, 1 > views;

 

The rest (presenters, transitions, etc.) remain in RAM_D1. This approach has resolved the RAM_D1 shortage issue. What are your thoughts on this? I’ve seen discussions in other community posts about moving the entire FrontendHeap instance to SDRAM, so I believe this partial relocation should be safe, but I’d love to hear your opinion.

Thank you again for your kind and technical support!