AN4861 STMICROELECTRONICS | Alldatasheet

Document overview

  • Manufacturer or author: Provided By ALLDATASHEET.COM(FREE DATASHEET DOWNLOAD SITE)
  • PDF pages: 91

Technical content

Datasheet sections

  • 1 Display and graphics overview
  • 1.1 Basic graphics concepts
  • 1.2 Display interface standards
  • 1.3 Display interfaces supported by STM32 MCUs
  • 2.1 LCD-TFT display controller on STM32 MCUs
  • 2.2 LTDC availability and graphic portfolio ac ross STM32 families
  • 2.3 LTDC in a smart architecture
  • 2.4 Advantages of using an STM32 LTDC controller
  • 3 LCD-TFT (LTDC) display cont roller description
  • 3.1 Functional description
  • 3.1.1 LTDC clock domains
  • 3.1.2 LTDC reset
  • 3.2 Flexible timings and hardware interface
  • 3.2.1 LCD-TFT pins and signal interface
  • 3.2.2 Fully programmable timings for different display sizes
  • 3.3 Two programmable LTDC layers
  • 3.3.1 Flexible window position and size configuration
  • 3.3.2 Programmable layer: color framebuffer
  • 3.4 Interrupts
  • 3.5 Low-power modes
  • 4 Creating a graphical applicat ion with LTDC
  • 4.1 Determining graphical application requirements
  • 4.2 Checking the display size and color depth compatibility
  • 4.2.1 Framebuffer memory size requirements and location
  • 4.2.2 Checking display compatib ility considering the memory
  • 4.3 STM32 package selection guide

Datasheet sections

  • 7 Supported display panels
  • 8 Frequently asked questions
  • 9 Conclusion
  • 10 Revision history

of graphical user interfaces (GUIs) and to an increase in the required hardware resources. (like memory for graphical primitives or framebuffer) and higher processing performances. requirements, the STM32 MCUs offer a large graphical portfolio. obtain the best graphical performances.

  • STM32F75xxx and STM32F74xxx advanced ARM®-based 32-bit MCUs (RM0385)
  • STM32F76xxx and STM32F77xxx advanced ARM®-based 32-bit MCUs (RM0410)
  • STM32F469xx and STM32F479xx advanced ARM®-based 32-bit MCUs (RM0386)
  • STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 advanced ARM®-based 32-bit MCUs (RM0090)
  • STM32F429/439, STM32F469/479, STM32F7x6, STM32F7x7, STM32F7x8, STM32F7x9 datasheets

Table 1. Applicable products

4.5.2 Optimizing the LTDC framebuffer fetching from external memories

6.2.2 How to check if a specific display size matches the

Table 10. STM32F4x9 with HCLK @ 180 MHz and SDRAM @ 90 MHz Table 11. STM32F7x6, STM32F7x7, STM32F7x 8 and STM32F7x9 with HCLK @ 200 MHz and Table 12. Example of supported display resolutions in specific STM32 hardware configurations . . . 39 Table 13. STM32 packages with LTDC peripheral versus Table 17. STM32 reference boards with embedding LTDC

1 Display and graphics overview

summarizes the display interfaces supported by the STM32 MCUs.

1.1 Basic graphics concepts

and the display technologies. A basic embedded graphic system can be schematized as described in Figure 1. Figure 1. Basic embedded graphic system display controller and a display glass.

  • The microcontroller computes the image to be displayed in the framebuffer, assembling graphical primitives such as icons or images. The CPU performs this operation by running a graphical library software. This process can be accelerated by a dedicated hardware like the DMA2D Chrom-Art Accelerator ®, used by the graphical library. The more often the framebuffer is updated, the more fluent the animations are (animation fps). 06Y 'LVSOD\\ FRQWUROOHU )UDPH EXIIHU 0&8 'LVSOD\\PRGXOH 'LVSOD\\JODVV
  • The framebuffer is a volatile memory used to store pixel data of the image to be displayed. This memory is usually called the graphic RAM (GRAM). The required size of the framebuffer depends on the resolution and color depth of the display. See Section 4.2.1: Framebuffer memory size requirements and location for more information on the required size of the framebuffer. – Double buffering is a technique which uses double framebuffers to avoid displaying what is being written to the framebuffer.
  • The display controller is continuously “refreshing” the display, transferring the framebuffer content to the display glass 60 times per second (60 Hz). The display controller can be embedded either in the display module or in the MCU.
  • The display glass is driven by the display controller and is the responsible to display the image (which is composed of a matrix of pixels). A display is characterized by: – Display size (resolution): is defined by t he number of pixels of the display which is represented by horizontal (pixels number) x vertical (lines number). – Color depth: defines the number of colors in which a pixel can be drawn. It is represented in bits per pixel (bpp). For a color depth of 24 bpp (which can also be represented by RGB888) a pixel can be represented in 16777216 colors. – Refresh rate (in Hz): is the number of times per second that the display panel is refreshed. A display shall be refreshed 60 times per seconds (60 Hz) since lower refresh rate creates bad visual effects. Display module categories The display modules are classified in two main categories, depending on whether they embed or not an internal controller and a GRAM.
  • The first category corresponds to the displays with an on-glass display controller and a GRAM (see Figure 2).
  • The second category corresponds to the displays with an on-glass display with no main controller and that have only a low-level timing controller. To interface with displays without controller nor GRAM the used framebuffer may be located in the MCU's internal SRAM (see Figure 3) or located in an external memory (see Figure 4).

Figure 2. Display module with embedded controller and GRAM

1.2 Display interface standards

organization committed to define and promote interface specifications for mobile devices.

  • Type A: based on Motorola 6800 bus
  • Type B: based on Intel® 8080 bus
  • Type C: based on SPI protocol The MIPI-DBI is used to interface with a display with an integrated graphic RAM (GRAM). The pixel data is updated in the local GRAM of the display. Figure 5 illustrates a MIPI-DBI type A or B display interfacing example.

Figure 5. MIPI-DBI type A or B interface Figure 6 illustrates a MPI-DBI type C display interfacing example. Figure 6. MIPI-DBI type C interface

1.3 Display interfaces supported by STM32 MCUs

  • All STM32 MUCs support the MIPI-DBI type C (SPI) interface
  • All STM32 MCUs with F(S)MC support the MIPI-DBI type A and B interfaces
  • The STM32 MCUs with LTDC support the MIPI-DPI interface
  • The STM32 MCUs embedding a DSI host support the MIPI-DSI interface Table 2 illustrates and summarizes the display interfaces supported by the STM32 microcontrollers.

Table 2. Display interfaces supported by STM32 MCUs

  1. Purple arrows show the pixel data path to the display.
  2. For more information on how to support Motorola 6800 and Intel 8080 with STM32's F(S)MC, refer to the application note

TFT LCD interfacing with the high-density STM32F10xxx FSMC (AN2790).

  1. All other STM32 MCUs with no LTDC peripheral can direct ly drive LCD-TFT panels using FSMC and DMA. Refer to

application note QVGA TFT-LCD direct drive using the STM32F10xx FSMC peripheral (AN3241).

  1. Only the STM32 MCUs indicated in Table 3 embedding a DSI Host can support the DSI interface. Refer to application note

DSI Host on STM32 microcontrollers (AN4860) for more information. Table 2. Display interfaces supported by STM32 MCUs (continued)

2 Overview of LTDC controller and STM32 MCUs

of the STM32 microcontrollers.

2.1 LCD-TFT display co ntroller on STM32 MCUs

neither a controller nor a graphic RAM.

2.2 LTDC availability and gr aphic portfolio across STM32

available graphic portfolio. Table 3. STM32 MCUs embedding an LTDC and their available graphic portfolio

2 M 256 k No 180 90 83 No Yes No

2 M 384 k Yes 180 90 83 No Yes Yes

1 M 320 k Yes 216 100 83 No Yes No

2 M 512 k

  1. The Quad-SPI interface allows interfacing with external memori es in order to extend the size of the application. For more
  2. LTDC fetches graphical data at AHB speed.
  3. Maximum pixel clock value at IO level, refer to Table 10 and Table 11for maximum pixel clock at system level.

Pixel clock (LCD_CLK) form relevant STM32 datasheet.

  1. The integrated MIPI-DSI controller allows easier PCB design with fewer pins, lower EMI (electromagnetic interference) and

lower power consumption. For more details on STM32's MIPI-DSI host refer to application note AN4860.

