Troubleshooting a 2.8 SPI TFT display

Hi all!

I'm having problems getting a cheap 2.8 SPI TFT display to work. I assume it's a common cheap display as I find it quite a lot in searches. Here's a link to it:
http://www.lcdwiki.com/2.8inch_SPI_Module_ILI9341_SKU:MSP2807

Here's what I have done so far:

I hooked the display up to a cheap zero clone and using the adafruit libraries for a display with an ILI9341 driver and got no response from the display. I edited the code to use the ICSP connectors for MOSI, CLK, MISO, and made changes to get the code to run on a arduino zero.

Next, since this is a 3.3v logic unit, I hooked up it to an arduino UNO using a resistor voltage divider, as documented on several web searches on the subject, to give me the correct logic levels. Still, no response from the display. On the UNO, I was using the ICSP for those connections.

I then tried an adafruit 2.8 LCD display shield on my UNO. The shield was modded to use the ICSP for the SPI communication. It worked, as always.

Tried the shield LCD display on the cheap zero clone, and it worked.

At this point, I bought another display, assuming I had a defective unit. New display doesn't work either.

I'm working on a breadboard using jumpers, and I've just checked all the jumpers/connections with an ohm meter and seeing almost no resistance.

I'm a bit lost as to what to look at next to figure this out.....

Thanks for any suggestions!
Randy

The display requires 3.3V logic on every signal pin. You must connect every signal pin.
It requires 5V on the VCC terminal. You can use 3.3V if 5V is not available.

It will work 100% on Zero, Due, STM32, Teensy3.x, Teensy4.x

It will only work on a Uno, Mega2560 if you provide level shifters on every TFT signal.

Adafruit examples often omit the RST argument in constructors.
Adafruit boards have a pullup on RST line. Your Red board has no pullup. So will fail without the full constructor.

The LCDWIKI document suggests shorting the board regulator which will make everything HOT. Yes, this will work for a few minutes before destroying the display.

David.

Thanks for the reply!

I had seen the pullup resistor on the RST in tutorials, I even tried it once before and it didn’t change anything. I’ve added it back in, and still nothing.

I am attaching an image of my current wiring and I’m still not seeing why it’s not working.

I would post up the code, but I doubt that is the problem since I can plug the adafruit lcd shield into the zero and it works with the current code.

Thanks again,
Randy

You have pulled up RESET to 5V. Ok via a 1k0 resistor. But I would be happier with pullup to 3.3V
You have connected LED to 5V. I would be happier with 3.3V (or a GPIO pin)

I would connect RESET to a regular GPIO on the Zero.
You have not connected D/C. This must be connected to a regular GPIO on a Zero.

Personally, I connect
CS to 10
DC to 9
RESET to 8

MOSI to 3x2 as in your PNG.
SCK
MISO

And then use Adafruit_ILI9341 example e.g.

#include "SPI.h"
#include "Adafruit_GFX.h"
#include "Adafruit_ILI9341.h"

// For the Adafruit shield, these are the default.
#define TFT_DC 9
#define TFT_CS 10
#define TFT_RST 8

// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
// Use hardware SPI (on Zero, use 3x2 pins) and the above for CS/DC/RESET
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST);
// If using the breakout, change pins as desired
//Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_MOSI, TFT_CLK, TFT_RST, TFT_MISO);

Please note how Adafruit omit the TFT_RST argument in their example constructor.

David.

Thank you David!

I wired up the DC pin and it’s working fine!

I think I see where I went wrong. I didn’t follow any tutorial on wiring this display up to a zero. I read up on SPI, read up on the zero’s SPI pins, read the display docs, and wired it up. In all my reading on SPI, the RESET and DC aren’t part of the normal SPI interface. I think, in all my efforts to get this to working, I messed with those pins, but never had them both connected at the same time. And somewhere along the way, my brain turned to mush trying to figure this out…

Now that it is working on my zero copy, I noticed the test sequence doesn’t appear to happen any quicker than if it was connected to an UNO. The zero is a faster micro-controller, so why doesn’t the test happen faster?

I’m attaching to this post fritzing breadboard and schematic images of my setup.

Thanks,
Randy

Edit: getting an error msg while trying to attach breadboard view file… will try again soon…

Thanks for the Fritzing diagram.

I strongly recommend that you connect TFT_RESET to D8.

If you do want to pullup TFT_RESET, use a 10k resistor to 3.3V instead of 1k0 to 5V.

Incidentally, if you use coloured connecting wires in the Fritzing diagram it helps with checking your physical wiring. e.g. match the Dupont cable wire colours

David.

I have connected the RESET to D8, as you suggested.

Two questions:
Why isn’t the display going thru the adafruit demo any faster on the zero than it does on an UNO?

Do you also know how to use the touch screen?

My fritzing images are using the wire colors I used, yeah the color choice is bad, but it’ what wires were handy on my desk…

Trying to attach the latest breadboard image isn’t working and the error messages suggests contacting a moderator.

Thanks for your help so far,
Randy

So, I've been working on this..

The adafruit graphictest demo runs fine, but at the same speed as an UNO. I thought there should be an increase in speed.

