Mcufriend LCD TFT shield with ILI9325 libraries test

Versione italiana qui

I bought a 2.4” TFT LCD shield on ebay

The characteristics declared are

· 4-wire resistive touchscreen
· spfd5408 controller with built in video RAM buffer
· 8 bit digital interface, plus 4 control lines

It is marked [u][/u]. It is a shield and all communications are done using 4+8 pins.

As you can see there is an ILI after the name of the shield and there is a “9325” printed with a timbre.

[u][/u] is down.

Using I found the download page but unfortunately the library
[uno242628.rar](http://“http://“http://“http://“http://“ uno242628.rar”””””)
was not archived.

Then I went here
downloaded the LCD_ID_Reader Version 1.2 sketch and run it on Arduino UNO R3.
I got ILI9325 as ID and a red screen so the Justin drivers should works. It seems that spfd5408B is compatible with ILI9325 but I don’t know if they have the same ID.
Downloaded and tested Justin libraries they work with the exception of the bitmap example: i get wrong colours.

Original Adafruit library identify the chipset as ILI9325 but doesn’t work, only a blank screen.

Then I downloaded the driver modified by buhosoft
They works but it seems that there is an error since the same sketch use the double of flash than using the Adafruit library. The bmp example doesn’t fit on a UNO.

I removed all unused code and I got the same flash bytes occupation. Doing a comparison between libraries I found that it seems that the only difference is in the ccp file in the reset routine.

*******************ORIGINAL ADAFRUIT******************
  digitalWrite(5, LOW);
  digitalWrite(5, HIGH);
  if(_reset) {
    digitalWrite(_reset, LOW);
    digitalWrite(_reset, HIGH);
    digitalWrite(_reset, HIGH);
    digitalWrite(_reset, LOW);
    digitalWrite(_reset, HIGH);

*****************MODIFIED BUHOSOFT*******************
  digitalWrite(5, LOW);
  digitalWrite(5, HIGH);
  if (_reset) {
    digitalWrite(_reset, LOW);
    digitalWrite(_reset, HIGH);

Edit: I made the change in the Adafruit library and it works.
I still have the same problem wit bitmaps.

Next library tested was the one by Smoke and Wires.
This library works but I still have the same problem with bitmaps.

Next library tested was the samuraijap’s one
It works with errors, it seems a memory location error since I get only partially coloured screen. All drawing are in the wrong position.

Next library tested was the one by ruelj2
It works but there is a noise that appears as blank lines in the screen during communications. Same wrong colours in bitmaps.

Next library tested was the one by goltermc
It works.

Library made by David Prentice
Tested only graphictest_kbv ant it work!!!

Doesn’t work:

Library by andreword
blank screen

Library by JoaoLopesF for SPFD5408 (need to change #include “pin_magic.h” into #include “pin_magic_UNO.h” in SPFD5408_Adafruit_TFTLCD.cpp to compile) EDIT:Joao fixed the error!
blank screen

Library by acharis
blank screen

Old library from SeedStudio where in tft.h is written (don’t know were I got it)
SPFD5408A or ST7781R TFT Library
blank screen so SPFD5408A should be different from SPFD5408B
The new one is here
but the .h file says that is only for ST7781R.

I din’t test UTFT library since it use different pins for 8bit communications and it seems that can’t be changed.

Most libraries need a const added just before
static unsigned char font PROGMEM = {
in file glcdfont.c instead you get an error in IDE 1.6.5

In most bitmap examples you must add
#include <SPI.h>
for the same reason.

Bitmap problem resolved. See here

Colours seems 555 coded and not 565. Very strange!

I have exactly the same display. Mine came from BangGood.

It does not render the Green properly. I just have 2 bits of Green:

5-6-5 encoding should be 32 shades of Red, 64 shades of Green,   32 shades of Blue.
RRRRRGGGGGGBBBBB    // on my other ILI9325 displays  Green is bit 6-11 (64 shades)
RRRRRxGGxxxBBBBB    // on the BangGood display.   Green is bit 9-10 (4 shades)

Yes, if you alter the tft.color565() method, you can get a “readable” photo.
I will post a sketch that displays the “R-G-B” gradation later today.

If I put the controller into 8-colour mode, the encoding is more obvious. i.e. bit 11 is ignored.

I suspect that several readers have obtained this particular display. Does anyone have one that actually works correctly?

I presume that there is some manufacturing defect with the TFT. The controller seems to behave as expected. i.e. reading or writing to the registers and memory.


Maybe some pins are broken or solded badly? But it is strange that all of us have problems only with the green colour.

Yes, the soldering of the micro-flex connector has bridges as you can see from your photo. In fact those bridges are on pins that are interconnected anyway. I am pretty sure that the problem is not with the 37-way flex connector.

Here is an example sketch: It should build with any of the “Adafruit_TFTLCD.h” libraries that are original or have been hacked.

 * rainbow_kbv
 *  Author: David Prentice
 * displays colour gradation on mcufriend UNO shields 

#include <Adafruit_GFX.h>
#include <Adafruit_TFTLCD.h>
Adafruit_TFTLCD tft(A3, A2, A1, A0, A4);
//#include <MCUFRIEND_kbv.h>
//MCUFRIEND_kbv tft;

uint16_t Control1, eightcolour;
uint16_t ID;

void setup(void)
    ID = tft.readID();
    Serial.print("TFT ID = 0x");
    Serial.println(ID, HEX);
    if (ID == 0xB509) Control1 = tft.readReg(0x00B);
    else Control1 = tft.readReg(0x007);

void loop(void)
    uint16_t start, y, incr, color;
    uint16_t height, width;
    width = tft.width();
    height = tft.height();
    incr = height / 3;
    tft.setCursor(0, start = 0 * incr);
    for (start += 16, y = 0; y < 64; y++) {
        color = tft.color565(y << 2, 0, 0);
        tft.drawLine(0, start + y, width, start + y, color);
    tft.setCursor(0, start = 1 * incr);
    for (start += 16, y = 0; y < 64; y++) {
        color = tft.color565(0, y << 2, 0);
        tft.drawLine(0, start + y, width, start + y, color);
    tft.setCursor(0, start = 2 * incr);
    for (start += 16, y = 0; y < 64; y++) {
        color = tft.color565(0, 0, y << 2);
        tft.drawLine(0, start + y, width, start + y, color);
#if defined(MCUFRIEND_KBV_H_)
    switch (ID) {
        case 0x0154:
        case 0x7783:
        case 0x9320:
        case 0x9325:
            eightcolour ^= (1 << 3);   //CL
            tft.WriteCmdData(0x0007, Control1 | eightcolour);
        case 0xB509:
            eightcolour ^= (1 << 0);   //COL
            tft.WriteCmdData(0x000B, Control1 | eightcolour);
    tft.setCursor(0, height - 10);
    tft.fillRect(0, height - 10, width, 10, 0x0000);
    tft.print("Controller ID: 0x");
    tft.print(ID, HEX);
    if (eightcolour) tft.print(" 8 colours   ");
    else tft.print(" 65k colours");

Use my “MCUFRIEND_kbv.h” library if you want to see 8-colour mode. You can find it attached to message#14
Comment out the Adafruit_TFTLCD include and constructor. Uncomment the MCUFRIEND_kbv include and constructor.


Thank you David for sharing your discovery. If the solder is ok I wonder if these chips are defective.

I would guess that it is a manufacturing problem with the physical TFT. After all, it must be pretty difficult to get the variable transmissive response for each primary colour.

The integrated circuit technology tends to either pass or fail. It is when you marry the i.c. electrical signals to the "big" LCD array that must be difficult to align.

Have you tried my sketch? Do you see two distinct sets of green bands? Do you see more than 4 levels of green?

I can understand "several" bad green shields. It seems unlikely that "all" shields with the "flex at bottom right hand edge" style would fail. The Chinese would have noticed !!!



Yes, I see two green bands and it seems that there are few green levels.


I spend the last two weeks trying to get the colors right on two of these mcufriend ILI9325 displays from Banggood. I already homed in on green being the issue, but could not put my finger on it yet. When I run the david_prentice sketch the banding is there as expected. The '555' workaround makes the pictures better in tftbmp, but green is still off. Seems to me this is not expected behavior... Would be strange though if a whole batch of these end up in the field unnoticed?

No, I am pretty confident that it is a genuine issue. For a start, BangGood seem to be reluctant to reply to the problem.

Not only BG, but it appears that people have bought these "green feature" displays from other vendors. What would be really interesting is to hear that any boards (II9325 with flex at bottom right) do NOT have a green problem.

Yes, you can mangle the Color565() method to use 2 bits (5-2-5) instead of the proper 6 bits for Green. But this is not an acceptable solution.


I fully agree, 2-bit green is useless. I guess that's what you can get when buying these cheap knock-offs... I bought these displays for prototyping (€5,-), so it's not the end of the world. Which doesn't mean that I don't want these displays replaced by good ones. Definitely will buy a real Adafruit display for the final project. Btw I still have one 2.4" display on the way from BG, should arrive in a week or so. Curious how that one will behave. I'll post an update.

One final remark: The brightness of the display isn't great. I noticed that during a reset with the display already showing a picture, the existing picture on the tft seems to 'light up' and brightness increases significantly. Once the sketch is running, brightness will dimm again. To my knowledge the controlling pin for this is hardwired to gnd and not available for pwm control. This behavior also doesn't increase confidence to the build quality. Note: is currently back up, schematics and an ancient library are available.

Cheers, Michiel

No, the basic design has been available for several years. i.e. 2.4" TFT, resistive Touchscreen and microSD with appropriate level shifter chips for Uno shield.

It has appeared with several different brands of controller chip. It is not much more than soldering a 3.3V bare screen to the red pcb. This is the first time that the red pcb has involved cut-out slots and microflex connectors.

All the previous shields worked just fine. They obviously required slightly different software for the different controller types. In practice they all worked the same. Perhaps with slight cosmetic differences according to the specific TFT manufacture.

Yes, they are cheap. But so are the 3.3V bare modules. I presume that they are the result of the massive phone market.


david_prentice: I presume that they are the result of the massive phone market.


I agree. But I wonder why we all three have the same defect on green and not other colour. I bought mine on eBay not Banghood.

As far as I can see, Mcufriend or LcSoft produce some circuit boards. Then several Chinese assembly houses produce the finished products. In turn, several more Chinese companies sell them via Aliexpress or Ebay. Or even local hobbyist shops.

For example. Just look for 2.4" Shield or Usbasp. There must be hundreds of different vendors of what look like "similar" boards.

Regarding the Green. I have no idea. I presume it is a manufacturing fault in the bare TFT. I suspect that the pcb assembly is 100% ok. Quite honestly, BG, DealExtreme or whichever Ebay vendor sold you the duff board, should replace the shield. In practice, they will either keep silent or ask you to return the shield at your expense.

You can open a dispute through Ebay. You will possibly get your money back. With no replacement. i.e. you gamble with another vendor and wait for China Mail.


Wandering about this colour problem I wrote a sketch to test every single bit of colour, using all power of 2.
But the results was not as espected.
For every colour I see only one bar instead of many. Maybe there are errors?

 * A sketch to test all bits in register colour
 * 320*240
 * 2015 09 16
#include <Adafruit_TFTLCD_mcu.h>   //Change this with your library
#include <Adafruit_GFX.h>

#define LCD_CS A3 // Chip Select goes to Analog 3
#define LCD_CD A2 // Command/Data goes to Analog 2
#define LCD_WR A1 // LCD Write goes to Analog 1
#define LCD_RD A0 // LCD Read goes to Analog 0
#define LCD_RESET A4 // Can alternately just connect to Arduino's reset pin


void setup() {
  Serial.println(F("TFT Green Test"));

  uint16_t identifier = tft.readID();



  tft.fillRect(0, 0, 219, 53, 32);
  tft.fillRect(0, 54, 219, 53, 64);
  tft.fillRect(0, 107, 219, 53, 128);
  tft.fillRect(0, 160, 219, 53, 512);
  tft.fillRect(0, 213, 219, 53, 1024);
  tft.fillRect(0, 266, 219, 53, 2048);
  tft.fillRect(0, 0, 219, 53, 1);
  tft.fillRect(0, 54, 219, 53, 2);
  tft.fillRect(0, 107, 219, 53, 4);
  tft.fillRect(0, 160, 219, 53, 8);
  tft.fillRect(0, 213, 219, 53, 16);
  tft.fillRect(0, 266, 219, 53, 32);
  tft.fillRect(0, 0, 219, 53, 4096);
  tft.fillRect(0, 54, 219, 53, 8192);
  tft.fillRect(0, 107, 219, 53, 16384);
  tft.fillRect(0, 160, 219, 53, 32768);
  tft.fillRect(0, 213, 219, 53, 0xF800);
  tft.fillRect(0, 266, 219, 53, 0x07E0);

void loop() {


Hi all I received a mcufriend board with ILI9341 controller. Until now only white blank screen with every sketch found around the net. Any clue to get it work?

amaze1: Hi all I received a mcufriend board with ILI9341 controller. Until now only white blank screen with every sketch found around the net. Any clue to get it work?

Try these Libraries from this Tutorial. It states to be compatable with the following LCD drivers: ILI9325, ILI9327, ILI9328, HX8347G, ILI9341, HX8357D, S6D0154..

Hopefully these will help get your shield up and running.


Added the library by David Prentice. It works!

No, it does NOT work with your ILI9325 shield. Your shield has a hardware problem. Hence the GREEN dog.
I had a similar display from BangGood. Red and Blue were fine. The Green only had 2-bits resolution.

On simple displays like graphicstest Demo, you will not notice. Now try a BMP.


It works but, as you as wrote, I have not tested BMP. But BMP fails with the others libraries too. And maybe it will works with some other shields that doesn't have this hardware problem, I think, without problem with BMP.