Overview of LTDC controller and STM32 MCUs graphical portfolio AN4861

2.3 LTDC in a smart architecture

The LTDC is a master on the AHB architecture which performs read access on internal and external memories. The LTDC has two independent layers, each one with its own FIFO enabling more flexibility of the display. The LTDC controller autonomously fetches graphical data at the speed of the AHB bus from the framebuffer. The graphical data is then stored in one of the FIFO internal layers then driven to the display. The system architecture enables that graphics can be built and plotted to the screen without any CPU intervention. The LTDC retrieves the data belonging to an image from the framebuffer, while the Chrom-Art Accelerator ® (DMA2D) is preparing the next images. The LTDC interface is integrated in a smart architecture allowing:

  • LTDC autonomously fetches the graphical data from the framebuffer (can be internal memories such as internal Flash, internal SRAM or external memories such as FMC_SDRAM or Quad-SPI) and drives it to the display.
  • DMA2D as an AHB master can be used to offload the CPU from graphics intensive tasks.
  • LTDC is able to continue displaying graphics even in sleep mode when the CPU is not running.
  • The multi-layer AHB bus architecture improves memories throughput and leads to higher performance. System architecture on STM32F429/439 and STM32F469/479 microcontrollers The system architecture of the STM32F429/439 line and the STM32F469/479 line consists mainly of 32-bit multilayer AHB bus matrix that interconnects ten masters and nine slaves (eight slaves for the STM32F429/F439). The LTDC is one of the ten AHB masters on the AHB busmatrix. The LTDC can autonomously access all the memory slaves on the AHB bus matrix, such as FLASH, SRAM1, SRAM2, SRAM3 FMC or Quad-SPI enabling an efficient data transfer which is ideal for graphical applications. Figure 9 shows the LTDC interconnection in the STM32F429/439 and STM32F469/479 lines systems.

Figure 10. LTDC AHB master in STM32F7x6, STM32F7x7, STM32F7x8 and STM32F7x9

  1. I/D Cache size = 4 Kbyte for STM32F7x6
  2. DTCM RAM size = 64 Kbyte for STM32F7x6
  3. ITCM RAM size = 16 Kbyte for STM32F7x 6, STM32F7x7, STM32F7x8 and STM32F7x9
  4. SRAM1 size = 240 Kbyte for STM32F7x6
  5. SRAM2 size = 16 Kbyte for STM32F7x 6, STM32F7x7, STM32F7x8 and STM32F7x9

2.4 Advantages of using an STM32 LTDC controller

Table 4 summarizes the major advantages of using the STM32’s embedded LTDC interface. Table 4. Advantages of using STM32 MCUs LTDC controller display module with no display controller nor GRAM. pixel clock of up to 83 MHz. SVGA, WVGA, XGA, HD, and others). Programmable layer: color framebuffer). applications such as smartwatches. display driving while the CPU is in SLEEP mode.

3 LCD-TFT (LTDC) display controller description

64 bytes are left, the LTDC fetches the remaining data.

3.1 Functional description

into the RGB interface. The pixel is then displayed on the screen. Figure 11. LTDC Block digram

3.1.1 LTDC clock domains

  • AHB clock domain (HCLK): used to transfer data from the memories to the FIFO layer and the other way around.
  • APB clock domain (PCLK): used to access the configuration and status registers.
  • The pixel clock domain (LCD_CLK): used to generate the LCD-TFT interface signals. The LCD_CLK output should be configured following the panel requirements through the PLL.

3.1.2 LTDC reset

The LTDC is reset by setting the LTDCRST bit in the RCC_APB2RSTR register.

3.2 Flexible timings and hardware interface

drive several monitors with different resolutions and signal polarities.

3.2.1 LCD-TFT pins and signal interface

  • Pixel clock LCD_CLK.
  • Data enable LCD_DE.
  • Synchronization signals (LCD_HSYNC and LCD_VSYNC).
  • Pixel data RGB888. Note: The LTDC controller may support other display technologies if their interface is compatible. The LTDC interface output signals are illustrated in Table 6. Other signals It is usual that display panel interfaces include other signals that are not part of the LTDC signals described in Table 5. These additional signals are required for a display module to be fully functional. The LTDC controller is able to drive only signals described in Table 5. The signals that are not part of the LTDC may be managed using GPIOs and other peripherals and may need specific circuits. The display panels usually embed a backlight unit which requires an additional backlight control circuit and a GPIO. Some display panels need a reset signal and also a serial interface such as I2C or SPI. These interfaces are used in general for the display initialization commands or for the touch panel control. Figure 12 shows a display panel connected to an STM32 MCU using the LTDC interface signals illustrated in Table 5.

Table 5. LTDC interface output signals . considered by the display only on the LCD_CLK rising or falling edge. and acts as line display strobe. acts as a frame update strobe. must be latched to be drawn. use up to 24 data lines (RGB888) as display interface bus.

Figure 12. LTDC signal interface

3.2.2 Fully programmable timing s for different display sizes

Table 3, Table 11 and Table 13. Table 6 summarizes the timings registers supported by the LTDC. Table 6. LTDC timing registers

Figure 15. LTDC fully programmable display resolution with

  1. Only the active display area is shown in this figure.

3.3 Two programmable LTDC layers

enabled, the Layer2 is the top displayed window. result of the blended color of Layer1 and the background. BCBLUE[7:0] is used for the blue value. Figure 16 illustrates the blending of two layers with a background.

Figure 16. Blending two layers with a background

3.3.1 Flexible window positi on and size configuration

the active display area) or only a part of the image frame. where only a portion of the image is displayed while the remaining area is not displayed. Figure 17. Layer window programmable size and position

  1. LTDC_LxWHPCR and LTDC_LxWVPCR are respectively LTDC layer x window horizontal and vertical

position configuration registers where “x” can refer to layer 1 or layer 2.

3.3.2 Programmable layer : color framebuffer

framebuffer and for the pitch. from the FIFO layer at the end of the framebuffer. The line length (in bytes) is configurable in the LTDC_LxCFBLR register. The number of lines (in bytes) is configurable in the LTDC_LxCFBLNR register. bytes. It is configured in the LTDC_LxCFBLR register. configured with up to eight programmable input color formats per layer. Figure 18 illustrates the pixel data mapping versus the selected input color format. Figure 18. Pixel data mapping versus color format

AN4861 LCD-TFT (LTDC) display controller description

3.4 Interrupts

The LTDC peripheral supports two global interrupts:

  • LTDC global interrupt.
  • LTDC global error interrupt. Each global interrupt is connected to two LTDC interrupts (logically disjointed) that can be masked separately through a specific register. Table 7 summarizes all of the related interrupts and all the particular cases when each interrupt is generated.

3.5 Low-power modes

The STM32 power state has a direct effect on the LTDC peripheral. While in sleep mode, the LTDC is not affected and it keeps driving graphical data to the screen. While in the standby and the stop mode, the LTDC is disabled and no output is driven through its parallel interface. Exiting the standby mode should be followed with the LTDC reconfiguration. It is possible to drive a display panel in sleep mode while the CPU is stopped thanks to the smart architecture embedded in the STM32 microcontrollers which allows all the peripherals to be enabled even in sleep mode. This feature fits wearable applications where the low- power consumption is a must. The LTDC as an AHB master may continue fetching data from FMC_SDRAM or Quad-SPI (when the memory-mapped mode is used) even after entering the MCU in SLEEP mode. A line event or register reload interrupt can be generated to wake up the STM32 when a defined line on the screen is reached or when the shadow reload occurs. More information on reducing power consumption is available on Section 5. Table 8 summarizes the LTDC's state versus the STM32's low-power modes. Table 7. LTDC interrupts summary

Description

underrun(1) 1. FIFO underrun interrupt is useful for deter mining the display size compatibility (see Section 4.2.2: Checking display compatibility considering the memory bandwidth requirements). FUIF FUIE CFUIF Generated when a pixel is requested while the FIFO is empty Transfer error TERRIF TERRIE CTERRIF Generated when bus error occurs

Table 8. LTDC peripheral state versus STM32 low-power modes

AN4861 Creating a graphical application with LTDC

4 Creating a graphical application with LTDC

This section illustrates the different steps required before and during a graphical application development using LTDC. The user should at first determine the graphical application requirements, then check if the desired display size fits the hardware configuration. During the graphical application compatibility check phase, the user can use the existing STM32 reference boards described in Table 17 to evaluate his hardware and software configuration.

