Solved: ESP32 ILI9486 - Parallel 8 Bit - Blank Screen & TFT_DC issue

[wEPac]

Hello,

I am facing a strange issue at startup with my screen. I tired the screen with others libraries running ILI9486 in 8bits parallel and it s working fine. So to make it simple, I use the sketch "Color_test.ino" from your library.

1. At startup, the sketch runs but the screen stays white blank
2. At this moment, pulling down the TFT_DC pin to the ground (~1 to 5 s), the screen ends to show the text and the colors inversion
3. Soon I can see the text displayed, I stop to pull down the TFT_DC pin and the screen keeps working

May you have an idea for a little help?

Hardware :

• ESP32 DevKitC v4
• SMC0400A RTP ILI9486 https://fr.aliexpress.com/item/4000304860179.html
• wires 4 inch long

Settings and pinout (many times verified...) :

#define ILI9486_DRIVER

#define TFT_BL   32

#define TFT_PARALLEL_8_BIT
#define TFT_DC   15
#define TFT_RST   5

#define TFT_WR    4
#define TFT_RD    2

#define TFT_D0   13
#define TFT_D1   12
#define TFT_D2   14
#define TFT_D3   27
#define TFT_D4   26
#define TFT_D5   25
#define TFT_D6   16
#define TFT_D7   17

[Bodmer]

That is very odd behaviour.

List all the connections you have made between the processor and display.

Post a picture of the wiring.

Run the Read_User_Setup sketch and post the serial output here.

[Bodmer]

I has a look at the vendors page. This indicates the ILI9486 based display is 16 bit only and thus will not work correctly with an 8 bit bus:

[wEPac]

Hi back, thank you for your quick answer ;)

ok... you know how AliExpress is bad with description ;) this display can be set to 8 or 16 bits bus and not only for ST7796S. I shortered the R1 and removed the R2, this way it works perfectlty in 8bit and shows the poor but right RGB332 colors (tested with success with LovyanGFX and many sketches, however I would prefer to use your library that looks very neater and LovyanGFX had some tiny displaying bugs with sprites)

About the connections, I shot some pics, but for sure, the list will be neater ;)

ESP32   Display
15   -> RS	LCD register / data selection control pin (high level: register, low level: data)
4    -> WR	LCD write control pin
2    -> RD	LCD read control pin
5    -> RST	LCD reset control pin (low level reset) Also tried directly connected to 3.3 and to EN pins
GND  -> CS	LCD reset control pin (low level enable)

13   -> DB0	LCD data bus low 8-bit pin
12   -> DB1	...
14   -> DB2	...
27   -> DB3	...
26   -> DB4	...
25   -> DB5	...
16   -> DB6	...
17   -> DB7	...

32   -> BL	LCD backlight control pin (High level light)

GND  -> GND	Module power ground pin
3.3  -> VDD	Module power positive pin (5V or 3.3V, 3.3V PREFERED)

and the 'Read_User_Setup' results

TFT_eSPI ver = 2.4.72
Processor    = ESP32
Frequency    = 240MHz
Transactions = Yes
Interface    = Parallel
Display driver = 9486
Display width  = 320
Display height = 480

TFT_DC   = GPIO 15
TFT_WR   = GPIO 4
TFT_RD   = GPIO 2

TFT_D0   = GPIO 13
TFT_D1   = GPIO 12
TFT_D2   = GPIO 14
TFT_D3   = GPIO 27
TFT_D4   = GPIO 26
TFT_D5   = GPIO 25
TFT_D6   = GPIO 16
TFT_D7   = GPIO 17

TFT_BL           = GPIO 32

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled

[wEPac]

I am looking further about ILI9486 in the datasheet and the 8bit possibility. At first times, I ran a sketch with the display in 16bit, and I had, indeed, bad colors. Then I shortered the R2 and removed the R1, and the display worked perfectly in 8bit. Maybe LovyanGFX made a trick especialy for the ILI9486?

However it should be only about the init step, maybe a command to the register... because it works perfectly as well with your library soon after I do the trick with the DC pin. But I can't imagine to shorter the DC pin at begining would be that lucky to send a good command to the register ;)

