Unable to initiate st7789 on Wemos D1 mini ESP8266

[Mearntain]

OVERVIEW:

1. Can not get tft_espi to work with my esp8266 wemos d1 mini and adafruit 135x240 st7789. Works just fine with adafruit library.
2. Arduino 2.0.4
3. TFT_eSPI library version 2.5.0
4. Board package version 3.1.2 (esp8266)
5. ESP8266 Wemos D1 Mini
6. TFT driver - st7789
7. Interface type SPI - sclk to D5, mosi to D7, cs to D8, rst to D4, DC to D3

I just want to run any basic example - display an image

User_Setup.h:

//                            USER DEFINED SETTINGS
//   Set driver type, fonts to be loaded, pins used and SPI control method etc
//
//   See the User_Setup_Select.h file if you wish to be able to define multiple
//   setups and then easily select which setup file is used by the compiler.
//
//   If this file is edited correctly then all the library example sketches should
//   run without the need to make any more changes for a particular hardware setup!
//   Note that some sketches are designed for a particular TFT pixel width/height

// User defined information reported by "Read_User_Setup" test & diagnostics example
#define USER_SETUP_INFO "User_Setup"

// Define to disable all #warnings in library (can be put in User_Setup_Select.h)
//#define DISABLE_ALL_LIBRARY_WARNINGS

// ##################################################################################
//
// Section 1. Call up the right driver file and any options for it
//
// ##################################################################################

// Define STM32 to invoke optimised processor support (only for STM32)
//#define STM32

// Defining the STM32 board allows the library to optimise the performance
// for UNO compatible "MCUfriend" style shields
//#define NUCLEO_64_TFT
//#define NUCLEO_144_TFT

// STM32 8 bit parallel only:
// If STN32 Port A or B pins 0-7 are used for 8 bit parallel data bus bits 0-7
// then this will improve rendering performance by a factor of ~8x
//#define STM_PORTA_DATA_BUS
//#define STM_PORTB_DATA_BUS

// Tell the library to use parallel mode (otherwise SPI is assumed)
//#define TFT_PARALLEL_8_BIT
//#defined TFT_PARALLEL_16_BIT // **** 16 bit parallel ONLY for RP2040 processor ****

// Display type -  only define if RPi display
//#define RPI_DISPLAY_TYPE // 20MHz maximum SPI

// Only define one driver, the other ones must be commented out

#define ST7789_DRIVER      // Full configuration option, define additional parameters below for this display

// Some displays support SPI reads via the MISO pin, other displays have a single
// bi-directional SDA pin and the library will try to read this via the MOSI line.
// To use the SDA line for reading data from the TFT uncomment the following line:

// #define TFT_SDA_READ      // This option is for ESP32 ONLY, tested with ST7789 and GC9A01 display only

// For ST7735, ST7789 and ILI9341 ONLY, define the colour order IF the blue and red are swapped on your display
// Try ONE option at a time to find the correct colour order for your display

//  #define TFT_RGB_ORDER TFT_RGB  // Colour order Red-Green-Blue
  #define TFT_RGB_ORDER TFT_BGR  // Colour order Blue-Green-Red

// For M5Stack ESP32 module with integrated ILI9341 display ONLY, remove // in line below

// #define M5STACK

// For ST7789, ST7735, ILI9163 and GC9A01 ONLY, define the pixel width and height in portrait orientation
 #define TFT_WIDTH  135
 #define TFT_HEIGHT 240 

// For ST7735 ONLY, define the type of display, originally this was based on the
// colour of the tab on the screen protector film but this is not always true, so try
// out the different options below if the screen does not display graphics correctly,
// e.g. colours wrong, mirror images, or stray pixels at the edges.
// Comment out ALL BUT ONE of these options for a ST7735 display driver, save this
// this User_Setup file, then rebuild and upload the sketch to the board again:

// #define ST7735_INITB
// #define ST7735_GREENTAB
// #define ST7735_GREENTAB2
// #define ST7735_GREENTAB3
// #define ST7735_GREENTAB128    // For 128 x 128 display
// #define ST7735_GREENTAB160x80 // For 160 x 80 display (BGR, inverted, 26 offset)
// #define ST7735_ROBOTLCD       // For some RobotLCD arduino shields (128x160, BGR, https://docs.arduino.cc/retired/getting-started-guides/TFT)
// #define ST7735_REDTAB
// #define ST7735_BLACKTAB
// #define ST7735_REDTAB160x80   // For 160 x 80 display with 24 pixel offset

// If colours are inverted (white shows as black) then uncomment one of the next
// 2 lines try both options, one of the options should correct the inversion.

// #define TFT_INVERSION_ON
// #define TFT_INVERSION_OFF

// ##################################################################################
//
// Section 2. Define the pins that are used to interface with the display here
//
// ##################################################################################

#define TFT_MISO PIN_D6
#define TFT_MOSI PIN_D7
#define TFT_SCLK  PIN_D5
#define TFT_CS      PIN_D8  // Chip select control pin
#define TFT_DC       PIN_D3  // Data Command control pin
#define TFT_RST      PIN_D4  // Reset pin (could connect to RST pin)

// If a backlight control signal is available then define the TFT_BL pin in Section 2
// below. The backlight will be turned ON when tft.begin() is called, but the library
// needs to know if the LEDs are ON with the pin HIGH or LOW. If the LEDs are to be
// driven with a PWM signal or turned OFF/ON then this must be handled by the user
// sketch. e.g. with digitalWrite(TFT_BL, LOW);

// #define TFT_BL   32            // LED back-light control pin
// #define TFT_BACKLIGHT_ON HIGH  // Level to turn ON back-light (HIGH or LOW)

// We must use hardware SPI, a minimum of 3 GPIO pins is needed.
// Typical setup for ESP8266 NodeMCU ESP-12 is :
//
// Display SDO/MISO  to NodeMCU pin D6 (or leave disconnected if not reading TFT)
// Display LED       to NodeMCU pin VIN (or 5V, see below)
// Display SCK       to NodeMCU pin D5
// Display SDI/MOSI  to NodeMCU pin D7
// Display DC (RS/AO)to NodeMCU pin D3
// Display RESET     to NodeMCU pin D4 (or RST, see below)
// Display CS        to NodeMCU pin D8 (or GND, see below)
// Display GND       to NodeMCU pin GND (0V)
// Display VCC       to NodeMCU 5V or 3.3V
//
// The TFT RESET pin can be connected to the NodeMCU RST pin or 3.3V to free up a control pin
//
// The DC (Data Command) pin may be labelled AO or RS (Register Select)
//
// With some displays such as the ILI9341 the TFT CS pin can be connected to GND if no more
// SPI devices (e.g. an SD Card) are connected, in this case comment out the #define TFT_CS
// line below so it is NOT defined. Other displays such at the ST7735 require the TFT CS pin
// to be toggled during setup, so in these cases the TFT_CS line must be defined and connected.
//
// The NodeMCU D0 pin can be used for RST
//
//
// Note: only some versions of the NodeMCU provide the USB 5V on the VIN pin
// If 5V is not available at a pin you can use 3.3V but backlight brightness
// will be lower.

// ###### EDIT THE PIN NUMBERS IN THE LINES FOLLOWING TO SUIT YOUR ESP8266 SETUP ######

// For NodeMCU - use pin numbers in the form PIN_Dx where Dx is the NodeMCU pin designation
//#define TFT_CS   PIN_D8  // Chip select control pin D8
//#define TFT_DC   PIN_D3  // Data Command control pin
//#define TFT_RST  PIN_D4  // Reset pin (could connect to NodeMCU RST, see next line)
//#define TFT_RST  -1    // Set TFT_RST to -1 if the display RESET is connected to NodeMCU RST or 3.3V

//#define TFT_BL PIN_D1  // LED back-light (only for ST7789 with backlight control pin)

//#define TOUCH_CS PIN_D2     // Chip select pin (T_CS) of touch screen

//#define TFT_WR PIN_D2       // Write strobe for modified Raspberry Pi TFT only