4.1 Determining graphical application requirements

Determining the graphical application needs is a crucial step to start from. Some of the most important parameters to be defined before starting the creation of the graphical application are: display resolution, color depth, as well as the nature of the data to display (static images, text or animation). Once the basic parameters mentioned above are defined, the user should determine the graphical hardware architecture of the application as well as the required hardware resources. The user should select the best-fitting STM32 package (see Table 13) according to the following parameters:

  • If an external memory is needed for the framebuffer
  • The external framebuffer memory bus width
  • The LTDC interface: RGB565, RGB666 or RGB888 depending on the display module
  • If an external memory is needed to store graphic primitives (QSPI or FMC_NOR)

4.2 Checking the di splay size and color depth compatibility

with the hardware configuration When starting a graphic application development using a STM32 microcontroller, the user usually has a defined desired display size and color depth. A key question that the user must answer before continuing the development is if such display size and color depth match a specific hardware configuration?. In order to answer this question, the user should follow below steps: 1. Determine the required framebuffer size and its location. 2. Check the compatibility of the display versus the framebuffer memory bandwidth requirements. 3. Check the compatibility of the di splay panel interface with the LTDC.

4.2.1 Framebuffer memory si ze requirements and location

Determining the framebuffer memory size and its location is a key parameter for the display compatibility check. The memory space required in the RAM to support the framebuffer should be contiguous and with a minimum size equal to: Framebuffer size = number of pixels x bits per pixel

resolution and on its color depth. depth. For instance, an RGB888 display can be driven using an RGB565 framebuffer. image while the second buffer used to prepare the next image. SDRAM/SRAM connected to the FMC. any bandwidth limitation issues for the LTDC. Table 9. Framebuffer size for different screen resolutions

  1. The required framebuffer size is doubled for double framebuffer configuration.
  2. An example of a custom 480 x 272 display is the ROCKTECH embedded on the STM32F746 discovery kit

AN4861 Creating a graphical application with LTDC Using the internal SRAM instead of an external SRAM or SDRAM has many advantages:

  • Provides a higher throughput (0 wait state access).
  • Reduces the number of required pins and the PCB design complexity.
  • Reduces the BOM, hence the cost, since no external memory is needed. The only limitation when using the internal SRAM is its limited size (hundreds of Kilobytes). When the framebuffer size exceeds the available memory, the external SDRAM or SRAM (driven by the FMC interface) should be used. However, when dealing with external memories, the user must be careful to avoid bandwidth limitation. For more detailed information refer to Section 4.5: Graphic performance optimization. Note: The color look-up table CLUT can be used to decrease the required framebuffer size. (For more details refer to the relevant STM32 MCU reference manual).

4.2.2 Checking display compatib ility considering the memory

The scope of this section is to explain how to check a display compatibility considering the framebuffer memory bandwidth. For that, this section describes some important bandwidth aspects and explains how to determine the required bandwidth for the pixel clock and the LTDC. Finally, this section shows a simple method that allows to conclude whether a desired display size is compatible with a specific hardware configuration. Framebuffer memory bandwidth aspects Once that the framebuffer location is fixed (either in internal or external memory), the user should check if its bandwidth can sustain the hardware configuration. In order to check if the memory bandwidth can sustain the LTDC required bandwidth, the user must consider any other concurrent accesses to the memory. In general, a small size framebuffer located in the internal RAM does not require a high bandwidth. This is because a small size framebuffer means low pixel clock, hence low LTDC required bandwidth. A more complex use case to analyze is when the framebuffer is located in an external memory (SDRAM or SRAM). Framebuffer memory bus concurrency

  • LTDC, DMA2D and CPU masters In a typical graphic application where an external SDRAM or SRAM memory is used as framebuffer, two or three main AHB masters concurrently use the same memory. The DMA2D (or the CPU) updates the next image to be displayed while the LTDC fetches and displays the actual image. The memory bus load depends mainly on the LTDC required bandwidth.
  • Other AHB masters It is common that an external SDRAM or SRAM memory is shared by other masters and not only by those used for graphics. This concurrency leads to heavy bus load and may impact the graphic performances. Figure 21 shows all the AHB masters with concurrent access to the SDRAM.

Figure 21. AHB masters concurrent access to SDRAM width. For SDRAM, the user can use a 8-bit, 16-bit or 32-bit configuration. computed pixel clock should respect the display’s specifications.