Test with LovyanGFX in 8bit Parallel :

It also passed the Adafruit graphic test with success and pretty fast ;)

[Bodmer]

OK, sounds like the vendors page is wrong.

In the 'Read_User_Setup' results, the reset pin should be listed as pin 5. Looks like that is the connected yellow wire so it MUST be defined. Check your setup file is correct and includes:

#define TFT_RST 5

If that does not fix it then I would connect the CS line to a pin and define it in the setup, the display can get garbage commands if that is tied low (depending on the EMC noise in your environment).

Ideally the regulator on the board needs 5V unless you have added a bypass link on J1.

[wEPac]

OK... done, but sadly, nothing changed

What I did and tested in 3 successives steps, adding :

1. defined TFT_RST 5
2. defined TFT_CS 18 and connected to ESP32
3. moved the 3.3v wire to 5v pinout from ESP

So to be neat, I end with RST -> 5, CS ->18 and VDD -> 5v

[Bodmer]

Run Read_User_Setup again and confirm it is listed. The symptoms suggest a bad connection, replace wires.

I have just tried an ILI9486 and it is working fine, my setup file:

#define TFT_PARALLEL_8_BIT
#define ILI9486_DRIVER

// ESP32 pins used for UNO format board
#define TFT_CS   33  // Chip select control pin
#define TFT_DC   15  // Data Command control pin - must use a pin in the range 0-31
#define TFT_RST  32  // Reset pin

#define TFT_WR    4  // Write strobe control pin - must use a pin in the range 0-31
#define TFT_RD    2

#define TFT_D0   12  // Must use pins in the range 0-31 for the data bus
#define TFT_D1   13  // so a single register write sets/clears all bits
#define TFT_D2   26
#define TFT_D3   25
#define TFT_D4   17
#define TFT_D5   16
#define TFT_D6   27
#define TFT_D7   14


#define LOAD_GLCD   // Font 1. Original Adafruit 8 pixel font needs ~1820 bytes in FLASH
#define LOAD_FONT2  // Font 2. Small 16 pixel high font, needs ~3534 bytes in FLASH, 96 characters
#define LOAD_FONT4  // Font 4. Medium 26 pixel high font, needs ~5848 bytes in FLASH, 96 characters
#define LOAD_FONT6  // Font 6. Large 48 pixel font, needs ~2666 bytes in FLASH, only characters 1234567890:-.apm
#define LOAD_FONT7  // Font 7. 7 segment 48 pixel font, needs ~2438 bytes in FLASH, only characters 1234567890:.
#define LOAD_FONT8  // Font 8. Large 75 pixel font needs ~3256 bytes in FLASH, only characters 1234567890:-.
#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

#define SMOOTH_FONT

A possibility is that your display cannot handle the timing of the signals, the ILI9486 has one of the slowest displays interface timings especially during DC switching. There are extra delays that can be switched in on some signals by editing the code, and removing the // here and here.

I assume you are using the Arduino IDE.

Other than that maybe the display you have needs a slightly different init sequence but that is just a guess.

[Bodmer]

These are the test results I get for comparison, adjusting the timings with extra delays will increase the times.

TFT_eSPI library test!
Benchmark                Time (microseconds)
Screen fill              201355
Text                     6943
Lines                    80841
Horiz/Vert Lines         19037
Rectangles (outline)     10595
Rectangles (filled)      561192
Circles (filled)         58524
Circles (outline)        27296
Triangles (outline)      17925
Triangles (filled)       184878
Rounded rects (outline)  16913
Rounded rects (filled)   566528
Done!

[wEPac]

Thanks for the big help and wasted time :)

OK I m going to try every case, and see what could work. I come back when it is done to provide results, but this time... it will need little while ;)

[wEPac]

OK, I proceed tests with differents steps, once by once, with new wires :

1. changing delays in the "Processors/TFT_eSPI_ESP32.h" => none
2. changing pinouts to your settings & original delays => none
3. your settings pinout & longer delays => none