// ######  FOR ESP8266 OVERLAP MODE EDIT THE PIN NUMBERS IN THE FOLLOWING LINES  ######

// Overlap mode shares the ESP8266 FLASH SPI bus with the TFT so has a performance impact
// but saves pins for other functions. It is best not to connect MISO as some displays
// do not tristate that line when chip select is high!
// Note: Only one SPI device can share the FLASH SPI lines, so a SPI touch controller
// cannot be connected as well to the same SPI signals.
// On NodeMCU 1.0 SD0=MISO, SD1=MOSI, CLK=SCLK to connect to TFT in overlap mode
// On NodeMCU V3  S0 =MISO, S1 =MOSI, S2 =SCLK
// In ESP8266 overlap mode the following must be defined

//#define TFT_SPI_OVERLAP

// In ESP8266 overlap mode the TFT chip select MUST connect to pin D3
//#define TFT_CS   PIN_D3
//#define TFT_DC   PIN_D5  // Data Command control pin
//#define TFT_RST  PIN_D4  // Reset pin (could connect to NodeMCU RST, see next line)
//#define TFT_RST  -1  // Set TFT_RST to -1 if the display RESET is connected to NodeMCU RST or 3.3V

// ###### EDIT THE PIN NUMBERS IN THE LINES FOLLOWING TO SUIT YOUR ESP32 SETUP   ######

// For ESP32 Dev board (only tested with ILI9341 display)
// The hardware SPI can be mapped to any pins

//#define TFT_MISO 19
//#define TFT_MOSI 13
//#define TFT_SCLK 14
//#define TFT_CS   15  // Chip select control pin
//#define TFT_DC    0  // Data Command control pin
//#define TFT_RST   16  // Reset pin (could connect to RST pin)
//#define TFT_RST  -1  // Set TFT_RST to -1 if display RESET is connected to ESP32 board RST

// For ESP32 Dev board (only tested with GC9A01 display)
// The hardware SPI can be mapped to any pins

//#define TFT_MOSI 15 // In some display driver board, it might be written as "SDA" and so on.
//#define TFT_SCLK 14
//#define TFT_CS   5  // Chip select control pin
//#define TFT_DC   27  // Data Command control pin
//#define TFT_RST  33  // Reset pin (could connect to Arduino RESET pin)
//#define TFT_BL   22  // LED back-light

//#define TOUCH_CS 21     // Chip select pin (T_CS) of touch screen

//#define TFT_WR 22    // Write strobe for modified Raspberry Pi TFT only

// For the M5Stack module use these #define lines
//#define TFT_MISO 19
//#define TFT_MOSI PIN_D7
//#define TFT_SCLK PIN_D5
//#define TFT_CS   14  // Chip select control pin
//#define TFT_DC   27  // Data Command control pin
//#define TFT_RST  33  // Reset pin (could connect to Arduino RESET pin)
//#define TFT_BL   32  // LED back-light (required for M5Stack)

// ######       EDIT THE PINs BELOW TO SUIT YOUR ESP32 PARALLEL TFT SETUP        ######

// The library supports 8 bit parallel TFTs with the ESP32, the pin
// selection below is compatible with ESP32 boards in UNO format.
// Wemos D32 boards need to be modified, see diagram in Tools folder.
// Only ILI9481 and ILI9341 based displays have been tested!

// Parallel bus is only supported for the STM32 and ESP32
// Example below is for ESP32 Parallel interface with UNO displays

// Tell the library to use 8 bit parallel mode (otherwise SPI is assumed)
//#define TFT_PARALLEL_8_BIT

// The ESP32 and TFT the pins used for testing are:
//#define TFT_CS   33  // Chip select control pin (library pulls permanently low
//#define TFT_DC   15  // Data Command control pin - must use a pin in the range 0-31
//#define TFT_RST  32  // Reset pin, toggles on startup

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

//#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  // Pins can be randomly assigned, this does not affect
//#define TFT_D3   25  // TFT screen update performance.
//#define TFT_D4   17
//#define TFT_D5   16
//#define TFT_D6   27
//#define TFT_D7   14

