Display issue: Random white lines, color/image shift

[dexter323i]

Hi!

First, thank you for your awesome library. It is a HUUGE help for my ESP32 projects!
I have a strange problem:
I made a Sim racing telemetry display years ago. It is using an ESP32 WROVER 16MB, a 3.5inch IPS display with R61529 driver IC, and capacitive touch, 8 bit parallel interface. I know it is not supported officially, but pull request #2715 just works flawlessly. I mean it worked...
I decided to switch from capacitive touch to physical buttons, so I ordered the same display panel, but without a touch a layer. It supposed to be same, but it isn't. Actually I ordered multiple pieces of it, and they all have the problem, but in different severity. Some are mostly ok, but others has serious defects.

E.g.: This screen should be totally black, with an orange "Starting..." text on it.

The white lines appear randomly on the panels. Some have more, some have less, and some have one or two only.

On this screen the "5" at the bottom right is broken in half, and it has some extra white lines. The very bottom bar should be red and green, and should consist of equal squares.

I cannot even describe this one. Look at the three top boxes: Random white lines, line shift, color shift, ghost images of previous text

I use sprites, and only refresh parts of the screen, where values changed. A refresh fixes the error, except when it intorduces new ones, and the next refresh fixes it again.

When I attach the old display (with capacitive touch layer), then everything works perfectly, they show no issue at all. Just these new touchless batch of IPS display panels have problems.

Do you have any idea what the problem could be? What should I try to change in the code? I use latest master branch, with #2715 applied to it.

Has anyone experienced similar problem before?

My user setup:

#define USER_SETUP_INFO "User_Setup"
#define DISABLE_ALL_LIBRARY_WARNINGS

//#define ILI9341_DRIVER
#define R61529_DRIVER
#define ESP32_PARALLEL

// Pins
#define TFT_CS  4
#define TFT_DC  14
#define TFT_RST 32
#define TFT_WR  13
#define TFT_RD  -1

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


#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

Dexter

[dexter323i]

Can I lower the communication frequency? If yes, what is the setting name, and what is the default value? I use 8 bit parallel not SPI, so I guess SPI_FREQUENCY is not applied here.

[Basitadam]

You can try with lower CPU core frequencies. If it fixes the issue you, then can dive into slowing down the parallel write commands

[dexter323i]

@Basitadam thanks for you recommendation!

Well, the story goes on. We wrote a messages to the IPS panel supplier as well, and this is his answer:
"Our engineer say that maybe the problem is capacitance withstand voltage value problem."

And then it hit me: Years ago, when I checked the diplay panel's pinout, it said pins 6 and 7 should get 2.8V max. And I was like WTF, it is nonsense! I have 3.3V ESP32, I won't supply 2.8V to VCC pins, all data pins, etc. I tried it with 3.3V, and it worked no problem, so the circuit stayed 3.3V.

Maybe it was a mistake. What others do with this 2.8V VCC line? What is the best method for it? What about the data lines? Should they be adjusted too?

[Basitadam]

I don't think the problem is with the capacitor voltage rating. Most common DC voltage for a standard capacitor are 2.5V and then 4V and above. So 2.8 or 3.3V won't matter.
As for the supply voltage, IMO maybe. Try supplying voltage to pins 6 and 7 with a series diode (like 1N4148) connected to 3.3V. (Not to the backlight. 4148 will fry). Most of the signal inputs has diodes connected (in reverse) to Vcc and GND, so signal lines can stay at 3.3V HIGH level. And for the LOW level below, 0.4-0.8V is considered LOW most of the time. So, OK.
I hope, but I don't think 2.8V thing will solve the issue

[dexter323i]

@Basitadam sorry for the late reply. I didn't have the bad display with me, I had to wait until it arrives. Now I can test it.
So, you are right! 2.8V VCC did nothing at all, but CPU frequency... Quite much!

    tft.setRotation(3);
    tft.setTextDatum(TL_DATUM);
    delay(3000);
    
    while(true){
        tft.fillScreen(TFT_BLACK);
        delay(1000);
        tft.fillScreen(TFT_BLUE);
        delay(1000);
    }

240MHz video: https://drive.google.com/file/d/1QxTCyAqokeKE5Q3xPiNEjfft_4Z5ySnc/view?usp=sharing
160MHz video: https://drive.google.com/file/d/1QtjWiM4sIEpgq_ku-BDzww44F7cHHd3s/view?usp=sharing

Can you give me some pointers, how to slow down the parallel communication towards the screen?

[Basitadam]

Nice catch.
Can you send your R61529_DRIVER files? I don't have them in my library.
And your MCU is ESP32 right? Not -S2, -S3, etc..

[dexter323i]

Yes, yes! Good old ESP32-WROVER-E MGN16R8 (Not S3 not S3)
The driver files are in this PR commit (see my original post): 2fdaecd

TYIA!

[Basitadam]

I can't really test but this should slow down writes. If the problem is with the delay between RD, WR, CS or OE signals and data signals, more work will be needed:
in TFT_eSPI_ESP32.h file add this:

   for(volatile uint32_t DirtyDelay=0; DirtyDelay<1000; DirtyDelay++) { DirtyDelay++};

Should go somewhere here (might differ from version to version):

You can increase 1000 value if needed

[dexter323i]

Okay, thank you I got it!

Actually, this is not good in this form, so I used this instead
for(volatile uint32_t dd=0; dd<3; dd++);
The 1000 is waaay way too many between each pixels. 1 is much better than nothing, 2 is even better, and with 3 I only see some bad pixels here and there. That would be acceptable, if it didn't take too long to refresh the whole screen. Here are my measurements in micro seconds:

• 240MHz no delay: 46452
• 160MHz no delay: 58301
• 240MHz delay 1: 69638
• 240MHz delay 2: 83179
• 240MHz delay 3: 96791

It takes more than double to refresh the screen!

I checked, and most of the drawing functions use tft_Write_16(C) and not tft_Write_8(C), so I modified these too:

But this is not enough! There was also a trick hidden in the TFT_eSPI::pushBlock(uint16_t color, uint32_t len) function

if ( (color >> 8) == (color & 0x00FF) )
{ 
  tft_Write_16(color);
  while (--len) {WR_L; WR_H; WR_L; WR_H;}
}
else while (len--) {tft_Write_16(color);}

If we want to draw with the same 16 bit color on all the pixels (e.g. drawing a rectangle, or filling the screen), and the upper and lower bytes matches in the 16 bit color, then we only write the color once, and then we only flip the "pixel pointer pin" up and down as many times as many pixels we have in the rectangle. Clever, but it made drawing black and white colors super duper ultra fast, which is the reason originally why I had the black screen fill much more worse, than simply writing numbers, and drawing images.

Anyway thank you so much! I say these displays are faulty, beacuse they cannot handle the required refresh rate.