It was nice to play with delays, I looked into the code yesterday, but did not find the init sequence. However, I saw a video with the graphic Adafruit test, between TFT_eSPI and LovyanGFX, and brenchmark were pretty close, so I doubted to add delays could solve the issue, but the test has been done ;)

Sadly it seems to confirm that a slightly different init sequence is needed :S

current Read_User_Setup results :

TFT_eSPI ver = 2.4.72
Processor    = ESP32
Frequency    = 240MHz
Transactions = Yes
Interface    = Parallel
Display driver = 9486
Display width  = 320
Display height = 480

TFT_CS   = GPIO 33
TFT_DC   = GPIO 15
TFT_RST  = GPIO 32
TFT_WR   = GPIO 4
TFT_RD   = GPIO 2

TFT_D0   = GPIO 12
TFT_D1   = GPIO 13
TFT_D2   = GPIO 26
TFT_D3   = GPIO 25
TFT_D4   = GPIO 17
TFT_D5   = GPIO 16
TFT_D6   = GPIO 27
TFT_D7   = GPIO 14

TFT_BL           = GPIO 19

Font GLCD   loaded
Font 2      loaded
Font 4      loaded
Font 6      loaded
Font 7      loaded
Font 8      loaded
Smooth font enabled

[wEPac]

For info, but I do not think that could change something? The MCU I have is a WROOM-32D

I was thinking, maybe just to add some delays at the init sequence? All seems to confirm an issue at this moment, like everything working fine later, after I "played" with the DC ?

PS I m working with Arduino IDE

[wEPac]

OK, I modified a bit the code from the init part in "ILI9486_Init.h" and it is working perfect, I am doing some more test and I ll be back to tell about it ;)

[wEPac]

Right I tried, with different pinouts, and different sketches, it is working fine, but I can't try with other display or CMU, I don't have others. Would be nice to perform tests with other hardwares...

The modification is in the "TFT_Drivers/ILI9486_init.h" file, at the line 24
I comment the lines 24 and 25 about Power Control 3, 0xC2

    writecommand(0xC2);
    writedata(0x44);

to add 2 others commands about Power Control 1, 0xC0 and Power Control 2, 0xC1

    writecommand(0xC0); //                          1100.0000 Power Control 1
    writedata(0x17);    //                          0001.0111   ... VRH1
    writedata(0x15);    //                          0001.0101   ... VRH2
    writecommand(0xC1); //                          1100.0001 Power Control 2
    writedata(0x41);    //                          0100.0001   . SAP BT
    writedata(0x00);    //                          0000.0000   ..... VC
    // writecommand(0xC2);
    // writedata(0x44);

Accorded to the Datasheet, Power consumption could been reduced by setting BT for the Power Control2, till 0x70, so we could have 0x71 for the 1st data byte

Here the "User_Setup.h" for the last test with VDD to 3.3v :

#define TFT_BL   15               // LED back-light control pin

#define TFT_PARALLEL_8_BIT

// The ESP32 and TFT the pins used for testing are:
#define TFT_CS   -1  // Case Select pin, Set to GND
#define TFT_DC   02  // (RS/DC) Register Select / Data Command control pin - must use a pin in the range 0-31
#define TFT_RST  -1  // Reset pin, toggles on startup, set to EN

#define TFT_WR    4  // Write strobe control pin - must use a pin in the range 0-31
#define TFT_RD    0  // Read strobe control pin

#define TFT_D0   13  // Must use pins in the range 0-31 for the data bus
#define TFT_D1   12  // so a single register write sets/clears all bits.
#define TFT_D2   14  // Pins can be randomly assigned, this does not affect
#define TFT_D3   27  // TFT screen update performance.
#define TFT_D4   26
#define TFT_D5   25
#define TFT_D6   16
#define TFT_D7   17

#define LOAD_GLCD 
#define LOAD_FONT2
#define LOAD_FONT4
#define LOAD_FONT6
#define LOAD_FONT7
#define LOAD_FONT8
#define LOAD_GFXFF

Here the sketch "Colour_test" lightly modified :

//   Diagnostic test for the displayed colour order
//
// Written by Bodmer 17/2/19 for the TFT_eSPI library:
// https://github.com/Bodmer/TFT_eSPI