// ######       EDIT THE PINs BELOW TO SUIT YOUR STM32 SPI TFT SETUP        ######

// The TFT can be connected to SPI port 1 or 2
//#define TFT_SPI_PORT 1 // SPI port 1 maximum clock rate is 55MHz
//#define TFT_MOSI PA7
//#define TFT_MISO PA6
//#define TFT_SCLK PA5

//#define TFT_SPI_PORT 2 // SPI port 2 maximum clock rate is 27MHz
//#define TFT_MOSI PB15
//#define TFT_MISO PB14
//#define TFT_SCLK PB13

// Can use Ardiuno pin references, arbitrary allocation, TFT_eSPI controls chip select
//#define TFT_CS   D5 // Chip select control pin to TFT CS
//#define TFT_DC   D6 // Data Command control pin to TFT DC (may be labelled RS = Register Select)
//#define TFT_RST  D7 // Reset pin to TFT RST (or RESET)
// OR alternatively, we can use STM32 port reference names PXnn
//#define TFT_CS   PE11 // Nucleo-F767ZI equivalent of D5
//#define TFT_DC   PE9  // Nucleo-F767ZI equivalent of D6
//#define TFT_RST  PF13 // Nucleo-F767ZI equivalent of D7

//#define TFT_RST  -1   // Set TFT_RST to -1 if the display RESET is connected to processor reset
                        // Use an Arduino pin for initial testing as connecting to processor reset
                        // may not work (pulse too short at power up?)

// ##################################################################################
//
// Section 3. Define the fonts that are to be used here
//
// ##################################################################################

// Comment out the #defines below with // to stop that font being loaded
// The ESP8366 and ESP32 have plenty of memory so commenting out fonts is not
// normally necessary. If all fonts are loaded the extra FLASH space required is
// about 17Kbytes. To save FLASH space only enable the fonts you need!

#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_FONT8N // Font 8. Alternative to Font 8 above, slightly narrower, so 3 digits fit a 160 pixel TFT
#define LOAD_GFXFF  // FreeFonts. Include access to the 48 Adafruit_GFX free fonts FF1 to FF48 and custom fonts

// Comment out the #define below to stop the SPIFFS filing system and smooth font code being loaded
// this will save ~20kbytes of FLASH
#define SMOOTH_FONT

// ##################################################################################
//
// Section 4. Other options
//
// ##################################################################################

// For RP2040 processor and SPI displays, uncomment the following line to use the PIO interface.
//#define RP2040_PIO_SPI // Leave commented out to use standard RP2040 SPI port interface

// For RP2040 processor and 8 or 16 bit parallel displays:
// The parallel interface write cycle period is derived from a division of the CPU clock
// speed so scales with the processor clock. This means that the divider ratio may need
// to be increased when overclocking. I may also need to be adjusted dependant on the
// display controller type (ILI94341, HX8357C etc). If RP2040_PIO_CLK_DIV is not defined
// the library will set default values which may not suit your display.
// The display controller data sheet will specify the minimum write cycle period. The
// controllers often work reliably for shorter periods, however if the period is too short
// the display may not initialise or graphics will become corrupted.
// PIO write cycle frequency = (CPU clock/(4 * RP2040_PIO_CLK_DIV))
//#define RP2040_PIO_CLK_DIV 1 // 32ns write cycle at 125MHz CPU clock
//#define RP2040_PIO_CLK_DIV 2 // 64ns write cycle at 125MHz CPU clock
//#define RP2040_PIO_CLK_DIV 3 // 96ns write cycle at 125MHz CPU clock

// For the RP2040 processor define the SPI port channel used (default 0 if undefined)
//#define TFT_SPI_PORT 1 // Set to 0 if SPI0 pins are used, or 1 if spi1 pins used

// For the STM32 processor define the SPI port channel used (default 1 if undefined)
//#define TFT_SPI_PORT 2 // Set to 1 for SPI port 1, or 2 for SPI port 2

