UNO R4 WIFI : 3.5" TFT LCD Shield white screen

Hello, I found this topic but despite the installation of the forked library of ZinggJM and the modification of the display line in the example code shared on the forked repository, nothing appear on my screen, who's staying completely white.

The screen is a 3.5" TFT LCD Shield, ILI9486, 8bit bus with touchscreen (this one), bought on amazon (if you can open the link)

I use a arduino R4 wifi

here the code i upload to the board without error :

#include <Arduino_GFX_Library.h>

#define GFX_BL DF_GFX_BL

Arduino_DataBus *bus = new Arduino_UNOPAR8();
Arduino_GFX *gfx = new Arduino_ILI9486(
  bus, 7 /* RST */, 0 /* rotation */, false /* IPS */);

void setup() {
  Serial.begin(9600);
  // Serial.setDebugOutput(true);
  // while(!Serial);
  Serial.println("Arduino_GFX Hello World example");

#ifdef GFX_EXTRA_PRE_INIT
  GFX_EXTRA_PRE_INIT();
#endif

  // Init Display
  if (!gfx->begin())
  {
    Serial.println("gfx->begin() failed!");
  }
  gfx->fillScreen(BLACK);

#ifdef GFX_BL
  pinMode(GFX_BL, OUTPUT);
  digitalWrite(GFX_BL, HIGH);
#endif

  gfx->setCursor(10, 10);
  gfx->setTextColor(RED);
  gfx->println("Hello World!");

  delay(5000); // 5 seconds
}

void loop() {
  gfx->setCursor(random(gfx->width()), random(gfx->height()));
  gfx->setTextColor(random(0xffff), random(0xffff));
  gfx->setTextSize(random(6) /* x scale */, random(6) /* y scale */, random(2) /* pixel_margin */);
  gfx->println("Hello World!");

  delay(1000); // 1 second
}

i got this output in the Serial Monitor and nothing else :

23:05:14.031 -> Arduino_GFX Hello World example

If i could find a working programs with the same device it would be awesome, to check if the screen work and finally understand how the lib work if i made a mistake.

@youstones, hi, welcome to the forum!

You no longer need to use my fork, as the official and released version of Arduino_GFX now also supports these shields on both Arduino UNO R4 version. Available in Library Manager as GFX Library for Arduino.

Unfortunately, this library doesn't support read from displays, so you can't check for the controller used. And there are different controllers used and conflicting information:

Specification:
Option: with touch screen, without touch screen
Input voltage: DC 2.8~3.3V
Disc IC: ILI9486 / ILI9488L
Screen Size: 3.5 inches
Screen material: TFT
Resolution: 320x480
Pin Module: 28 pin (8 + 8 + 6 + 6)
Touch length Pen: 8.8cm/3.46in
Module size: 8.5 x 5.5 cm / 2.17 x 3.35 in
Weight: approx. 55g / 1.9oz

Driver IC ILI9486/ST7796

So you would need to try with different controllers.

If you have an Arduino UNO R3 (or any of the Atmega328 UNO versions), you could try with the library MCUFriend_kbv. It has an example to read the controller ID: LCD_ID_readreg.ino
(I would suggest to buy a classic UNO for such tests.)
-jz-

2 Likes

Thanks for your quick reply !

I thought the display was a ILI9486 because the sticker on the box mentionned it, but the other displays are worth a shot. if it doesn't work then i'll try to get another board

@ptillisch , hi, could you please give my pull request
https://github.com/arduino/uno-r4-library-compatibility/pull/25
a push?
Thank you.

1 Like

Hi @ZinggJM. I don't have any involvement or privileges in that particular repository. Maybe @Hans7 can help.

1 Like

PR merged! Thanks for the update @ZinggJM.

2 Likes

hello !

i managed to make it work with ILI9488 and then later with ILI9486 like my previous code for strange reason. But now i'm wondering if i can use cable to use unused pin by the lcd to add button, led, etc but the screen stay white again, even with the unused pin connected to the screen. Do i really need to plug the lcd in the board or one or more of my cables are faulty ?

First, retest with connected directly. Then maybe try with very short cables.
You may have ringing when used with cables. Write pulse is rather short with this bus driver.
I would buy a proto-shield and add long-tail headers. Then you can add connections to the proto board.

1 Like

Sorry, I don't use this library and the like, I have typically used Adafruit libraries and/or have worked on some other versions for the Teensy.

But I know some displays can be tricky to get to work reliably using cables, especially depending on the quality of the connections and the length.

As @ZinggJM mentioned, try ringing out all of the connections, I often use a simple program that sets all of the IO pins state to Input PU (or on some boards optionally PD, but these don't support that), The code then simple cycles looking for pins that change state, and I use a simple wire from ground, and touch the different pins, like at the display and see if it registers the correct IO pin number...

Also I don't know what the clock speed is set to for SPI? You might try lowering it and see if that helps.

Is there anything else connected up to the SPI pins? If so do they all have external Pull up resistors on their Chip select pins? If not you may need to have your sketch set them all to output and initialized to high before you initialize the display.

Side note: in the several decades I have done c/c++ code, I don't think I have ever used the new operator outside of a function, like setup.

I am not saying it won't work, just that I have never done it and as such have no idea.

If I wanted those object pointers to be global, I would typically declare the pointers global, maybe assigned a nullptr, and then do the new operator within setup()..

Good luck

1 Like

Please note that this topic is related to MCUFriend kind of 8 bit parallel shield for Arduino UNO.

I used "ringing" for ringing signals on a wire, caused by reflections. English is not my native language, but I think I've seen this term used in this sense.
-jz-

It is perfectly legal C++ use. But I also had to accept this kind of use by this library.
And it is easy to adapt to commonly used code by then declaring:

Arduino_GFX& display(*gfx);

Sorry, just used my generic suggestions for display issues... So that part would not apply:

From: Bell tester, ringing out a wire | Electrician Talk

Traditionally a couple of dry cells were wired in series with a doorbell and connected in the circuit. When you went to the terminus you would touch the circuit conductors and the bell would ring. Hence the term "ringing out" the circuit. This just a take off on the doorbells used in old homes.

Here is a version of the sketch I mentioned...

#define digitalWriteFast digitalWrite
#define digitalReadFast digitalRead
//#endif
void setup() {
  Serial.begin(115200);
  while (!Serial && millis() < 10000 );
  //Serial.println("Compile Time:: " __FILE__ " " __DATE__ " " __TIME__);
  Serial.print("Num Digital Pins: ");
  Serial.println(NUM_DIGITAL_PINS, DEC);
  Serial.flush();

  testForShorts();
  
}

void loop() {
    allPinTest( );
}

uint32_t pinLast[NUM_DIGITAL_PINS];
void allPinTest() {
  uint32_t ii;
  Serial.print("PULLUP Start Vals:\n  ");
  Serial.print("PULLUP :: TEST to GND\n  ");
  for ( ii = 0; ii < NUM_DIGITAL_PINS; ii++) {
    pinMode( ii, INPUT_PULLUP );
    delayMicroseconds( 5 );
    pinLast[ii] = digitalReadFast( ii );
    if (!pinLast[ii]) {
      Serial.print("\nd#=");
      Serial.print( ii );
      Serial.print( " val=" );
    }
    Serial.print( pinLast[ii] );
    Serial.print(',');
  }
  Serial.println();
  Serial.println();
  while ( 1 ) {
    uint32_t jj, dd = 0, cc = 0, ee=4;
    cc = 0;
    for ( ii = 0; ii < NUM_DIGITAL_PINS; ii++) {
      jj = digitalReadFast( ii );
      if ( jj != pinLast[ii] ) {
        dd = 1;
        cc++;
        pinLast[ii] = jj;
        Serial.print("d#=");
        Serial.print( ii );
        if ( pinLast[ii] ) Serial.print( "\t" );
        Serial.print( " val=" );
        Serial.print( pinLast[ii] );
        Serial.print(',');
      }
      if ( cc > 1 && ee ) {
        Serial.println(">>> MULTI CHANGE !!");
        ee--;
      }
    }
    if ( dd ) {
      dd = 0;
      Serial.println();
      delay( 50 );
    }
  }
}

void testForShorts() {
  uint32_t ii;
  Serial.print("Quick Test for Shorts to adjacent pin");
  Serial.println("UNOR4 does not support INPUT_PULLDOWN");
  Serial.println("\n Now try Pull up and see if setting low follow");
  for ( ii = 0; ii < NUM_DIGITAL_PINS-1; ii++) {
    pinMode( ii+1, INPUT_PULLUP );
    pinMode( ii, OUTPUT);
    digitalWrite(ii, LOW);
    delayMicroseconds( 5 );
    if (!digitalRead(ii+1)) {
      Serial.print(ii,DEC);
      Serial.print(":");
      Serial.println(ii+1, DEC);
    }
  }
  Serial.println();  
}

1 Like

https://en.wikipedia.org/wiki/Ringing

1 Like

Okay i know think there is a problem with the connection or the lcd, because sometimes it work, sometime no, in direct plug. I got a case where the setup() would be display, but then fade out to pure white at the end, not displaying the loop nor the setup(). I'm really confuse about it, the monitor doesn't give any error. I think i'm gonna try to let it unplug for a while, hoping to "reset" I don't know what.

I used "ringing" for ringing signals on a wire, caused by reflections. English is not my native language, but I think I've seen this term used in this sense.

i'll investigate that, it seems a good idea

As @ZinggJM mentioned, try ringing out all of the connections, I often use a simple program that sets all of the IO pins state to Input PU (or on some boards optionally PD, but these don't support that), The code then simple cycles looking for pins that change state, and I use a simple wire from ground, and touch the different pins, like at the display and see if it registers the correct IO pin number...

hmmm i tried the sketch and the pin react really quickly when using short hard metal cable (the one of the breadboard, i forgot their name if they have one) and the same happen for the long cable, but i've already found one who doesn't work so i'm gonna try every one of them

I have one TFT that also had this issue. For this display I had to use a slightly stretched WR pulse.
Unfortunately this stretching got lost on an update of the bus driver class, on a cleanup by the maintainer of the library. I re-tested with the new release, and didn't see the issue. So it may be intermittent. But I have no time to re-test that now.
-jz-

1 Like

I understand, but can i have a idea of in which file was the modification ? Hoping i don't bother you too much ^^

Take a look at the history of https://github.com/ZinggJM/Arduino_GFX/blob/master/src/databus/Arduino_UNOPAR8.cpp

https://github.com/ZinggJM/Arduino_GFX/commit/42e9d41e6b0c792d33b402682525fbe0fe12a088

I re-tested release 1.4.0 with Arduino UNO R4 Minima and WiFi with my ILI9486 UNO shield.
Both didn't show the issue I had back in September with my original Arduino_UNOPAR8 version.

But I chose to create a variant class Arduino_UNOPAR8_WRS with slightly stretched write pulse anyway.
I think this is a clean solution. This alternative variant can be used should the issue show up.
-jz-

I will check this, but like the last time, after a long time without being powered (here the night) the lcd work like a charm, no white screen, with the same sketch i upload the day before. I hope the variant you shared work if i reproduce the "error" i got who produce white screen (i really thank you to take time on this topic, i'm really grateful).

I have the code in the first post working on Arduino Uno R4 Minima + £12 Amazon ILI9486 after changing the reset pin from 7 to 18 thusly:
Arduino_GFX gfx = new Arduino_ILI9486(
bus, 18 /
RST /, 1 / rotation /, false / IPS */);

Using ArduinoIDE-managed GFX Library for Arduino by Moon On Our Nation.

Hello, I'm new to Arduino and am encountering an issue. I have a 3.5-inch TFT LCD display, but I'm uncertain of its exact model number (ILI9486, ILI9488L, etc.) or whether it includes touch functionality. I've installed the GFX library for Arduino, which I understand has been updated to support this display. However, when I upload the PDQgraphictest file to my R4 WIFI board, I only see a white screen. I've reviewed the forum pages where you've provided solutions, but I'm having difficulty understanding the specific changes I need to make. Could you please explain them in a simpler manner? I hope I'm not being overly demanding.