STM32 LTDC Framebuffer Bandwidth: Traffic and FIFO Underrun

A framebuffer can fit in RAM while an STM32 LTDC display still runs out of pixel data. Capacity answers how many bytes can be stored. Bandwidth describes recurring traffic. FIFO underrun concerns whether the controller receives data before its current reserve empties. A design must address all three.

This analysis covers continuous scanout from a linear, uncompressed framebuffer. Its numbers are teaching assumptions, not panel timings or STM32 performance guarantees. The goal is to build a traffic account and a service-latency investigation before deciding that a memory interface is adequate.

Start with capacity, then put time into the calculation

Assume an 800 x 480 active image stored in RGB565 at two bytes per pixel. A tightly allocated frame requires 800 x 480 x 2 = 768,000 bytes. Two such framebuffers require 1,536,000 bytes. Any actual allocation must also satisfy its layout and memory requirements.

Those figures establish storage, not a transfer rate. The same stored frame can be read repeatedly without changing. Conversely, rendering a replacement frame adds traffic even before the display engine reads it.

TouchGFX 4.27 describes the storage cost and lifecycle of double buffering: one buffer can supply continuous display readout while another is rendered, with a controlled swap.^[2] Two allocated buffers do not mean that LTDC reads two complete images for every refresh.

Buffers store images; layers are configured composition inputs. Multiple active layers can require separate reads. Double buffering one layer changes successive frame locations, not the number of layers read together.

Distinguish frame-average traffic from active consumption

Keep the teaching image at 800 x 480 and assume a 60 Hz refresh. The useful active-pixel payload read across a whole second is:

800 x 480 x 60 x 2 = 46,080,000 bytes/s

That is 46.08 MB/s using decimal megabytes. It is an average over the frame interval, not a guarantee that memory may delay service arbitrarily within that interval.

Now assume total timing dimensions of 1056 x 525, including blanking. The corresponding pixel clock is 1056 x 525 x 60 = 33.264 MHz. Multiplying that clock by two bytes gives 66.528 MB/s as a pixel-clock-based active-consumption screening rate.

ST AN4861, Revision 7, relates pixel clock to total timing dimensions and refresh, and presents a bandwidth screen based on pixel clock and layer storage bytes per pixel. It also discusses competing bus masters and distinguishes FIFO starvation from a transfer error.^[1]

This screening rate describes active pixel cadence, not extra RAM pixels for porches or a constant RAM rate through blanking. Buffered fetches may occur during blanking. Do not add this rate to the frame average.

Real memory fetches can be bursty and buffered. These calculations do not describe the exact refill pattern, transaction overhead, or guaranteed memory service. They help distinguish the volume of useful payload from the rate and timing constraints that supply it.

Add producer traffic once, at the memory being assessed

The display reader is only one participant. CPU rendering, image decoding, DMA2D operations, and buffer copies can create additional reads and writes. Count them at a stated boundary: for example, the external memory that holds both the copy source and destination.

Suppose a complete RGB565 frame is copied 30 times per second. Assume both sides use that counted memory and each payload crosses the boundary once. Each copy then reads 768,000 bytes and writes another 768,000 bytes:

(768,000 read + 768,000 write) x 30 = 46,080,000 bytes/s

Adding that copy to the one-layer frame-average scanout gives 46.08 + 46.08 = 92.16 MB/s. This is an ideal payload subtotal. It excludes other work and transaction costs; caching or intermediate staging can change the traffic at the chosen boundary. Count each read and write once; do not then add the same copy again under a second label such as flush traffic.

Placement changes the account. If the copy source resides elsewhere, its reads may not cross the same memory boundary as the destination writes. Conversely, rendering that reads destination pixels before writing them adds traffic beyond a simple write-only model. Define the operation rather than assigning every GUI update one generic cost.

GUI render modes change the producer side

LVGL 9.5 distinguishes PARTIAL, DIRECT, and FULL rendering. PARTIAL uses smaller draw buffers for changed areas. DIRECT uses full-screen-sized buffers; with two buffers it copies rendered areas to the other buffer after flushing. FULL redraws the entire screen.^[3]

These distinctions belong in the workload account. A mode name alone cannot establish the resulting external-memory traffic. Trace where rendering occurs, what the flush operation copies, and which allocations share the memory under review.

Partial rendering does not stop continuous LTDC scanout. Updating a small button may reduce producer work while the controller continues reading the displayed frame. If an architecture instead uses display-local image memory or another refresh model, it needs a different account from the one used here.

Likewise, double buffering can separate producer and reader ownership without reducing the bytes consumed by a refresh. It may also introduce synchronization copies depending on the framework. Compare actual operations rather than assuming that an extra buffer is a bandwidth optimization.

Average bandwidth cannot protect against every service gap

A FIFO holds a finite reserve. Even if memory delivers enough bytes over a long interval, a period without service can exhaust that reserve during active consumption. This is why an average bandwidth result cannot establish immunity to underrun.

Consider a deliberately idealized model: a 256-byte FIFO starts full, drains at a constant 96 MB/s, and receives no refill for four microseconds. These are fictional parameters for an independent example, not an STM32 FIFO specification or values derived from the earlier RGB565 workload.

Bytes demanded during the gap = 96,000,000 x 0.000004 = 384
Ideal empty time = 256 / 96,000,000 = about 2.6667 microseconds

The gap requires more data than the full assumed reserve holds. Faster service afterward cannot supply pixels whose deadline has already passed. Adequate long-term throughput therefore cannot compensate for every interruption in service. This example demonstrates a latency constraint; it does not prescribe a scheduling limit for any actual LTDC.

A real assessment needs the target FIFO organization, occupancy at the start of a gap, fetch behavior, and memory-service timing. A FIFO that starts partly full has less reserve than this model. Refill during consumption changes the trajectory again. The arithmetic remains useful only when its assumptions stay visible.

Investigate contention with a representative workload

Peak interface rate is not the same as sustained useful delivery to LTDC. The target’s memory timing, transaction pattern, refresh behavior, arbitration, and competing accesses determine the service it receives. Do not insert an assumed efficiency percentage and treat the result as a validated limit.

Build a workload record that separates static scanout from added rendering, copying, and other memory users. Then exercise realistic combinations, including transitions that produce bursts of work. A quiet static screen cannot represent a system that also decodes images and copies updated regions.

Collect the target’s documented status or driver records without assuming that every device exposes the same counter. Confirm that monitoring is enabled and records the events of interest. Follow its documented handling semantics. A period with no recorded underrun is useful evidence for those conditions; it does not prove full panel compatibility or cover every future workload.

Possible changes include reducing unnecessary copies, reconsidering active layers, or revising memory placement and scheduling. Each changes a specific part of the account and must be checked on the target. Refresh changes must remain within the panel’s supported timing; there is no universal safe reduction.

Keep bandwidth separate from other integration faults

Incorrect pixel layout and stale CPU-written data require their own evidence. A bandwidth calculation cannot prove correct cache publication or buffer ownership. Conversely, correcting memory visibility cannot guarantee that a busy memory system meets scanout deadlines.

Use the LCD pixel clock and timing guide for timing context and the LCD display module interfaces guide for interface context. Keep the traffic account tied to the actual continuous-scanout path.

For project-specific review, contact RJY Display with the panel datasheet and timing, MCU, memory topology and clock, bus width, layers and formats, render/copy schedule, fault records, and representative concurrent workload. Those details support a scoped integration discussion; the worked numbers do not establish a compatible board or a guaranteed fix.

References

1. ST AN4861, Revision 7: Creating a graphical application with LTDC; layer discussion in the same application note. February 2026.
2. TouchGFX 4.27: Framebuffer, as read October 22, 2026.
3. LVGL 9.5: Display setup and draw buffers.