// Define the SPI clock frequency, this affects the graphics rendering speed. Too
// fast and the TFT driver will not keep up and display corruption appears.
// With an ILI9341 display 40MHz works OK, 80MHz sometimes fails
// With a ST7735 display more than 27MHz may not work (spurious pixels and lines)
// With an ILI9163 display 27 MHz works OK.

// #define SPI_FREQUENCY   1000000
// #define SPI_FREQUENCY   5000000
// #define SPI_FREQUENCY  10000000
// #define SPI_FREQUENCY  20000000
#define SPI_FREQUENCY  27000000
// #define SPI_FREQUENCY  40000000
// #define SPI_FREQUENCY  55000000 // STM32 SPI1 only (SPI2 maximum is 27MHz)
// #define SPI_FREQUENCY  80000000

// Optional reduced SPI frequency for reading TFT
#define SPI_READ_FREQUENCY  20000000

// The XPT2046 requires a lower SPI clock rate of 2.5MHz so we define that here:
#define SPI_TOUCH_FREQUENCY  2500000

// The ESP32 has 2 free SPI ports i.e. VSPI and HSPI, the VSPI is the default.
// If the VSPI port is in use and pins are not accessible (e.g. TTGO T-Beam)
// then uncomment the following line:
//#define USE_HSPI_PORT

// Comment out the following #define if "SPI Transactions" do not need to be
// supported. When commented out the code size will be smaller and sketches will
// run slightly faster, so leave it commented out unless you need it!

// Transaction support is needed to work with SD library but not needed with TFT_SdFat
// Transaction support is required if other SPI devices are connected.

// Transactions are automatically enabled by the library for an ESP32 (to use HAL mutex)
// so changing it here has no effect

// #define SUPPORT_TRANSACTIONS

OUTPUT FROM DIAGNOSTIC SKETCH:

[Bodmer]

Try it again after commenting out the following lines in your setup file thus: //#define TFT_MISO PIN_D6 //#define TFT_MOSI PIN_D7 //#define TFT_SCLK PIN_D5

Also run Read_User_Setup again and check the reported gpio numbers are correct.

[Mearntain]

The 3 lines have been commented out, ran Read_User_Setup again, but still am unable to get the display to work with the library.

[Bodmer]

I see that the OP states: TFT_eSPI library version 2.5.0

Yet the Read _User_Setup indicates the version is 2.4.79

Make sure you do not have multiple copies of the library loaded.

I use IDE 1.8.xx but I will try with the new 2.0.4 and see if that makes a difference.

[Mearntain]

Yep, you are correct that I did have a typo, but I do only have 1 library installed. I downgraded to .79 last night before posting to see if it would fix my issue, and it didnt. .

On another computer with the same setup.h, I am also having the same issue with Arduino 1.8.xx. That computer never had tft_espi until today so that was a fresh library install there.

For what its worth, I did have this working on the same setup in the past (deleted setup file by accident at some point), but I remember there being a "got ya" in the setup file to where I had to add something special but can't remember what it was.