AN4861 Creating a graphical application with LTDC The pixel clock for a specific refresh rate calculated with the following formula: LCD_CLK (MHz) = total screen size x refresh rate Where total screen size = total width x total height. LTDC required bandwidth The LTDC required bandwidth depends mainly on three factors:

  • The number of used LTDC layers
  • The LTDC layer color depth
  • The pixel clock (depends on the resolution of the display panel and on the refresh rate) The maximum required bandwidth can be calculated as described below:
  • If only one LTDC layer is used – LTDC required bandwidth = LCD_CLK x BppL1
  • If two LTDC layers are used – LTDC required bandwidth = LCD_CLK x (BppL1 + BppL2) Where BppL1 and BppL2 are respectively the color depth for LTDC Layer1 and Layer2. The LTDC required bandwidth should not exceed the memory's available bandwidth, otherwise, display problems will occur and the FIFO underrun flag will be set (if the FIFO underrun interrupt was enabled). Note: If the memory used to store the framebuffer is also used for other application purposes, it may impact the graphical performances of the system. Check if the used display resolution fits the hardware configuration The general method for checking whether a display size with a particular color depth is compatible with memory bandwidth is: 1. Compute the pixel clock according to the display size or extract it from the display’s datasheet. 2. Check if the display’s pixel clock does not exceed the maximum system's supported pixel clock described in Table 10 or Table 11. The user should use the following parameters to extract from Table 10 or Table 11 the maximum supported pixel clock corresponding to the used hardware configuration: a) Number of used LTDC layers. b) The used system’s clock speed HCLK and framebuffer memory speed. c) External framebuf fer memory bus width. d) Number of AHB masters accessing concurrently to external framebuffer memory. 3. The user should perform some tests to confirm the hardware compatibility with the desired display size and color depth. In order to do it, the user should monitor the LTDC FIFO underrun interrupt flag in the LTDC_ISR register. If the FIFO underrun interrupt flag is always reset then the user confirms that the desired display size is compatible with the hardware configuration. If the FIFO underrun flag is set, the user should check the following points: a) Verify if he extracted, from Table 10 or Table 11, the correct maximum pixel clock corresponding to the right hardware (for example the user is working with a 16-bit
  • For the STM32F4x9 line the system clock HCLK is running @ 180 MHz and the SDRAM is @ 90 MHz.
  • For the STM32F7x6, STM32F7x7, STM32F7x8 and STM32F7x9 lines the system clock HCLK is running @ 200 MHz and the SDRAM is @ 100 MHz.
  • One or two AHB masters concurrent access to SDRAM (LTDC or LTDC+DMA2D).
  • The SDRAM bus width is 16-bit or 32-bit.
  • Either only one LTDC layer or two layers are used.
  • The LTDC layer color depth is 8 bpp, 16 bpp, 24 bpp or 32 bpp.
  • For the STM32F4x9 line the system clock HCLK is running @ 180 MHz and the SDRAM is @ 90 MHz.
  • For the STM32F7x6, STM32F7x7, STM32F7x8 and STM32F7x9 lines the system clock HCLK is running @ 200 MHz and the SDRAM is @ 100 MHz.
  • Only one LTDC layer used.
  • Two AHB masters concurrent access to the SDRAM (LTDC + DMA2D).

Table 11. STM32F7x6, STM32F7x7, STM32F7x8 and STM32F7x9 with HCLK @ 200 MHz and

4.2.3 Check the compatibil ity of the display panel interface with the LTDC

factors to consider when choosing the LCD panel are the resolution and the color depth.

  • The required GPIO number.
  • The framebuffer size and location.
  • The pixel clock of the display.

Table 12. Example of supported display resolutions in specific STM32 hardware

  1. VESA (video electronics standar ds association) is a technical standards organization for computer display

standards providing display monitor timing (DMT) standards.

  1. CVT R.B: coordinated video timings reduced blanking standard by VESA.
  2. CEA = consumer electronics association.
  3. Up to 8 bpp for the STM32F4x9 microcontrollers
  • Ensure that the display interface is compatible with the LTDC (parallel RGB with control signals).
  • Check if the control signals can be controlled by the LTDC (additional GPIOs are sometimes needed).
  • Ensure that the display signal levels are matching the LTDC interface signal levels (VDD from 1.8 V to 3.6 V).
  • Ensure that the display’s pixel clock is supported by the LTDC maximum pixel clock defined in ithe relevant STM32 microcontroller datasheet.
  • Verify that the display timings parameters are supported by the LTDC timings (see Table 6: LTDC timing registers).
  • Check that the display’s size and color depth are supported by the LTDC (refer to Section 4.2.2: Checking display compatibility considering the memory bandwidth requirements).

4.3 STM32 package selection guide

  • Whether an external memory is needed and which is the bus width.
  • Which LTDC configuration to use: RGB565, RGB666 or RGB888. When selecting the STM32 package, the user has to consider the RGB interfaces availability and the application requirements in terms of GPIOs number. The user must refer to the STM32 relevant datasheet to get the available packages with GPIOs. An easy way to check if the STM32 package in which the user is interested matches the application needs in term of GPIO number, is to use STM32CubeMX (the pinout tab). Table 13 summarizes the available packages and RGB interface of STM32 MCUs embedding an LTDC.

4.4 LTDC synchronization with DMA2D and CPU

4.4.1 DMA2D usage

memories. It is recommended to use the DMA2D in order to offload the CPU.

  • Fill a rectangular shape with a unique color.
  • Copy a frame or a rectangular part of a frame from a memory to another.
  • Convert the pixel format of a frame or a rectangular part of a frame while transferring it from one memory to another memory.
  • Blend two images with different sizes and pixel format and store the resulting image in one resulting memory. STM32F7x8(2) NA NA NA NA NA NA NA NA NA NA 24 STM32F7x9(2) NA NA NA NA NA 24 24 24 NA NA 24 1. Gray cells with “NA” = the package is not available for that specific product. Cells with “18” value = only RGB565 and RGB666 parallel outputs are supported. Cells with “24” value = all of RGB565, RGB666 and RGB888 outputs are supported. 2. The integrated MIPI-DSI controller allows easier PC B design with fewer pins, for more details on STM32's MIPI-DSI host refer to application note AN4860.

4.4.2 LTDC and DMA2 D/CPU synchronization

commonly used to avoid displaying the framebuffer calculation on the screen. workflow of these two masters (LTDC and either CPU or DMA2D). the end of the actual frame display and that the two buffers should be flipped. Figure 23. Double buffering: synchronizing LTDC with DMA2D or CPU

  • Program the line interruption with the value of the last screen line, the interrupt handler should flip the framebuffers and start the next framebuffer calculation.
  • Program the shadow reload register (LTDC_SRCR) to Vertical blanking reload to change the LTDC framebuffer address on the VSYNC period and Poll on VSYNC bit of the LTDC_CDSR register to unblock the DMA2D.

4.5 Graphic performance optimization

4.5.1 Memory allocation

when using the internal SRAM memory split into two or more slaves. an additional system bus bandwidth.

graphics for the framebuffer while the SRAM1 is used by the CPU. Figure 24. Example of taking advantage from memory slaves split

4.5.2 Optimizing the LTDC framebuf fer fetching from external memories

burst read into single accesses, which can heavily affect the graphical performances. crosses the Kilobyte boundary which splits the burst read into single accesses. SDRAM, which leads to an underrun.

  • Reduce the layer window and the framebuffer line widths.
  • Add a number of dummy bytes at the end of every line of pixels to match the closest frame line width multiple of 64 bytes. 06Y9 &RUWH[0 /&' 7)7 '0$ 65$0 65$0 )/$6+ ELW%XV0DWUL[ 65$0 ,%XV '%XV 6%XV .%&&0 'DWD5$0 &KURP $57 '0$' $57 /7'&IHWFKLQJWKHIUDPHEXIIHUIURP65$0RU65$0 0DVWHU 6ODYH %XVPXOWLSOH[HU

the line width size is equal to 1440 bytes which is not a multiple of 64 bytes. the read operation into single accesses. The Figure 25 illustrates the kilobyte boundary cross problem for the given example. Figure 25. Burst access crossing the kilobyte boundary

  • Reduce the layer window and the framebuffer line widths: use the LTDC layer windowing feature by reducing the window size to match the closest frame line width multiple of 64 bytes. Since the window width is reduced, the framebuffer size should also be reduced since the extra 22 and 23 bursts for all frame lines are not fetched nor displayed by LTDC. This method solves the 1 Kbyte boundary crossing issue with a slight window width decrease (see Figure 26). The code below is based on the HAL drivers and shows an example of setting the pitch as described in Figure 26: /* Setting the Layer1 window to 448x272 at positions X = 16 and Y = 0 */ pLayerCfg.WindowX0 = 16; pLayerCfg.WindowX1 = 464; pLayerCfg.WindowY0 = 0; pLayerCfg.WindowY1 = 272; 06Y9 E\\WHVEXUVW )UDPHOLQH )UDPHOLQH SL[HOVSLWFK 3LWFK OLQHZLGWK [E\\WHV « )UDPHOLQH « « $FWLYHGLVSOD\\DUHD[ :LQGRZVWDUW :LQGRZVWDUW :LQGRZVWDUW :LQGRZHQG ; [ E\\WHVEXUVW )LUVW.%\\WH 6HFRQG.%\\WH 6HFRQG.%\\WH 7KLUG.%\\WH &URVVLQJWKH.%\\WHERXQGDU\\

Figure 26. Reducing layer window and framebuffer line widths

  • Add a number of dummy bytes at the end of every line of pixels to match the closest frame line width multiple of 64 bytes. This can be done using the LTDC layer pitch (see Section 3.3: Two programmable LTDC layers). To do this, the user must consider the two points below: – The framebuffer should contain the dummy bytes (as described in Figure 27): when writing data into the framebuffer, it can be done by programming an output 06Y9 E\\WHVEXUVW$FWLYHGLVSOD\\DUHD[ ; )LUVW.%\\WH 6HFRQG.%\\WH «)UDPHOLQH )UDPHOLQH SL[HOV SLWFK 3LWFK OLQHZLGWK [E\\WHV 6HFRQG.%\\WH SL[HOVDFWLYHZLGWK 7KLUG.%\\WH «)UDPHOLQH « « :LQGRZVWDUW :LQGRZVWDUW :LQGRZHQG :LQGRZVWDUW

Creating a graphical application with LTDC AN4861 offset of the DMA2D equal to the difference between the closest burst multiple and the actual line length data size. – The LTDC line length should always be equ al to the active data size, but, the LTDC pitch should be programmed with the value of the closest bytes number multiple of 64 bytes. The HAL_LTDC_SetPitch function provided under the hal_ltdc driver can be used to program the desired pitch value in number of pixels. For the previous example, the value of the pitch to pass to this function should be equal to 512 (512 is the number of pixels per line corresponding to a line length size of 1536 bytes which is multiple of 64 bytes). The code below is based on the HAL drivers and shows an example of setting the pitch as described in Figure 27: /* Setting the Layer1 window to 480x272 at positions X = 0 and Y = 0 */ pLayerCfg.WindowX0 = 0; pLayerCfg.WindowX1 = 480; pLayerCfg.WindowY0 = 0; pLayerCfg.WindowY1 = 272; pLayerCfg.PixelFormat = LTDC_PIXEL_FORMAT_RGB888; pLayerCfg.Alpha = 255; pLayerCfg.Alpha0 = 0; pLayerCfg.BlendingFactor1 = LTDC_BLENDING_FACTOR1_PAxCA; pLayerCfg.BlendingFactor2 = LTDC_BLENDING_FACTOR1_PAxCA; /* Framebuffer start address: LTDC fetches the image directly from internal Flash the real image width is 480 pixels but additional 32 pixels are added to each line to get a 512 pixels pitch. Only the 480 pixels width is displayed*/ pLayerCfg.FBStartAdress = (uint32_t)&image_data_Image_RGB888_512x272; pLayerCfg.ImageWidth = 480; pLayerCfg.ImageHeight = 272; pLayerCfg.Backcolor.Blue = 0; pLayerCfg.Backcolor.Green = 0; pLayerCfg.Backcolor.Red = 0; if (HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0) != HAL_OK) Error_Handler(); /* Sets the Layer1 (index 0 refers to Layer1) Pitch to 512 pixels */ HAL_LTDC_SetPitch(&hltdc, 512, 0); Figure 27 describes the management of the memory after solving the previous problem.

Figure 27. Adding dummy bytes to make the line width multiple of 64 bytes

4.5.3 Optimizing the LTDC fr amebuffer fetching from SDRAM

important that no other masters are doing access into the same SDRAM bank.

Figure 28. Placing the two buffers in independent SDRAM banks accesses during CAS latencies.

4.5.4 Framebuffer content up date during BLANKING period

bus bandwidth is relaxed and it allows the update of the framebuffer.

4.6 Special recommen dations for Cortex®-M7 (STM32F7 Series)

  • The Cortex®-M7 does some speculative read accesses to normal memory regions. These speculative read accesses could cause high latency or system errors when performed on external memories like SDRAM or Quad-SPI. This impacts AHB masters (such as LTDC) accessing the FMC or Quad-SPI and particularly decreases graphical 06Y9 %DFNEXIIHU)URQWEXIIHU %DQN %DQN «%DQNQ 5RZ 5RZ 5RZ 5RZ 5RZ EXIIHUV