The LCDWIKI's basic demo file that doesn't use any libraries works, but all other files fail to compile for a zero. They compile fine for a UNO, but for a zero, the LCDWIKI_SPI file throws so many errors...

David, your MCUFRIEND-kbv diagonse_TFT_support.ino produced this:

Diagnose whether this controller is supported
There are FAQs in extras/mcufriend_how_to.txt

tft.readID() finds: ID = 0xD3D3

MCUFRIEND_kbv version: 2.9.9

Probably a write-only Mega2560 Shield
Try to force ID = 0x9481

PORTRAIT is 320 x 480

Run the examples/graphictest_kbv sketch
All colours, text, directions, rotations, scrolls
should work.  If there is a problem,  make notes on paper
Post accurate description of problem to Forum
Or post a link to a video (or photos)

I rely on good information from remote users

yet the file graphictest_kbv compiled fine and produced output to the serial monitor, but didn't do anything as far as drawing on the screen.

I've ordered sparkfun logic level shifters and will be interested to see what happens when I hook this up to an UNO.

Moving on, I'm using @Paul Stoffregen XPT2046_Touchscreen library, that can be found here:

And I am getting what appears to be good touch screen location data, but there are parts of the code that I don't quite understand, basically the IRQ part.

One thing I noticed is that in all the examples I looked at, the touchscreen and LCD display use different SPI connections. Why? I thought SPI was to be shared MOSI, MISO, SCK, and each device needs a CS pin.

Thanks for any help,
Randy

The adafruit graphictest demo runs fine, but at the same speed as an UNO. I thought there should be an increase in speed.

The SPI implementation on the Arduino Zero core is crap.
The SERCOM on the Zero is limited to 12MHz for SPI. SPI is 8MHz on a Uno. Although the SPI on an AVR is fairly primitive, the Arduino Uno core optimises fairly well.

The LCDWIKI's basic demo file that doesn't use any libraries works, but all other files fail to compile for a zero. They compile fine for a UNO, but for a zero, the LCDWIKI_SPI file throws so many errors...

I have not tried LCDWIKI on a Zero. I suspect that it would use the crap Zero core SPI library. It will probably be slower than Adafruit. And definitely inconvenient to use badly-spelled methods.

David, your MCUFRIEND-kbv diagonse_TFT_support.ino produced this:

MCUFRIEND_kbv is designed for Mcufriend parallel shields.

I've ordered sparkfun logic level shifters and will be interested to see what happens when I hook this up to an UNO.

Level shifters will be no faster than voltage dividers or series resistors. (but electrically wiser)

Moving on, I'm using @Paul Stoffregen XPT2046_Touchscreen library, that can be found here:

XPT2046_Touchscreen works fine. But it expects hardware SPI. e.g. putting IL9341, XPT2046, SD card on the hardware SPI bus.

One thing I noticed is that in all the examples I looked at, the touchscreen and LCD display use different SPI connections. Why? I thought SPI was to be shared MOSI, MISO, SCK, and each device needs a CS pin.

Many Mega2560 40-pin Adapter shields route the XPT2046 to GPIO pins digital#3-7
This meant that XPT2046 SPI commands had to be bit-banged in software e.g. libraries like UTouch.h URTouch.h

Since the XPT2046 pins are physically separate from ILI9341 on your Red display, you can route the XPT2046 signals to any GPIO pins for URTouch.h

However, God gave you the SPI bus. I put TFT, Touch, SD all on the same hardware SPI bus.

The Arduino Zero is not very common. So popular libraries do not always support it. But this is (generally) very simple to resolve.

The Zero has sophisticated DMA that could be used for large SPI transfers.

David.

Thanks for the information you've supplied!

However, God gave you the SPI bus. I put TFT, Touch, SD all on the same hardware SPI bus.

That's what I was thinking, put all 3 on the same bus, even though all examples show a different SPI bus for touch. So I wired touch and tft to the same bus, and tried this simple example:

Which is a simple off/on button graphic display and switch that can be turned off/on from the touchscreen. Couldn't get the code to work. I was only getting touch data and the display was blank. I disabled the touchscreen parts of the code, and the graphics display worked, but the two just wouldn't play nicely together.

I used this example:

And followed the part about creating a new SPI bus on digital pins 11, 12, 13 (like an UNO). Connecting the touchscreen to this SPI bus, and the example works.

Been looking at the performance of the display.

The SPI implementation on the Arduino Zero core is crap.
The SERCOM on the Zero is limited to 12MHz for SPI. SPI is 8MHz on a Uno. Although the SPI on an AVR is fairly primitive, the Arduino Uno core optimises fairly well.

So I am assuming it's the bus speed that accounts for performance. I ran some tests using the adafruit graphicstest code and was surprised by the results.

The zero clone with the adafruit shield ran the demo in 33.693 seconds
The zero clone with the cheap breakout ran the demo in 33.694 seconds
The UNO with the adafruit shield rand the demo in 11.768 seconds

Where should I look for my performance issues? I've seen these displays work fast on ESP32s.

Any and all advice is helpful,
Randy