And if it helps any, if you are familiar with the Adafruit_ST7789 library basic example, If i use option one with hardware SPI (plugged into same SPI plugs as my setup.h file, the display doesn't work. If I choose option 2 and explicitly define SCLK and MOSI, it works as expected.

[Mearntain]

This is the display

https://learn.adafruit.com/adafruit-1-14-240x135-color-tft-breakout/pinouts

Here is my specific board

[Bodmer]

Ah! You say, "If i use option one with hardware SPI (plugged into same SPI plugs as my setup.h file, the display doesn't work. If I choose option 2 and explicitly define SCLK and MOSI, it works as expected."

The second option works because the Adafruit library will then use software SPI which can be used on any pins. The fact that the first option does not work shows that the hardware SPI pins are not correctly wired to the display.

How can this be? The answer I think is that the Wemos D1 mini comes in different versions. Older boards mapped different pins to say D7!

Check your Wemos board version and try to find the GPIO pin number map for your actual PCB, I think the pin map posted above is incorrect for the board you have. Then use the GPIO numbers ( not Dx or PIN_Dx references) in the setup file.

[Mearntain]

That is the pinout that was given to me when I originally purchased the chips. Any idea of how to tell which one this is? I've tried every combination of pinouts I could find online and yet to make any work.

[Mearntain]

UPDATE - I got home, and using a raw chip pinout for the wifi chip, I beep tested MOSI to truly be D7 as expected along with SCLK beeping out to D5 as expected. I have even substituted actual GPIO pin numbers in the setup as well and still get the same result. Even more stumped now..

[Mearntain]

UPDATE AGAIN - using a multimeter, I am getting what I assume to be proper readings from my MOSI (D7 - GPIO 13) and SCLK (D5 - GPIO 14) pins (all pins defined read about 1.6V while all non-defined pins measure the full 5V). This really makes me think this is a issue with the setup.h file

(edit to clarify - i was testing voltages between 5V pin and each individual output)

[Bodmer]

A logic 1 will be about 3.3V so measuring from 5V to a logic 1 would give about 1.7V which is what you measure.

There are changes in the latest ESP8266 board package. The board architecture is now signalled by:

#define ARDUINO_ARCH_ESP8266

It used to be:

#define ESP8266

It looks like the Adafruit library still uses lines like:

#if defined (ESP8266)
  ...
#endif

So that means Adafruit_GFX is not completely compatible with the latest ESP8266 board package. This would explain why hardware SPI does not work.

The latest TFT_eSPI github master library has been updated to handle old and new board packages. Older versions of TFT_eSPI will only work with older ESP8266 board packages.

Maybe try older board packages?

[Mearntain]

Just downgraded it all the way back from the current package to 2.6.0 and no change. I'm open to try anything else...no exaggeration, I've seriously got around 18 hours of trials trying to get to this to work so far. I even tried on another board, Adafruit Huzzah32 and tried it connected to both the HSPI and SSPI pins and still unable to make this library work (however can get the other libaries to work on the huzzah32 no problem, however not in hardware spi mode. Nothing that I missed over in my setup.h file that I posted? If not, there must be something that I am just vastly misunderstanding

[Bodmer]

I'll connect up a ESP8266 board to an ST7789 display and see if it works for me.

Which board do you select in the menu:

[Mearntain]

I have tried several boards in the menu all with the same result, but LOLIN(WEMOS) D1 mini (clone) is my normal go-to for uploading

[Bodmer]

I have connected an ST7789 screen to an ESP8266 and it is working fine.

Sequence:

1. Use Arduino IDE 1.8.13
2. Download fresh copy of TFT_eSPI v 2.5.0 using library manager
3. Download frech copy of ESP8266 board package 3.1.2
4. Make the following chnges to User_Setup.h: a) Comment out ILI9341 driver at line 45 b) Uncomment ST7789 driver at line 55
5. Connect display to an ESP8266 board (NodeMCU format but same GPIO used).
6. Select ESP8266 board package
7. Select LOLIN(WEMOS) D1 mini (clone) board
8. Set upload speed to 921600 (just to speed up loading) and COM9
9. Upload "Sprite_Draw" sketch
10. Display runs fine but with blue and red swapped
11. Make the following chnges to User_Setup.h: a) Uncomment line 77 to select BGR colour order
12. Upload "Sprite_Draw" sketch and display works with correct colours

My display has no 5V to 3.3V regulator so it is powered from 3.3V only.

Next change to Arduino IDE 2.0.3 (already configured to use the same sketch/libraryfolder and board packages as the older IDE).

1. Select ESP8266 board package
2. Set upload speed to 921600 (just to speed up loading) and COM9
3. Upload "Colour_Wheel" sketch and display runs fine

I have a 240x240 display but did NOT set the size in the setup file so it will be treated as 240x320 and not all drawn graphics are visible as expected.

So it appears I have wired up the display the same as yours and it works fine.

The only difference is that I used a NodeMCU board as I do not have any Lolin boards. However I would not expect that to make a difference.

Do check your display has a 5v to 3.3V regulator if you are powering from 5V. Make sure the display backlight does not flicker during program execution as that would indicate an inadequate power supply.

Other than that I don't think I can help further.

[Mearntain]