/* 
 Different hardware manufacturers use different colour order
 configurations at the hardware level.  This may result in
 incorrect colours being displayed.

 Incorrectly displayed colours could also be the result of
 using the wrong display driver in the library setup file.

 Typically displays have a control register (MADCTL) that can
 be used to set the Red Green Blue (RGB) colour order to RGB
 or BRG so that red and blue are swapped on the display.

 This control register is also used to manage the display
 rotation and coordinate mirroring. The control register
 typically has 8 bits, for the ILI9341 these are:

 Bit Function
 7   Mirror Y coordinate (row address order)
 6   Mirror X coordinate (column address order)
 5   Row/column exchange (for rotation)
 4   Refresh direction (top to bottom or bottom to top in portrait orientation)
 3   RGB order (swaps red and blue)
 2   Refresh direction (top to bottom or bottom to top in landscape orientation)
 1   Not used
 0   Not used

 The control register bits can be written with this example command sequence:
 
    tft.writecommand(TFT_MADCTL);
    tft.writedata(0x48);          // Bits 6 and 3 set
    
 0x48 is the default value for ILI9341 (0xA8 for ESP32 M5STACK)
 in rotation 0 orientation.
 
 Another control register can be used to "invert" colours,
 this swaps black and white as well as other colours (e.g.
 green to magenta, red to cyan, blue to yellow).
 
 To invert colours insert this line after tft.init() or tft.begin():

    tft.invertDisplay( invert ); // Where invert is true or false

*/
#include <SPI.h>
#include <TFT_eSPI.h>       // Hardware-specific library
TFT_eSPI tft = TFT_eSPI(320, 480);  // Invoke custom library

#define   BL_CHANNEL 0      // PWM channel for the blacklight

void setup(void)
{
  // set the blacklight
#if defined(TFT_BL)
  initBrightness();
  setBrightness(4);
#endif

  tft.init();  
  tft.setRotation(1);                     // Set the screen in Landscape
  tft.fillScreen(TFT_BLACK); 
  
  // We can now plot text on screen using the "print" class
  tft.setTextColor(TFT_WHITE, TFT_BLACK); // Set the font colour to be white with a black background
  tft.setCursor(0, 0, 4);                 // Set "cursor" at top left corner of display (0,0) and select font 4
  tft.println("Initialised default\n");
  tft.println("White text");
  tft.setTextColor(TFT_RED, TFT_BLACK);
  tft.println("Red text");
  tft.setTextColor(TFT_GREEN, TFT_BLACK);
  tft.println("Green text");
  tft.setTextColor(TFT_BLUE, TFT_BLACK);
  tft.println("Blue text");
  delay(5000);

  tft.setTextColor(TFT_WHITE, TFT_BLACK); // Set the font colour to be white with a black background
}

void loop()
{
  // Binary inversion of colors
  tft.invertDisplay(true); // Where is true or false
  tft.setCursor(0, 0, 4);
  tft.println("Invert ON                  \n");
  delay(1000);

  // Normal colors
  tft.invertDisplay(false); // Where is true or false
  tft.setCursor(0, 0, 4);
  tft.println("Invert OFF                  \n");
  delay(1000);
}

void initBrightness()
{
  const int freq        = 5000;
  const int resolution  = 8;
  ledcSetup(BL_CHANNEL, freq, resolution);
  ledcAttachPin(TFT_BL, BL_CHANNEL);
  setBrightness(4);
}
void setBrightness(uint8_t level)
{ // level from [0, 8], 0:black screen
  ledcWrite(BL_CHANNEL, 0xFF >> (8 - level));
}

[wEPac]

and... yes, a classic but still so funny

ESP32 DevKitC v4, LCD 4" ILI6486, TFT_eSPI test > 30fps

[Bodmer]

Well done for finding the solution. I will try the extra commands in my display and add them to the init sequence.

[wEPac]

Glad if that can help, the change should be secured, I looked at the difference with another driver and also at the datasheet. Thank you for the library, I m gonna play with sprites to relax :)

Best regards

[Bodmer]