AN4861 Creating a graphical application with LTDC performances and may lead to system errors (if the LTDC framebuffer is located in external memory and/or if the Quad-SPI memory is used for graphics).

  • The Cortex®-M7 CPU embeds an L1-Cache (see Figure 10). Some graphic issues may be encountered due to unsuitable cache settings; bad graphic visual effects may occur if cache maintenance is not properly performed. If the suitable cache maintenance method is not used, graphical performances may be impacted.

4.6.1 Disable FMC bank1 if not used

After reset, the FMC bank1 is always enabled to allow boot into external memories. Since the Cortex ®-M7 is doing some speculations, it can generate a speculative read access to the first FMC bank. The default FMC configuration being very slow, this speculative access blocks the access to the FMC by other AHB masters for a very long time, leading to underrun on the LTDC side. To prevent this CPU speculative read accesses on the FMC bank1, it is recommended to disable it when it is not used. This can be done by resetting the MBKEN Bit in FMC_BCR1 register which is by default enabled after reset. To disable the FMC Bank1, the user can use the following code: /* Disabling FMC Bank1: After reset FMC_BCR1 = 0x000030DB where MBKEN = 1b meaning that FMC_Bank1 is enabled and MTYP[1:0]= 10 meaning that memory type is set to NOR Flash/OneNAND Flash*/ FMC_Bank1->BTCR[0] = 0x000030D2; For more details on FMC configuration refer to the relevant STM32 reference manual.

4.6.2 Configure the memo ry protection unit (MPU)

This section defines the STM32F7 Series system memory attributes and the basic MPU concepts. It also describes how to configure the MPU in order to prevent graphical performance issues related to the Cortex ®-M7 speculative read accesses and cache maintenance. Note: This section is only describing some necessary basic MPU concepts needed for configuration. For further details on MPU and cache, refer to the following documents: - AN4838 application note “Managing memory protection unit (MPU) in STM32 MCUs” - AN4839 application note “Level 1 cache on STM32F7 Series” - STM32F7 Series Cortex®-M7 processor programming manual (PM0253) - ARM Cortex®-M7 technical reference manual.

Creating a graphical application with LTDC AN4861 MPU attributes configuration In order to prevent graphic performance issues related to the Cortex®-M7 speculative read accesses, the user should review all the memory map of the application and configure the MPU according to the hardware. So, the user has to set the following configurations:

  • Define the framebuffer MPU region and the other application MPU regions.
  • MPU must be configured according to the size of the memory used by the application.
  • The MPU attributes of the unused regions must be configured to strongly ordered execute never (XN). For example, for the Quad-SPI, if an 8 MByte memory is connected, the remaining 248 MByte unused space (from a total 256 MByte addressable space) must be set to strongly ordered XN. See example in Section 6.2.7.
  • Prevent the Coretx-M7 speculative read accesses to the external SDRAM/SRAM (if the FMC swap is enabled, see Figure 29), to do it the SDRAM/SRAM MPU region must be set to execute never (XN).
  • If the Cortex ®-M7 CPU is used for framebuffer processing (writing to SDRAM/SRAM), the framebuffer region MPU attribute should be set to normal cacheable with read and write access permission. Note: The framebuffer MPU region attribute should be set to execute never since it is only dedicated for graphical content creation. Figure 29 describes the STM32F7’s FMC banks and Quad-SPI MPU memory attributes at default system memory map

Creating a graphical application with LTDC AN4861

  • Cache maintenance and data coherency: visual impact of WBWA without cache maintenance operation The data coherency issue is often encountered when performing framebuffer processing using a Cortex®-M7 CPU with L1-cache enabled and a WBWA cache policy. This issue occurs when multiple masters such as Cortex®-M7 and LTDC are sharing the same region (framebuffer) and the cache maintenance is not performed. When the CPU is processing the framebuffer (writes to framebuffer) and if the framebuffer region has a write-back cache policy, the processed result (image to be displayed) is not seen on the framebuffer (may be SRAM or SDRAM), and then it is not displayed. To avoid this issue, the user should use one of the following methods: – Configure the framebuffer region cache attribute to write-through (WT), in that case each write operation is performed on the cache and on the framebuffer. – Configure the framebuffer region cache attribute to write back write allocate (WBWA) and perform the cache maintenance by software. Write-through is safer for data coherency but may impact graphic performances.
  • Cache maintenance may impact graphic performances The user should use the suitable cache policy matching his application. Each method has its cons and pros. So the user should consider the following particularities for each method: – Write-through: is very simple to manage (no need to perform cache maintenance by software) and safer for data coherency but it generates a lot of single write operations to the framebuffer which may impact LTDC accesses. Note: The user should also consider that cac he maintenance may impact graphic performances even when the CPU is not used for framebuffer processing. Thus, in some applications the CPU is accessing to the external SDRAM or SRAM for purposes other than graphics with cache enabled. In that case, cache maintenance may impact the LTDC accesses. – Write back write allo cate: it is more suitable to use WBWA and software routine and synchronize the cache maintenance operation with the LTDC during blanking. This allows to create additional bandwidth on the framebuffer memory (SRAM or SDRAM). The cache maintenance operation should be performed by software after writing data to the framebuffer memory region; this is done by forcing a D- cache clean operation using the CMSIS function SCB_CleanDCache(). So all the dirty lines in the cache are written back to the framebuffer. MPU configuration example An example of MPU configuration is described in Section 6.2.7, showing how to set the framebuffer MPU attribute when the CPU is used (with cache enabled) for graphical operations. The described example is created for the STM32F746G-DISCO board hardware configuration where the external SDRAM is used for framebuffer and the external QSPI Flash memory is containing the graphic primitives.

4.7 LTDC peripheral configuration

This section describes the steps needed to configure the LTDC peripheral.

4.7.1 Display panel connection

LCD_HSYNC, LCD_VSYNC, LCD_DE and LCD_CLK. mapping table in the relevant datasheet. Note: All GPIOs have to be configured in very high-speed mode. shows an example of connecting an RGB666 display panel. Figure 30. Connecting an RGB666 display panel

Creating a graphical application with LTDC AN4861 GPIOs configuration using STM32CubeMX tool To connect a display panel to an STM32 MCU, the user should configure the GPIOs to be used for interfacing. Using the STM32CubeMX tool is a very simple, easy and rapid way to configure the LTDC peripheral and its GPIOs since it allows to generate a project with a preconfigured LTDC. Section Section 6.2.3: LTDC GPIOs configuration provides a guide on how to configure the LTDC GPIOs. Configuration of specific pins of a display module Some display modules may need other signals to be fully functional. The user can use GPIOs and some peripherals to control these signals. An example of using GPIOs to control the display enable pin (LCD_DISP) on a display panel is described in section Section 6.2.3: LTDC GPIOs configuration. Enabling LTDC interrupts To be able to use the LTDC interrupts, the user should enable the LTDC global interrupts on the NVIC side. Then, each interrupt is enabled separately by enabling its corresponding enable bit. The LTDC interrupt-enable bits are available in the LTDC_IER register described in Table 7: LTDC interrupts summary. Note: The FIFO underrun and transfer error interrupts are enabled in the hal_ltdc driver HAL_LTDC_Init() function An example of enabling LTDC interrupts using STM32CubeMX is described in Section 6.2.3: LTDC GPIOs configuration.

4.7.2 LTDC clocks and timings configuration

