This application note describes how to use SmartDMA on the MCXA577 as a software LCD controller to generate 480 × 272 parallel RGB LCD timing in RGB565 format. A prebuilt SmartDMA firmware array is copied to SRAMX3 and started through its API table; SmartDMA then performs continuous full-frame scanning while the Arm Cortex-M33 builds the UI, schedules animations, and updates dirty areas. No dedicated LCD controller, FlexIO, or eDMA channel is used.
The demonstration UI is a kitchen timer. Three decorative bubbles in the upper-left corner use the LVGL animation engine.
- Resolution 480 × 272; pixel format RGB565, 16 bits per pixel.
- SmartDMA drives 21 signals: D0–D15, PCLK, HSYNC, VSYNC, DE, and DISP.
- The full framebuffer is 261,120 bytes (255 kB); LVGL renders into a 480 × 27 partial draw buffer (25,920 bytes) and the flush callback copies dirty areas into the shared framebuffer.
- The 2,656-byte SmartDMA firmware array (12-word API table plus 2,608-byte binary) is installed into SRAMX3 at runtime; Arm and SmartDMA share the framebuffer in SRAM.
- Raster geometry of the installed firmware: 531 PCLK per line (2 sync + 41 back porch + 480 active + 8 front porch) and 293 lines per frame (10 sync + 7 back porch + 272 active + 4 front porch).
- The three upper-left bubbles float asynchronously; their moving redraw areas are visible in the serial flush coordinates.
For the full theory of operation, timing waveforms, memory layout, and bandwidth budget, see application note AN15129 — Implement RGB LCD Interface by SmartDMA on MCX A577.
- MCUXpresso IDE V25.6 or later
- SDK_25_06_00_FRDM-MCXA577
- MCUXpresso for Visual Studio Code: This example supports MCUXpresso for Visual Studio Code, for more information about how to use Visual Studio Code please refer here.
- LVGL 9.4 (included in the project under
lvgl/), used inLV_DISPLAY_RENDER_MODE_PARTIALmode.
-
FRDM-MCXA577
-
K043FN02H-CT LCD Module
-
USB Type-C cable
-
Personal Computer
-
Some fly wires
The K043FN02H-CT is the panel used for validation, but it is not required. Any RGB LCD module that meets the electrical and timing requirements can be used — connect it by signal name, and do not reuse the connector pin numbers of the validation hardware. Note the following:
- Logic supply: verify that the I/O voltage of the selected LCD module is compatible with the MCXA577 3.3 V signals. Add level shifting when it is not compatible.
- Ground: the MCXA577 and the LCD module must share a low-impedance common ground.
- Backlight: connect LED_A/LED_K or the backlight-control input according to the LCD module data sheet.
- Unused color bits: RGB565 uses only R3–R7, G2–G7, and B3–B7. Handle the unused lower color inputs as specified by the selected module data sheet.
- If the resolution, panel, or sampling edge changes, recalculate the timing and verify the waveforms with a logic analyzer.
- Connect FRDM-MCXA577 with LCD module as below assignment.
| SmartDMA Data Bit |
MCXA577 Header | MCU Pin / Mux | SmartDMA PIO | LCD Signal |
|---|---|---|---|---|
| D0 | J9-4 | P0_4 / ALT7 | PIO0 | R3 |
| D1 | J9-3 | P0_5 / ALT7 | PIO1 | R4 |
| D2 | J9-6 | P3_2 / ALT10 | PIO2 | R5 |
| D3 | J9-5 | P0_7 / ALT7 | PIO3 | R6 |
| D4 | J9-8 | P0_14 / ALT7 | PIO4 | R7 |
| D5 | J9-7 | P0_15 / ALT7 | PIO5 | G2 |
| D6 | J9-10 | P0_16 / ALT7 | PIO6 | G3 |
| D7 | J9-9 | P0_17 / ALT7 | PIO7 | G4 |
| D8 | J9-2 | P0_18 / ALT7 | PIO8 | G5 |
| D9 | J8-21 | P2_0 / ALT7 | PIO24 | G6 |
| D10 | J8-22 | P2_1 / ALT7 | PIO25 | G7 |
| D11 | J8-23 | P2_2 / ALT7 | PIO26 | B3 |
| D12 | J8-28 | P4_7 / ALT7 | PIO27 | B4 |
| D13 | J8-6 | P2_4 / ALT7 | PIO28 | B5 |
| D14 | J8-26 | P2_5 / ALT7 | PIO29 | B6 |
| D15 | J8-27 | P2_6 / ALT7 | PIO30 | B7 |
| PCLK | J8-19 | P0_22 / ALT7 | PIO12 | PCLK |
| HSYNC | J8-20 | P0_23 / ALT7 | PIO13 | HSYNC |
| VSYNC | J8-10 | P2_19 / ALT7 | PIO21 | VSYNC |
| DE | J9-12 | P4_2 / ALT7 | PIO22 | DE |
| DISP | J8-4 | P3_20 / ALT10 | PIO20 | DISP / ENABLE |
Logically the SmartDMA data bus carries D0–D4 as the 5-bit red channel, D5–D10 as the 6-bit green channel, and D11–D15 as the 5-bit blue channel. Because the validation wiring maps these lines as shown above, the LVGL flush callback and RGB_LCD_FillColor() swap the red and blue fields before writing to the framebuffer:
lcdColor = ((color & 0xF800U) >> 11U) |
( color & 0x07E0U) |
((color & 0x001FU) << 11U);If you rewire the panel so that the channels line up directly, remove this swap.
Connect the board to the computer via the USB cable. The hardware as below:
-
Open MCUXpresso IDE, in the Quick Start Panel, choose Import from Application Code Hub.
-
Enter the demo name in the search bar.
-
Click Copy GitHub link, MCUXpresso IDE will automatically retrieve project attributes, then click Next>.
-
Select main branch and then click Next>, Select the MCUXpresso project, click Finish button to complete import.
- Import the project (an-mcxa577-rgb565-lcd-interface-by-smartdma) into MCUXpresso IDE as described in section 3.2.
- Select the Debug configuration and click Build Project to build the application.
- Open a serial port assistant on the board's debug UART and set the baud rate to 115200.
- Connect the FRDM-MCXA577 board, then click Debug to download and run the application. Confirm that the LCD starts normally and displays the demo screen.
The hardware displays the kitchen-timer UI steadily: a dark-blue background, a light rounded main panel, an orange Cook label, a central countdown and pot graphic, and temperature, status, and capacity cards along the bottom. The red, green, and blue channels are correct, confirming the RGB/BGR field swap and all 16 data lines. The three upper-left bubbles continuously float up and down.
The serial console output during startup and rendering is:
MCUX SDK version: ...
LVGL 9.4 with SmartDMA RGB LCD: 480x272 RGB565.
LVGL heap after UI: used=...
LVGL flush N: (x1,y1)-(x2,y2) begin
LVGL flush N: complete
The flush coordinates track the moving bubble areas, which confirms that LVGL partial rendering and the copy into the shared framebuffer are working.
Q: The colors look wrong (red and blue are exchanged). Check the R/B field swap described in section 3.1. It compensates for the validation wiring; if your panel is wired so the channels align directly, remove the swap.
Q: The image is corrupted or disappears.
A parallel RGB panel has no display memory, so PCLK and the sync signals must never stop. Confirm that SmartDMA is still running and that SMARTDMA_SetExternalFlag(1U) was called after SMARTDMA_Boot() — the raster firmware checks the external flag at every frame boundary.
Q: Can I use a different LCD module or resolution? Yes, but connect by signal name rather than by connector pin number, and recalculate the timing for the new panel. The firmware array, API-table entry, installation address, and the absolute addresses embedded in the image form one validated package: if it is rebuilt or relocated, regenerate and revalidate the whole array and confirm that the SRAM and SRAMX3 objects do not overlap. Always verify the resulting waveforms with a logic analyzer.
Q: The animation stutters.
The flush callback prints diagnostics for every transfer. This is useful for observing dirty areas but consumes CPU and UART time. Disable or rate-limit the per-flush PRINTF in a production build.
Q: What is the memory cost? Approximately 280 kB in total: a 261,120-byte full framebuffer, a 25,920-byte LVGL partial buffer, a 64-byte SmartDMA stack, and an 8-byte parameter block in SRAM, plus the 2,656-byte firmware image installed in SRAMX3.
- Application note: AN15129 — Implement RGB LCD Interface by SmartDMA on MCX A577
- FRDM-MCXA577 product page
- MCX A series microcontrollers
- MCUXpresso SDK
- NXP Community Forum
Questions regarding the content/correctness of this example can be entered as Issues within this GitHub repository.
Note: For more general technical questions regarding NXP Microcontrollers and the difference in expected functionality, enter your questions on the NXP Community Forum
| Version | Description / Update | Date |
|---|---|---|
| 1.0 | Initial release on Application Code Hub | September 30th 2026 |