Interfacing LCD Modules


Last Update: Aug 5, 2020 @ 13:04 Information subject to change.

This is another Application Note relevent to using STM32CubeMX and True Studio. The issues with source code to initialize the Orise Tech OTM8009A and Raydium RM68120 controllers using a 16-bit parallel interface are discussed.

We get our LCD modules for the Decaf boards ready-made from China suppliers. These modules (2.8″, 4″ and 7″) all have a 16-bit parallel interface. The 72MHz Cortex-M3 and 168MHz Cortex-M4 series mcu boards are the higher end models that support the high speed FSMC (Flexible Static Memory Controller) mode to access the LCD and esspecially to write data to the LCD GRAM (Graphic memory).

We’ve used the ILI9320/25/28 series and the SSD1963 LCD controller chips without much difficulty, but recently have come across some LCD modules that are … aggravating … for developers.

The code base for all the Decaf LCD models is essentially hardware independent for the most part, which simplifies the addition of new functionality and maintenance of the code. The hardware dependence is on three levels: mcu clocks, I/O pin assignments, and LCD initialization. The first two are handled with the STM32CubeMX project and the target mcu selection, and then with TrueStudio.

The problem area is the LCD controller initialization in a function we named LCD_Init(). This function contains the code that configures the controller to the attached LCD panel.

An issue that comes up with configuring FSMC for an LCD is the addressing of the Control Register, and the associated Data Register. In the Cortex-M3 and M4 chips, there’s up to four RAM Banks (1 – 4) that can be accessed, depending on how the mcu controller board is designed. All our boards use Bank#1, which has the base address of 0x6000 0000. Within each Bank, there are four 64MB regions which are addressed using the FSMC_NE1|2|3|4 signal. Hence, the base addresses for Bank#1 with the four possible NEx qualifiers are:

  • Bank #1, NE1 = 0x6000 0000
  • Bank #1, NE2 = 0x6400 0000
  • Bank #1, NE3 = 0x6800 0000
  • Bank #1, NE4 = 0x6C00 0000

The LCD Data Register Select (LCD_RS) is handled by one of the FSMC Ax address lines, such as FSMC_A10, A18, or A2. The address line for the 16-bit LCD interface is set by the design of the mcu controller board, not the LCD board. The LCD_RS address bit to be set is Ax + 1, so using the previous examples we have …

  • Bank #1, NE1, A10 LCD_RS = 0x6000 0800
  • Bank #1, NE3, A18 LCD_RS = 0x6808 0000
  • Bank #1, NE2, A2 LCD_RS = 0x6400 0008

We have two controllers with issues, mostly because the obsolescent controller Data Sheets are incomplete early versions.

The Orise Tech OTM8009A 800×480 LCD-TFT controller DataSheet is v0.92 (June 2012) which appears to be the last available version. We were able to locate some LCD_Init code, and after stripping out the Chinese comments, we were able to get the controller to initialize the display.

The Raydium Semiconductor Corp RM68120 800×400 LCD TFT controller Datasheet is v0.0 (May 2011) and there does not appear to be a newer version anywhere, and we have surely looked. Raydium was bought by another company and no longer manufactures the RM68120. We have located some init code, but this appears to to use the SPI or/and MIPI interfaces. One initialization command set we found documented in code enables the SPI interface mode, and it’s not documented in the v0.0 manual. There’s also a lot of code that sets gamma levels accessing undocumented registers and values. We’ll keep looking for documented and working code. The display is working at some level, as it displays all white pixels. We can issue the Invert_All_Pixels command, and the the screen turns black and back to white under test program control. Tests indicate that the GRAM is not being written correctly, and possibly not read either. We don’t know if the LCD module is faulty, or perhaps the Cortex-M4 board has a problem.

If you want the LCD init source code, contact us.