Sounds good - my display does have a regulator on it. Even powering with 3.3 instead, no change. Tried again with all of your mentioned settings and no new results (see screenshot, was unable to include tft_espi in same screenshot but that is at 2.5.0 fresh install).

I wish I could chalk it up to bad hardware or something like that, but unfortunately that is not that the case as it works perfectly fine (just compiled this after the failed tft_espi attempt) with a different libary. And the fact that I did use this library about a year ago with the exact same hardware, I know it is possiible. I remember searching Google for hours on end and founds tons of people with similar issues, but all seemed to have the same fix. I was only able to find one post (or comment maybe) that had a direct reesolution to my issue. I really wish I could find that link and have been searching over a week now. Only hope is maybe my computer still has browser history saved from that far back to find it again.

[Mearntain]

I do recall it being a adafruit brand display issue specific to your library if that rings a bell at all?As mentioned in an earlier post, I can not get the library to work on ESP32 either. Maybe I get lucky and find the year old history in the meanwhile

[Bodmer]

It is supsicious that it does not work with an ESP32 either.

I think the Adafruit displays are 5V tolerant and have inline buffers. Maybe drop the SPI clock speed down to a very low value of 1MHz and see if it works. It could be there is a large delay in the buffers if they are powered froma low voltage?

[Bodmer]

The display does have a HC4050 level converter so that will limit the maximum SPI rate as I expect it is run off 3.3V.

[Mearntain]

Well.....I made progress....but unsure of what it was the caused that progress....BUT Sprite example does work now.

I'm making an assumption that there is some sort of time delay issue (too short) or something causing the problem. Or maybe I'm completely wrong?

Upload...nothing happened. Reset button, nothing happens. (THIS NEXT PART MIGHT BE IMPORTANT) Unplugging power and then plugging back in, the LED on board stays solid blue as if boot failed or froze maybe? I hit the reset button, blue light returns to normal operation but display still doesnt work. Wait a few more seconds, reset button, and Sprite starts displaying. At this point I can hit reset a couple more times and the sketch resets and runs as expected and I can repeat as many times as I want.

[Bodmer]

Since the Read_User_Setup sketch runs as reported above this shows boot occurs correctly after sketch upload.

Did you try a much lower SPI clock speed?

Another option is to change this line: https://github.com/Bodmer/TFT_eSPI/blob/master/TFT_eSPI.h#L132 To invoke mode 0 rather than 3.

[Mearntain]

Yep, I did try a much lower SPI speed, down to 1mhz as you suggested. That was when I was able to get the display to work from the previous picture.

I changed SPI mode to 0 and that caused the display to power up immediately after pressing the reset button. I played with multiple speeds afterwards and 1mhz seems to be where its at (faster wasn't displaying). I do still have to press reset twice to make it power up, but not with the long delays between now after changing SPI mode. I supposed maybe trying a different reset pin may fix that.

At least its working now and I'll play with the settings to get it optimized. I appreciate you hanging in there with me!

[Bodmer]

Re. SPI mode. You can invoke mode 0 by adding:

#define TFT_SPI_MODE SPI_MODE0

To the setup file.

Software SPI with the Adafruit library would probably operate at a few MHz.

I suspect the HC4050 logic level translator is introducing signal skew. Powering the display from 5V will raise the chip supply voltage slightly and then the buffer delay will reduce slightly.

You may find changing the GPIO for one of the pins DC, CS or RST solves the boot problem. This is because some of the GPIO have alternative functions at boot time and are required to be in a certain state immediately after power on. This seems to fit with your boot up issues.

You can buy ST7789 displays that do not have the buffer cheaply from China if you are patient with the long postal delay. I have also seen them on Amazon. Purchasing and integrated display plus processor is also relatively inexpensive.

I am going to close this as I think this is a hardware level problem. I think the ESP8266 can bitbash SPI at around 6MHz, so try that speed with hardware SPI. If you solve it or have more info on the required operating constraints then do share.

[Mearntain]

I did a little playing around just now and it appears that the board does work at 6mhz as you suspected. That seems to be the cutoff and I am unable to get it to display past that. Thanks again for the help in getting things going!