This section describes the steps needed to configure the LTDC clock and timings respecting the display specifications. It also provides a configuration example for the ROCKTECH (RK043FN48H) display embedded on the STM32F746G-DISCO board. System clock configuration It is recommended to use the highest system clock to get the best graphic performances. This recommendation applies also for the external memory framebuffer. So if an external memory is used for the framebuffer, the highest allowed clock speed should be used to get the best memory bandwidth. For instance for the STM32F4x9 microcontrollers the maximum system speed is 180 MHz, so if an external SDRAM is connected to the FMC the maximum SDRAM clock is 90 MHz (HCLK/2). For the STM32F7 Series, the maximum system speed is 216 MHz but with this speed and HCLK/2 prescaler the SDRAM speed exceeds the maximum allowed speed (see product”s datasheet for more details). So to get the maximum SDRAM, it is recommended to configure HCLK to 200 MHz, then the SDRAM speed is set to 100 MHz. The clock configuration providing the highest performances is:

  • STM32F4x9 devices: HCLK @ 180 MHz and SDRAM @ 90 MHz.
  • STM32F7 Series: HCLK @ 200 MHz and SDRAM @ 100 MHz.

LTDC peripheral configuration. display compatibility considering the memory bandwidth requirements). Table 14). It is recommended to use typical display timings. Table 14. LCD-TFT timings extracted from ROCKTECH RK043FN48H datasheet (1)

  1. The gray cells highlight the values used in the example presented below.

60 Hz refresh rate as shown below:

Based on Table 15, TOTALW = 531 and TOTALH = 297. Refer to the LTDC pixel clock configuration STM32CubeMX example in Section 6.2.4. control signal should be inverted versus the DE polarity indicated in the display datasheet. The other control signals should be configured exactly like the display datasheet. Table 15. Programming LTDC timing registers

AN4861 Creating a graphical application with LTDC

4.7.3 LTDC layer(s) configuration

This section describes the needed steps to configure the LTDC layer(s) respecting the display size and the color depth. As previously stated in Section 3.3.2 the LTDC features two independently configurable layers, where the user can enable either one or the two layers. By default both layers are disabled so only the configured background color is displayed (the default color is black). The user can display layer 1 + background or display layer 1 + layer 2 + background. Display only the background If no layer has been enabled, only the background is displayed. If the background color is not configured, the default background black color is displayed (LTDC_BCCR = 0x00000000). To set a blue background color the LTDC_BCCR register should be set to 0x000000FF. Layer parameters configuration Once that the LTDC GPIOs, clocks and timings are properly set, the user should configure the following LTDC layer parameters. Each LTDC layer has its own parameters so it should be configured separately.

  • Window size and position
  • Pixel input format
  • Framebuffer start address
  • Framebuffer size (image width and image height) and pitch
  • Layer default color in ARGB8888 format
  • Layer constant alpha for blending
  • Layer blending factor1 and factor2 An example of LTDC layer parameters configuration using STM32CubeMX is described in Section : LTDC Layer parameters configuration on page 75. Note: All layer parameters can be modified on the fly except for the CLUT. The new configuration has to be either reloaded immediately or during vertical blanking period by configuring the LTDC_SRCR register.

4.7.4 Display panel configuration

Some displays require to be configured using serial communication interfaces such as I2C or SPI. For instance the STM32F429I-DISCO is embedding the ILI9341 display module which is initialized through the SPI interface. A dedicated driver for this display module (ili9341.c) including initialization and configuration commands is available in the STM32Cube firmware package under: STM32Cube_FW_F4_Vx.xx.x\\Drivers\\BSP\\Components\\ili9341 An example of display initialization sequence based on the ili9341_Init() function is included in the STM32Cube examples for the STM32F429I-Discovery board under STM32Cube_FW_F4_Vx.xx.x\\Projects\\STM32F429I-Discovery\\ Examples\\LTDC\\LTDC_Display_2Layers

Creating a graphical application with LTDC AN4861

4.8 Storing graphic primitives

Graphic primitives are basic elements (such as images or fonts) which can combined to build the framebuffer content that is displayed. Static data should be placed in a non-volatile memory. When the amount of data to store is relatively low, the internal FLASH memory can be used. Otherwise, graphical contents should be placed in external memories. The STM32 microcontrollers offer parallel (FMC) or serial (QSPI) interface for external NOR Flashes (see Table 3). To build the framebuffer content, the DMA2D can directly read graphic primitives form a parallel NOR Flash or a Quad-SPI Flash. Refer to the application note Quad-SPI (QSPI) interface on STM32 microcontrollers (AN4760) for more details on storing graphic content on QSPI memory.

4.8.1 Converting images to C files

To add graphic primitives to a user project, they should be converted to C or header files. In order to do that, the user can use some specific tools allowing to generate C or *.h files. Warning: The user must convert images to C files respecting the configured pixel input format described in Section : Pixel input format on page 27. Some tools may generate C or *.h files with red and blue colors swapped. To avoid this issue (displaying an image with red and blue swapped), the user can use the LCD image converter tool. The LCD image converter is a very customizable free tool allowing to convert images to C files and offering the possibility to generate the C file in the desired format. An example is described in Section 6.2.5: Displaying an image from the internal Flash.

4.9 Hardware considerations

This section provides some hardware considerations for a graphic application. In general two important hardware interfaces should be designed carefully: the LTDC interface and the external memory interface (used for framebuffer) such as FMC_SDRAM or FMC_SRAM. LTDC parallel interface When the pixel clock is below 40 MHz (SVGA), a simple 3.3 V signaling can be used. It is possible to reach 83 MHz with a parallel RGB if the load and the wire length are reduced (for example to interface on the same PCB with on-board an LVDS transciver or HDMI transceiver). It is recommended to configure the LTDC GPIOs at the maximum operating speed OSPEEDRy[1:0] = 11b. Refer to the relevant STM32 reference manual for a description of the GPIOx_SPEEDR GPIO port output speed register.

AN4861 Creating a graphical application with LTDC FMC SDRAM/SRAM interface When using an external SRAM or SDRAM memory for a framebuffer, the FMC-SDRAM and the FMC-SRAM interfaces speed depend on many factors including the board layout and the pad speed. A good PCB design enables to reach the maximum pixel clock described in Table 10 and Table 11. The layout should be as good as possible in order to get the best performances. To get more information on PCB routing guidelines, refer to the following application notes available on the STMicroelectronics website:

  • Section “Flexible memory controller (FMC) interface” of application note Getting started with STM32F7 Series MCU hardware development (AN4661)
  • Section “Flexible memory controller (FMC) interface” of application note Getting started with STM32F4xxxx MCU hardware development (AN4488)

Saving power consumption AN4861

5 Saving power consumption

When an application is in idle state and displaying only a screen saver, it is important to drive the STM32 chip in sleep mode to reduce the power consumption. In sleep mode all peripherals can be enabled (FMC-SDRAM and LTDC for instance) while the CPU is stopped. External memories such as SDRAM or QSPI FLASH can be driven in low-power modes whenever it is needed in order to avoid the waste of power. If the application is in low-power state but requires to display graphics, the LTDC can be kept active and the SDRAM can be put in self-refresh mode (in order to save power). If the application is set in power-down mode, it saves even more power. The display can also be disabled or put in low-power mode if it is not needed when running the application.

AN4861 LTDC application examples

6 LTDC application examples

This section provides:

  • Some graphic implementation examples considering the resources requirements
  • An example on how to create a basic graphical application
  • A summary of STM32 reference boards with embedding LTDC and featuring an on- board LCD-TFT panel

6.1 Implementation examples and resources requirements

This section provides some graphic implementation examples detailing the hardware resources requirements.

6.1.1 Single chip MCU

Thanks to their integrated SRAM, the STM32 MCUs can be used for graphic applications without the need of an external SDRAM/SRAM memory for framebuffer. Also, thanks to their high size internal Flash (up to 2 MByte), the user can use them to store graphic primitives. The use of internal memories allows to reduce the used pins, ease the PCB design and make cost savings. In order to use a single chip MCU for a graphical application, the user can use the following hardware configuration:

  • Internal Flash up to 2 MByte: storing user application code and graphic primitives.
  • The framebuffer should be located in the internal SRAM, so depending on the internal SRAM size for each STM32 MCU, the user can interface with a corresponding display size and color depth as illustrated below: – STM32F7x7 line: use SRAM1 (368 Kbyte) to support resolutions 400 x 400 16 bpp (313 Kbyte) or 480 x 272 16 bpp (255 Kbyte). – STM32F7x6 line: use SRAM1 (240 Kbyte) to support 320 x 320 resolution with 16 bpp (200 Kbyte). – STM32F469/F479 line: use SRAM1 (160 Kbyte) to support 320 x 240 resolution with 16 bpp (154 Kbyte). – STM32F429/F439 line: use SRAM1 (112 Kbyte) to support 320 x 240 resolution with 8 bpp (75 Kbyte). – STM32 MCU packages: LQFP100 or TFBGA100 Figure 31 illustrates a graphic implementation example where only a single chip with no external memories is used.

Figure 31. Low-end graphic implementation example

6.1.2 MCU with external memory

  • External QSPI Flash memory with up to 256 MByte addressable memory-mapped is used for storing graphic primitives.
  • External SDRAM 32-bit memory used for framebuffer.
  • STM32 MCU packages: UFBGA169, UFBGA176, LQFP176, LQFP208, TFBGA216, WLCSP168 and WLCSP180. Figure 32 illustrates a graphic implementation example where two external memories are connected to a STM32 MCU, one for the framebuffer and the other for graphic primitives. 06Y9 )0& 5$0 8SWR )ODVK 8SWR %XV0DWUL[ /7'&&RUWH[0 &KURP $57 '0$' 'XDO 463, [ESS[ESS [ESS[ESS 5*% )UDPHEXIIHULQLQWHUQDO65$0*UDSKLFSULPLWLYHVLQWKHLQWHUQDO)ODVK

Figure 32. High-end graphic implementation example Table 16. Example of graphic implantations with STM32 in different hardware

  1. Package availability of STM32 MCUs embedding LTDC is summarized in Table 13.

6.2 Example: creating a ba sic graphical application

steps required to create a basic graphic application.

6.2.1 Hardware description

Figure 33. Graphic hardware configuration in the STM32F746G-DISCO

  1. The pink arrow shows the pixel data path to the display.
  2. 400x400 and 320 x 320 are specific display re solutions commonly used for smartwatches.

Figure 34. LCD-TFT connection in the STM32F746G-DISCO board

  • LTDC interface pins: – 24-bit RGB interface. – Timing signals: LCD_HSYNC, LCD_VSYNC, LCD_DE and LCD_CLK.
  • Other specific pins: – LCD_DISP to enable/disable display standby mode. – INT interrupt line: allows the touch sensor to generate interrupts. – I2C interface to control the touch sensor. – LCD_RST reset pin allowing to reset the LCD-TFT, it is connected to the global MCU reset pin (NRST). – LCD_BL_A and LCD_BL_K pins for LED backlight control: the backlight is controlled by the STLD40DPUR circuit. Backlight Controller: the STLD40DPUR circuit described in Figure 35 is a boost converter that operates from 3.0 V to 5.5 V. It can provide an output voltage as high as 37 V and can drive up to ten white LEDs in series. Refer to the STLD40D datasheet for more information on the backlight controller. The high level on the LCD_BL_CTRL (PK3) signal lights the backlight on, while the low level switches it off. Note: It is possible to change the display brightness (dim the backlight intensity) by applying a low- frequency (1 to 10 kHz) PWM signal to the EN pin 7 of the STLD40D circuit. This action needs a rework since there is no timer PWM output alternate function available on the PK3 pin, so user should remove the R81 resistance and connect another GPIO pin with the PWM output alternate function. 7LPLQJVLJQDOV 5*% 7RXFKLQWHUUXSW ,&IRUWRXFKVHQVRU /&'5HVHW %DFNOLJKW FRQWURO

Figure 35. Backlight controller module

6.2.2 How to check if a specifi c display size matches the

  • Display resolution: 480 x 272 pixels with LED backlight and capacitive touch panel.
  • Display interface: 24-bit RGB888 (in total 28 signals). Determining framebuffer size and location Depending on its size and on the internal available SRAM size, the framebuffer can be located either in the internal SRAM or in the external SDRAM. The total embedded SRAM size for the STM32F746NGH6 MCU is 320 Kbyte where SRAM1 (240 Kbyte) can be used (see Figure 10: LTDC AHB master in STM32F7x6, STM32F7x7, STM32F7x8 and STM32F7x9 smart architecture). The framebuffer size is calculated in the following way:
  • For 24 bpp – framebuffer (Kbyte) = 480 x 272 x 3 / 1024 = 382.5
  • For 16 bpp – framebuffer (Kbyte) = 480 x 272 x 2 / 1024 = 255
  • For 8 bpp: – framebuffer (Kbyte) = 480 x 272 / 1024 = 128 So based on these results, the required framebuffer size is about 128 Kbyte for 8 bpp. In that case, the framebuffer can be located in the internal SRAM1 (240 Kbyte). This is not valid for a double framebuffer case as the size of 128 x 2 Kbyte exceeds the internal SRAM size. For the 16 bpp color depth and in a double framebuffer configuration, the required framebuffer size (2 x 255 Kbyte) exceeds the internal SRAM size, so using an external SRAM or SDRAM is a must for this configuration.

AN4861 LTDC application examples For the 24 bpp color depth and in a double framebuffer configuration, the required framebuffer size exceeds the internal SRAM size (2 x 382.5 Kbyte), so using an external SRAM or SDRAM is a must for this configuration. The next step is to check if the SDRAM 16-bit bus width can sustain the desired resolution and color depth. Check if a 480 x 272 resolution with 24 bpp fits the SDRAM 16-bit configuration At this stage the user should have decided to use an external SDRAM but still has to check if the SDRAM 16-bit bus width (actual hardware implementation in the discovery board) matches the 480 x 272 @ 60 Hz display size and 24 bpp color depth. In order to conclude if such hardware configuration can support the desired display size and color depth or not, the user should first compute the pixel clock. The computed LCD_CLK is about 9.5 MHz (for computing pixel clock refer to Section 6.2.3: LTDC GPIOs configuration. Then the user should check based on the following parameters if the computed pixel clock is not higher than the maximum LCD_CLK indicated in Table 11. – Number of used LTDC layers: in this example only one layer is used. – System clock speed HCLK and framebuffer memory speed: HCLK @ 200 MHz and SDRAM @ 100 MHz. – External framebuffer memory bus width SDRAM 16-bit. – Number of AHB masters accessing concurrently to external SDRAM: 2 masters (DMA2D and LTDC). Referring to the pixel clock Table 11 in the “LTDC + DMA2D” column and one layer row, the pixel clock can reach 34 MHz for SDRAM of 16-bit. So the SDRAM 16-bit bus width is quite enough to sustain a 480 x 272 @ 60 Hz resolution (LCD_CLK = 9.5 MHz) with 24 bpp color depth.

6.2.3 LTDC GPIOs configuration

As shown on Figure 34, the ROCKTECH RK043FN48H display is connected to the STM32F746xx using a parallel RGB888 of 24 bits. LTDC RGB interface pins configuration Once that the STM32CubeMX project is created, in the Pinout tab choose one from the listed hardware configurations. Figure 36 shows how to select the RGB888 hardware configuration with the STM32CubeMX. The user can also configure all the GPIOs by setting the right alternate function for each GPIO one by one.

LCD_BL_CTRL (PK3) pin is kept floating so there is no need to configure this pin. then click on the LTDC button as shown in Figure 38. the LTDC global interrupts then click on the OK button. Figure 42. STM32CubeMX: enabling LTDC global and error interrupts

6.2.4 LTDC peripheral configuration

Figure 46. STM32CubeMX: LTDC timing configuration

AN4861 LTDC application examples LTDC Layer parameters configuration At this stage all LTDC clocks and timings should have been set in the STM32CubeMX project. The user should configure the LTDC layer1 parameters according to the display size and the color depth. If needed, the user can also enable the layer2 by setting to “2 layers” the “Number of Layers” field in the LTDC configuration window shown in Figure 47. To set the LTDC layer1 parameters using STM32CubeMX, the user must select the configuration tab then click on the LTDC button as shown in Figure 37. In the LTDC configuration window shown in Figure 47 the user must select the Layer Settings tab, set the LTDC layer1 parameters and then click on the OK button. At this step, the user can generate the project with the desired toolchain by clicking on “Project->Generate Code”

Figure 47. STM32CubeMX: LTDC Layer1 parameters setting

6.2.5 Displaying an imag e from the internal Flash

specifications, it is important to display an image from the internal Flash. graphic primitives on page 58).

LTDC application examples AN4861 hltdc.Init.AccumulatedActiveW = 523; hltdc.Init.AccumulatedActiveH = 293; hltdc.Init.TotalWidth = 531; hltdc.Init.TotalHeigh = 297; /* Background color */ hltdc.Init.Backcolor.Blue = 0; hltdc.Init.Backcolor.Green = 0; hltdc.Init.Backcolor.Red = 0x0; if (HAL_LTDC_Init(&hltdc) != HAL_OK) Error_Handler(); /* Layer1 Window size and position setting */ pLayerCfg.WindowX0 = 0; pLayerCfg.WindowX1 = 480; pLayerCfg.WindowY0 = 0; pLayerCfg.WindowY1 = 272; /* Layer1 Pixel Input Format setting */ pLayerCfg.PixelFormat = LTDC_PIXEL_FORMAT_RGB565; /* Layer1 constant Alpha setting 100% opaque */ pLayerCfg.Alpha = 255; /* Layer1 Blending factors setting */ pLayerCfg.BlendingFactor1 = LTDC_BLENDING_FACTOR1_PAxCA; pLayerCfg.BlendingFactor2 = LTDC_BLENDING_FACTOR2_PAxCA; /* User should set the framebuffer start address (can be 0xC0000000 if external SDRAM is used)*/ pLayerCfg.FBStartAdress = (uint32_t)&image_data_STLogo; pLayerCfg.ImageWidth = 480; pLayerCfg.ImageHeight = 272; /* Layer1 Default color setting */ pLayerCfg.Alpha0 = 0; pLayerCfg.Backcolor.Blue = 0; pLayerCfg.Backcolor.Green = 0; pLayerCfg.Backcolor.Red = 0; if (HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0) != HAL_OK) Error_Handler(); Once the LTDC is correctly configured in the project, the user should build the project and then run it.

AN4861 LTDC application examples

6.2.6 FMC SDRAM configuration

The external SDRAM must be configured as it contains the LTDC framebuffer. To configure the FMC_SDRAM and the SDRAM memory device mounted on the STM32746G-Discovery board, the user can use either STM32CubeMX or use the existing BSP driver. To configure the FMC_SDRAM using the BSP driver follow the steps described below: 1. Add the following files to the projec t: BSP stm32746g_discovery_sdram.c and Add the stm32f7xx_hal_sdram.c and stm32f7xx_ll_fmc.c HAL drivers to the project 2. Enable the SDRAM module in the stm32f 7xx_hal_conf.h file by uncommenting the SDRAM module definition. Include the stm32f7xx_hal_sdram.h file in the main.c file. 3. Call the BSP_SDRAM_Init() func tion in the main() function.

6.2.7 MPU and cache configuration

As illustrated in Section 4.6, the MPU attributes should be correctly configured in order to prevent graphical performance issues related to the Cortex®-M7 speculative read accesses and cache maintenance. This section describes an example of MPU attribute configuration with respect to the STM32F746G-DISCO board hardware configuration. The MPU memory attributes can be easily configured with STM32CubeMX. A code example of MPU configuration generated using STM32CubeMX is described at the end of this section. MPU configuration example: FMC_SDRAM In this configuration example, the double framebuffer technique is used; the frontbuffer is placed in the SDRAM bank1 while the backbuffer is placed in the SDRAM bank2 with respect to the SDRAM bandwidth optimization described in Section 4.5.3: Optimizing the LTDC framebuffer fetching from SDRAM. The following MPU regions are created (FMC without sawp):

  • Region0: defines the SDRAM memory size 8 MByte
  • Region1: defines the frontbuffer 256 Kbyte (16 bpp x 480 x 272), it overlaps region0
  • Region2: defines the backbuffer 256 Kbyte (16 bpp x 480 x 272), it overlaps region0 Figure 52 illustrates the MPU configuration of the SDRAM region.

Figure 53. MPU configuration for Quad-SPI region the FMC_SDRAM and Quad-SPI respecting the previously described configurations.

LTDC application examples AN4861 HAL_MPU_ConfigRegion(&MPU_InitStruct); /* Configure the MPU attributes for region 1 */ /* Configure the MPU attributes for the frontbuffer to normal memory*/ MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER1; MPU_InitStruct.BaseAddress = 0xC0000000; MPU_InitStruct.Size = MPU_REGION_SIZE_256KB; MPU_InitStruct.SubRegionDisable = 0x0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1; MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); /* Configure the MPU attributes for region 2 */ /* Configure the MPU attributes for the backbuffer to normal memory*/ MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER2; MPU_InitStruct.BaseAddress = 0xC0200000; MPU_InitStruct.Size = MPU_REGION_SIZE_256KB; MPU_InitStruct.SubRegionDisable = 0x0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1; MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); /* Configure the MPU attributes for region 3 */ /* Configure the MPU attributes for Quad-SPI area to strongly ordered memory*/ MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER3; MPU_InitStruct.BaseAddress = 0x90000000; MPU_InitStruct.Size = MPU_REGION_SIZE_256MB; MPU_InitStruct.SubRegionDisable = 0x0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