I have tried my display with the following power control init sequence:

    writecommand(0xC0); //                          1100.0000 Power Control 1
    writedata(0x17);    //                          0001.0111   ... VRH1
    writedata(0x15);    //                          0001.0101   ... VRH2
    writecommand(0xC1); //                          1100.0001 Power Control 2
    writedata(0x41);    //                          0100.0001   . SAP BT
    writedata(0x00);    //                          0000.0000   ..... VC
    writecommand(0xC2);
    writedata(0x44);

And it still works fine.

Does your display work OK if the command 0xC2 setting is not commented out?

[wEPac]

With the current values for Power Control 3 (0x44) this is not working with my display. I played a bit further with the values, trying to adjust them better :

1. Power Control 1 decreased to reduce current consumption
2. Control Power 3 value increased to enhances the drivability of the step-up circuit and the quality of display

Inreasing Control Power 3 will increase current consumption, this why I tried to compensate with Power Control 1, but it was indeed working with the last values

    // Power Control 1 default values:
    //    0x0E    (Sets the VREG1OUT)
    //    0x0E    (Sets the VREG2OUT)
    writecommand(0xC0); //                          1100.0000 Power Control 1
    writedata(0x0E);    //                          0000.1110   ... VRH1
    writedata(0x0E);    //                          0000.1110   ... VRH2
    //writedata(0x17);    //                          0001.0111   ... VRH1
    //writedata(0x15);    //                          0001.0101   ... VRH2
    
    // Power Control 2 default values:
    //    0x60    (step-up factor for the operating voltage / adjust the constant current)
    //    0x00    (VCI1 regulator output voltage 3.3v)
    writecommand(0xC1); //                          1100.0001 Power Control 2
    writedata(0x41);    //                          0100.0001   . SAP BT
    writedata(0x00);    //                          0000.0000   ..... VC
    
    // Power Control 3 default value:
    //    0x33    (Step-up cycle for step-up circuit)
    // The higher step-up operating frequency enhances the drivability of the step-up circuit
    // and the quality of display but increases the current consumption
    writecommand(0xC2); //                          1100.0010 Power Control 3
    writedata(0x55);    //                          0101.0101   . DCA1 . DCA0
    //writedata(0x44);    //                          0100.0100   . DCA1 . DCA0

So for Power Control 3, changing 0x44 -> 0x55 is enough for my display to work

REF http://www.lcdwiki.com/res/MRB3503/ILI9486_Datasheet.pdf
page 237 - 242

[Bodmer]

Thanks I have updated the Github master with these settings:

    writecommand(0xC0); //                          1100.0000 Power Control 1
    writedata(0x0E);    //                          0001.0111   ... VRH1
    writedata(0x0E);    //                          0001.0101   ... VRH2
    writecommand(0xC1); //                          1100.0001 Power Control 2
    writedata(0x41);    //                          0100.0001   . SAP BT
    writedata(0x00);    //                          0000.0000   ..... VC
    writecommand(0xC2); //                          1100.0010 Power Control 3
    writedata(0x55);    //     nb. was 0x44         0101.0101   . DCA1 . DCA0

[PJ5168]

These are the test results I get for comparison, adjusting the timings with extra delays will increase the times.

TFT_eSPI library test!
Benchmark                Time (microseconds)
Screen fill              201355
Text                     6943
Lines                    80841
Horiz/Vert Lines         19037
Rectangles (outline)     10595
Rectangles (filled)      561192
Circles (filled)         58524
Circles (outline)        27296
Triangles (outline)      17925
Triangles (filled)       184878
Rounded rects (outline)  16913
Rounded rects (filled)   566528
Done!

Dear Sir,

I am using ESP32 Uno and ILI9486 shield in 8-bit mode.
Got the same results as yours.
But, tested other ESP32+ST7796 in 8-bit mode and the testing time is only about 1/3.
Is ST7796 three times faster than ILI9486? Or, is there any way to set a faster operation speed for ESP32+ILI9486 8-bit?
Thank you,

PJ.

[thesunRider]

Can someone please provide pin connections for NodeMCU-12s (Esp8266) and an ILI9486 parallel bus display.
The display looks like below: