[SOLVED] Getting the ST7735 to work with Spark

no no and no… I rewired, recompiled, shorten the wires… it will not work. BUT, one time I got the text to display for half a second after a power cycle and the screen went white again. I haven’t been able to reproduce it though. I do have my 10K resistor between RST and 3V3. I removed any other components and kept the code to the sample provided by peekay123.

I’m pretty sure it’s reset or initialization problem. It’s unbelievable…

How about this as a test:

  • Add a delay in setup() of say 10 seconds so you have time to work.

  • Now when the core is in this delay, take a jumper and bring the display’s reset pin low (to ground) for one second.

  • Now wait for the rest of the program run and see if you get anything on the display.

The LCD controller data sheet on page 66 says it needs a 10ms reset pulse if the power is not applied just right (there are two VDD pins that need to be ordered).

You could also try a big-ish electrolytic capacitor and a 0.1uF ceramic cap across the LCD power and ground.

You could also try adding an electrolytic cap to the reset line so it held low while power is coming up.

Hang in there! We’ll figure it out!

2 Likes

Hello @bko, thanks for jumping in. I need Prozac! :cry:

here is what I have done. I turn the D7 LED on at the beginning of the setup and turn it off after 10sec so I know when I am in that “wait” phase.

While in there, I plug the RST pin of the TFT to the GND for a second or two… Then put the 10K resistor back in place between the RST and 3V3 to have a pull-up on it.

Then I see my D7 go off… and… nothing. The TFT stays lit up white.

Tried a 0.1uF ceramic cap (104) on the LCD power and GND but didn’t do much.

As I was trying all this it did once display the text for 0.5sec and turned back white. Raging!!

We are feeling with you :weary:

With @peekay123 and @bko on board you’ve got the best trying to assist.

It IS puzzling :confounded:


As for the pull-up, you can leave it in place while pulling the pin low. That’s the whole point of pull resistors - to provide a defined state while there is no other signal, but not to (or very little) interfere with other dedicated signals.

Not to go against @peekay123 's advice to NOT connect RST to the Core, but since we are somehow groping in the dark and can’t test it without the board, you could again attach the RST to an A pin, but this time without “telling” the library (leave the pull-up in place).
This way you could try several combinations and timings for the RST signal against your TFT code.
As Paul pointed out, the RST logic might well be inverted.
If you whip up a test code where you can set the RST procedure and timing via a Spark.function or Serial, you might be able to test a lot of combos without having to reflash permanently.

Sorry for not being more of a help here :disappointed:

1 Like

I have no way of testing this, but try this code

I’ve ignored my own advice and purposely chosen D7 as reset pin, to have some visual feedback of what’s going on on the reset line.

This buils on the Web IDE (which uses the ST7735 lib version that uses 0 as NO_RST_PIN value)

// This #include statement was automatically added by the Spark IDE.
#include "Adafruit_ST7735/Adafruit_ST7735.h"


#define cs   A2
#define dc   D6
#define rst  D7


//#include "Adafruit_GFX.h"    // Core graphics library
//#include "Adafruit_ST7735.h" // Hardware-specific library
//#include "glcdfont.h"


Adafruit_ST7735 tft(cs, dc, 0); // hardware SPI / no RST

unsigned long ms;
bool retry = true;

int resetLevel = 0xAAAA;  // let pull resistor do its job
uint resetTime = 50;

void setup() 
{
    pinMode(rst, INPUT); // ensure to have high impedance 

    Serial.begin(115200);
    ms = millis();
    
    
    Spark.function("SetTFT", setTFT);
    
    while(!Serial.available() && (millis() - ms) < 5000)
        SPARK_WLAN_Loop();
}

void loop() 
{
    if(retry)
    {
        doTFT();
        retry = false;
    }
}

void doTFT()
{
    if (resetLevel == LOW || resetLevel == HIGH)
    {
        digitalWrite(rst, !resetLevel);
        delay(resetTime);
        digitalWrite(rst, resetLevel);
        delay(resetTime);
        digitalWrite(rst, !resetLevel);
    }
    
    tft.initR(INITR_BLACKTAB); //for the ST7735R, otherwise would be initB for the B version

    tft.fillScreen(ST7735_BLACK);

    tft.setCursor(0, 0);
    tft.setTextColor(ST7735_WHITE);
    tft.setTextWrap(true);
    tft.print("Paul and Brian are the real Geniuses!!");
    tft.setCursor(3, 0);
    tft.print(millis());

    tft.drawLine(0, 0, tft.width()-1, tft.height()-1, ST7735_YELLOW);
    tft.drawLine(tft.width()-1, 0, 0, tft.height()-1, ST7735_YELLOW);

    tft.drawPixel(0, tft.height()/2, ST7735_GREEN);
}


int setTFT(String cmd)
{
    int result = 0xAA;
    int x = cmd.toInt();
    
    if(x > 0)
    {
        result = 
        resetTime = x;
    }
    else if (cmd == "LOW")
    {
        resetLevel = LOW;
        pinMode(rst, OUTPUT);
        digitalWrite(rst, !resetLevel);
        result = 0;
    }
    else if (cmd == "HIGH")
    {
        resetLevel = HIGH;
        pinMode(rst, OUTPUT);
        digitalWrite(rst, !resetLevel);
        result = -1;
    }
    else
    {
        pinMode(rst, INPUT);
        result =
        resetLevel = 0xAAAA;
    }
    
    retry = true;
    return result;
}

BTW: Are you running the TFT on 3V3 or on 5V now?

@ScruffR and @apassemard, please get the latest code from the repo as I found the compiler was not producing the results I expected for the reset pin logic. I fixed that with a #define NO_RST_PIN for the correct pin value. So to NOT use a RST pin, you make the pin value NO_RST_PIN. :smile:

@ScruffR, earlier in the topic I asked @apassemard to power the board from the Vin pin, having some concerns over the amount of power draw on the 3.3v pin. There is an onboard 3.3v regulator that he set the jumper for. I do, however, notice that he is powering the LEDs from the 3.3v line.

1 Like

It might well be a power issue too.
As I said I had a similar problem with a TFT turning white and hanging till I power-cycled it (since I also had no RST pin ;-)), when inserting an SD card in the on-board slot.
The reason was a very short voltage drop, which I could overcome with a cap - just as @bko already suggested.

So when Antony ( @apassemard ) says he sometimes gets a good result which then disappears, without obvious reason (since loop() is empty), it might well be an electrical issue.

Antony, how are you powering the Core?
Could you try a power supply >= 1000mA?

1 Like

@ScruffR, I agree. A CHEAP USB power source has been shown over and over to cause problems. Using a quality supply like an Apple charger or similar unit is a good start.

1 Like

@ScruffR I used your code but wonder about a possible typo in the following “if” statement: Looks like reserLevel should be HIGH no?

As is it didn’t do much, so I started adding some delays here and there, and also serial outputs so I could track things a bit. I go HIGH, I go LOW, and I see the little D7 LED do it’s thing but not output on the display.

The interesting thing is that randomly (and not often), I will see the text appear on the screen for a fraction of a second and it goes back to white right after. So something is happening.

To answer your question about voltage, I unsoldered the J1 on the board and reverted to a 5V input to VCC. I do power the LED with 3.3V, I actually tried 5V as the datasheet said it supports it (I think) and it just makes the screen brighter.

I power the Spark from my mac USB directly, but I switched to a USB power supply that outputs 2A to try as well. Same results. It’s from an Android device.

I’ll keep trying, it’s encouraging to see the screen pop to life from time to time, even rarely. I’m wondering if the display may be defective as well…

@peekay123 I grabbed the new version in the repo and tried it as is (just changing DC to D6) and compiled but it didn’t work.

It happened again. I resetted the spark entirely… Moved my DC pin to D0 to be able to use Peekay123’s code without any changes. I compiled, once, nothing, I compiled a second time and the screen flashed some text for 0.5 sec or so and went back white.

I think the display has an issue honestly… I should receive a couple new ones in the next couple of weeks. I’m giving up on this one. It should work… this is not normal.

oh… THIS is an interesting one… Desperate, I put the VCC of the display on 3.3V instead of 5V, and got the code to display text and WORK!!

was I wrong thinking that when the jumper is shorted it uses 3.3V, and not shorted it uses 5V??

This doesn’t look shorted to me…

@apassemard, you are correct, it does NOT look shorted! According to the schematics, shorted bypasses the onboard regulator allowing 3.3v as Vcc. So either the regulator is damaged, explaining a few things, or there enough of a short to bypass the regulator. I am just freaking glad it works! :stuck_out_tongue:

1 Like

ME TOO!!! This was just driving me nuts!! :stuck_out_tongue_winking_eye:

I’ve hooked up the DHT_22 and have been compiling a bunch of code without any issue so far… My project can move along now!!

Big THANKS!!! to @peekay123 and @ScruffR and @bko

3 Likes

That’s a typical copy-paste mistake, sure it should be HIGH :blush: (Edit: corrected)

Glad to hear, you got it working again :+1:


Could you please summarise the combined problems in a quick post for drivers by?

I have bought one of these ‘cheap’ TFT displays with a ST7735B controller that appears to be exactly the same as your pictures. I have tried all the things in the thread above and I always see a white screen and nothing else. I have reached the conclusion the display is defective. Posting the code here if you might spot some mistake from your efforts to solve the problems with this type of display.

#define cs A2
#define dc D6
#define rst 0

Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst); // hardware spi

Update on this is that I received a ‘quality’ adafruit ST7735 display. With the defines above it still did not work. I have now inserted values directly into the tft object creation and this works. I am relieved to get this working, but can anyone explain why this is the case.

Adafruit_ST7735 tft = Adafruit_ST7735(A2, D6, 0); // hardware spi

What library and what application code do you use?

Is it a sample? Which?
or
Is it your own code? Please show.

I am using/including the Adafruit_ST7735 library from the Web IDE and had copied the example code. Rather than me reproducing it here you should see the same in the library.

I am including:

// This #include statement was automatically added by the Particle IDE for the TFT display
#include “Adafruit_ST7735/Adafruit_ST7735.h”

I have experienced this problem before with setting pinMode where if I use a #define relay D7 it does not work and if I use int relay = D7; if does.

Hmm, that’s odd if only the defines make the difference.

It should and did work, but one contributing factor could be that A2, D0 and D7 are #defines themselves and so the preprocessor would need to resolve multiple “layers” - maybe there was some change in the buildfarm that causes this behaviour now (ping @Dave)

Meanwhile could you try this, if this proves me right or wrong

#define relay 07
#define cs    12
#define dc    06
#define rst    0

This removes the need for double resolve (just for testing, since it’s not considered good style, so don’t use in production code ;-))

To avoid wasting precious RAM use const int relay = D7;


On the other hand, when I try this code things work as expected

#define relay D7
#define cs A2
#define dc D6
#define rst 0

char msg[255];
float x = 3.1415;

void setup()
{
    Serial.begin(115200);
    
}

void loop()
{
    sprintf(msg, "%2d\t%2d\t%2d", relay, cs, dc);
    Serial.println(msg);
    delay(1000);
}

On Web IDE (Particle Build) - are you using this too?

A possible other reason could be found in these threads
[Solved] PinMode in Object Constructors/Functions?
Why does this code compile properly, but make my Core flash red?

1 Like

I am using the Web IDE.
I tried with first suggestion above #define cs 12 etc. - that worked.
Then I tried #define cs A2 etc. - that worked and it didn’t before.

I will look in the other threads as you suggest - thanks for your advice.

2 Likes

Hello all,

I had the exact same problem reported by a bunch of people in different thread ( text displayed 1 time on 10…) most of the time the display turn and stay white. I’ve a 1.44" TFT display from adafruit (model 2088). After hours trying to figure what the problem is … using hardware reset fix the problem. @peekay123 I know you you suggest to use swReset but look unusable for some devices?

I use a fork of original Spark port from peekay123 (merged with latest Adafruit::ladyada libs supporting the 1.44" display )

I have a Particle Photon to drive the display.

PS. I’m completely new here, first post and newbie with electronic too (I’m not a developper neither…)

1 Like