AN4861 LTDC application examples MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); /* Configure the MPU attributes for region 4 */ /* Configure the MPU attributes for QSPI memory to normal memory*/ MPU_InitStruct.Enable = MPU_REGION_ENABLE; MPU_InitStruct.Number = MPU_REGION_NUMBER4; MPU_InitStruct.BaseAddress = 0x90000000; MPU_InitStruct.Size = MPU_REGION_SIZE_16MB; MPU_InitStruct.SubRegionDisable = 0x0; MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0; MPU_InitStruct.AccessPermission = MPU_REGION_PRIV_RO; MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE; MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable = MPU_ACCESS_CACHEABLE; MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE; HAL_MPU_ConfigRegion(&MPU_InitStruct); /* Enables the MPU */ HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

6.3 Reference boards with LCD-TFT panel

ST offers a wide range of reference boards such as NUCLEO, Discovery and EVAL boards, many of them embedding display panels. For STM32 reference boards featuring an on- board display but not embedding an LTDC, the DBI (FMC or SPI) interface is used to connect the STM32 with the display. For the other STM32 boards, the LTDC is used to interface with the display panel. These reference boards can be used to evaluate the graphic capability in specific hardware / software configurations. Table 17 summarizes the STM32 reference boards embedding LTDC and featuring an on- board TFT-LCD panel.

320 RGB666 Resistive

480 RGB666 Capacitive

272 RGB888 Resistive

480 RGB888 Capacitive

480 RGB888 Capacitive 32-bit 16-bit 64

272 RGB888 Capacitive

80 RGB888 Capacitive

80 RGB888 Capacitive 32-Bit 16-Bit 64

  1. An available board B-LCDAD-HDMI1 (that can be purchased separately), allows to convert DSI into HDMI format to

connect HDMI consumer displays. microcontroller motherboard to the standard display connector (TE 1-1734248).

  1. Another discovery board is available STM32F769I-DISC1 but with no embedded display, the display can be purchased

separately as B-LCD40-DSI1ordering code.

AN4861 Supported display panels

7 Supported display panels

The display controller embeds a very flexible interface that provides below features which allow the STM32 MCUs to support multiple parallel display panels (such as TFT-LCD and OLED displays) available in the market:

  • Different signal polarities.
  • Programmable timings and resolutions. The display panel's pixel clock (as indicated in manufacturer datasheet) must not be higher than the STM32's maximal pixel clock. So the user should refer to the display datasheet to ensure that the panel’s running clock is lower than the maximum pixel clock.

8 Frequently asked questions

Table 18. Frequently asked questions memory used for framebuffer. considering the memory bandwidth requirements. shared with other AHB masters or not. provides the best possible performances. considering the memory bandwidth requirements. Does LTDC support OLED displays? Yes, if the OLED display has a parallel RGB interface. Does LTDC support STN displays? No, STN displays are not supported by LTDC. Section 4.8.1: Converting images to C files).

9 Conclusion

The STM32 MCUs provide a very flexible display controller allowing to interface with a wide range of displays at a lower cost and offering high performances. Thanks to its integration in a smart architecture, the LTDC autonomously fetches the graphical data from the framebuffer and drives it to the display without any CPU intervention. The LTDC is able to continue fetching the graphical data and driving the display while the CPU is in SLEEP mode, which is ideal for low power and mobile applications such as smartwatches. This application note described the STM32 graphical capabilities and presented some considerations and recommendations to take fully advantage of the system's smart architecture.

Table 19. Document revision history 10-Feb-2017 1 Initial release.