Never having worked with smd components before, how do you substitute resistors?

Are you referring to modifying the display board to remove the three resistors to get the SD card working?

If so I just soldered a wire across the gap where the resistor was removed. Solder may blob that far as well - but I had fine wire that worked.
sd and screen not working together

hey dudes,

i know this post is quite old, but maybe somebody of you can still help.
The Screen of the ili9341 works fine for it self. Same with the sd card. But both dont work together. As soon as connect the SPI wires to the SD pins the screens stops working. I removed all 3 Resistors and bridged them, include J1. I use the pull ups for the CS and the Dc. By the way i use a nodemcu.
I dont use the MISO pin for the screen( but that should be a problem).
Any advice?

Yes, ask the nocdemcu forum. We're using Teensy in this forum.

well i already did. But the community isnt that big yet. Reading this threath, i assumend you guys have quite the experience with the ili9341, regardless of what microcontroller
Are you sure you are using two separate Chip Selects ? One for the SD card and a second one for the TFT Display. Both CS pins need separate pullups.
That's not a problem with the display, it is a software-problem. Perhaps a problem with the SPI-Driver or whatever is used to access SPI. Do you have pullups on all chipselects ?
That's not a problem with the display, it is a software-problem. Perhaps a problem with the SPI-Driver or whatever is used to access SPI. Do you have pullups on all chipselects ?

But if each of the spi slave works for itself, then i would asume the software is alright?
There's a software-conflict when using both.
Perhaps both parts are trying to use SPI the same time ?
Actually there are many ways that shared SPI access to multiple devices can mess with their neighbors. In the Teensy World we have a software solution called SPI Transactions that configures the SPI subsystem as needed for each device while it is being used and then can switch the SPI subsystem to the configuration needed for a different device. The two configurations are effectively separated from each other. I don't know if this is applicable in your case but just add this idea of a potential conflict to your pile of things to look at.

I just know that I commonly use an SD card and the TFT display together without any problems.

For us to be effective in looking into your question, we really need a couple of helpful hints.

1) A description of your hardware setup including a description of where the wires go and power connections.
For this to be easily understandable and capable of being tested remotely, you should have hardware that matches what we have available.
Sometimes a picture works best along with a short description regarding the picture.

2) A complete posting of your program program sketch that will run on my hardware that illustrates the problem.
Note: I can't duplicate your issue if I can't run the program on an Arduino or Teensy using the Teensy Tools.
thanks for the reply. So u use the SPI Transactions that only one client at a time is used, right? The SPI library is compatible with the Nodemcu. So i will try the Transactions.

My code:
#include <SD.h>
#include <Adafruit_GFX.h>
#include <Arduino.h>
#include <Adafruit_ILI9341.h>

#define TFT_DC D1
#define TFT_CS D2
#define SD_CS D8

//here i use hardware SPI
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);

void setup() {
if (!SD.begin(SD_CS)){

void loop() {
//just to see if screen works

For the hardware, i will solder everything tomorrow instead of having it on a breadboard (I just want to make sure i have not any loose connections).
I took one of my ILI9341 displays and replaced the SD resistors with jumpers as described above.

I then took a Teensy 3.1 and loaded the example SD CardInfo example. It worked.

I then loaded an example TFT test program and it also worked.

I then modified your test program as shown below -

It runs ok when using the alternate SD card.init vs SD.begin !!

It appears that SD.begin(SD_CS) returns TRUE indicating that the card init succeeded BUT all the later SD card accesses appear to return bad info.

When I use card.init(SPI_FULL_SPEED, SD_CS) to init the card then everyone - both TFT and SD Card - are happy.

This suggests something in the SD & Adafruit_ILI9341 libraries does not like you but by using the alternate SD card.init you may have workaround to the problem.

I've not ever run into this problem before as I normally use the Teensy ILI9341_t3 library which is optimized for the Teensy family of microprocessors. It works great.

  SD & TFT card test
// include the SD library:
#include <SD.h>
#include <SPI.h>
#include <Adafruit_GFX.h>
#include <Arduino.h>
#include <Adafruit_ILI9341.h>

// set up variables using the SD utility library functions:
Sd2Card card;
SdVolume volume;
SdFile root;

// change this to match your microprocessor IO pins !!!!!
// The numbers below reflect the Arduino and Teensy Standard numbering system

#define SD_CS 4
#define TFT_CS 20
#define TFT_DC 21

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);

void setup()
  delay (2000); // Give Windoze USB Serial time to reconnect after upload
  // Open serial communications and wait for port to open:
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  Serial.println("ILI9341 TFT using OnBoard SD Test");

  delay(2000); // give me a chance to look at tft screen !!

  Serial.println("\n\nInitializing SD card...");
  tft.println("\nInitializing SD card...");
  // we'll use the initialization code from the utility libraries
  // since we're just testing if the card is working!
  //if (!SD.begin(SD_CS)) { // This seems to init the card but NO card info is read later !!
  if (!card.init(SPI_FULL_SPEED, SD_CS)) { // this alternate init WORKS OK
    Serial.println("initialization failed. Things to check:");
    tft.println("SD initialization failed.");
    Serial.println("* is a card inserted?");
    Serial.println("* is your wiring correct?");
    Serial.println("* did you change the chipSelect pin to match your shield or module?");
  } else {
    Serial.println("Wiring is correct and a card is present.");
    tft.println("Wiring correct and card present.");

  // print the type of card
  Serial.print("\nCard type: ");
  tft.print("\nCard type: ");
  switch (card.type()) {
    case SD_CARD_TYPE_SD1:
    case SD_CARD_TYPE_SD2:

  // Now we will try to open the 'volume'/'partition' - it should be FAT16 or FAT32
  if (!volume.init(card)) {
    Serial.println("Could not find FAT16/FAT32 partition.\nMake sure you've formatted the card");
    tft.println("Could not find FAT16/FAT32 partition.");

  // print the type and size of the first FAT-type volume
  uint32_t volumesize;
  Serial.print("\nVolume type is FAT");
  Serial.println(volume.fatType(), DEC);
  tft.print("\nVolume type is FAT");
  tft.println(volume.fatType(), DEC);
  volumesize = volume.blocksPerCluster();    // clusters are collections of blocks
  volumesize *= volume.clusterCount();       // we'll have a lot of clusters
  if (volumesize < 8388608ul) {
    Serial.print("Volume size (bytes): ");
    Serial.println(volumesize * 512);        // SD card blocks are always 512 bytes
    tft.print("Volume size (bytes): ");
    tft.println(volumesize * 512);        // SD card blocks are always 512 bytes
  Serial.print("Volume size (Kbytes): ");
  tft.print("Volume size (Kbytes): ");
  volumesize /= 2;
  Serial.print("Volume size (Mbytes): ");
  tft.print("Volume size (Mbytes): ");
  volumesize /= 1024;

  Serial.println("\nFiles found on the card (name, date and size in bytes): ");
  tft.println("\nSee Serial Terminal for\n Listing of Files found on SD Card.");


  // list all files in the card with date and size to Serial 
  root.ls(LS_R | LS_DATE | LS_SIZE);

void loop(void) {
//just loop forever... we said everything in setup !!
Last edited:
Just for the record, I wanted to mention that I'm using one of these boards for a hobby project and I've been able to get the screen, touch controller and SD card to all work, using the same SPI bus.

Note that I'm using a Freescale Kinetis KW01 board (ARM Cortex-M0+ with radio) and ChibiOS with the uGFX library. (I know the Teensy uses a different CPU, but it's in the same family.)

I did not have to modify the board by removing the resistors.

There are a couple of things to watch out for:

1) Make sure you start out with the chip select signals for each device in the high state before doing any SPI transactions.

2) If you're using a multi-tasking OS like ChibiOS and using more than one device on the same SPI channel, you need to use a mutex to prevent overlapped accesses. ChibiOS provides the spiAcquireBus()/spiReleaseBus() routines for this.

3) If the SD card is sharing the same SPI channel with other slave devices, make sure to initialize the SD card first before doing any SPI transactions to any other slaves.

There is a command that has to sent to the card in order to put it in SPI mode (otherwise it operates in native mode). Once SPI mode is selected, the card will play nice with other SPI slaves on the bus. However I suspect that if you initiate SPI transactions with other slaves first (e.g. the screen or touch controller chip), the SD card may react to the bit patterns it sees in an unpredictable way and fail to respond when you try to select SPI mode later.

I found that when you call the gfxInit() routine from uGFX, it initializes the screen first. Initialization of the SD card doesn't happen until some time later, such as if you want to display an image. As long as I call the SD card initialization routine before gfxInit(), the SD card always seems to work reliably.

SD_CS: any free digital pin
SD_SCK: 13

F_CS: this is the chip select for the not populated flash memory chip

I have one of the boards with the F_CS pin and I was naturally curious if anyone knew the model/type of flash chip which COULD be used on this board - I'm doing a project which indexes arrays of ~a couple hundred thousand strings, which doesn't need gigs and gigs of memory but requires more than the Teensy has available for program/variable space onboard. I'd like to see if the flash chip might be a good option for filling this gap.

:) Thx, in advance, for your suggestions.
I've modified my ili9341 display a little bit.
  • The resistors R1, R2 and R3 are replaced with 0R resistors,
  • ~10k pull-up resistors for SD_CS, TFT_CS and TFT_D/C
  • the solder jumper J1 is closed.
The display is now 3.3V only - max voltage for VCC is 3.3V!
View attachment 4273

Forgive awakening an old post, but seems best to keep everything on this topic where it can be found, even if it's beating a long-dead horse.

I just got a couple of these TJCTM24028-SPI displays from PJRC and it's all "new to me."

First, I was disappointed in the brightness: connected as recommended, with 100 Ω in series with the backlight, it only draws 20 mA total, or 5 mA per diode (there's one per edge). I believe it should be more like 20 mA per diode x 4 diodes, or 80 mA total, for nominal display brightness. The data sheet from ElectroDragon suggests the LED pin should be connected directly to 3.3VDC (there is an internal 3.9 Ω dropping resistor on the board); indeed, connected this way I measure 82 mA to the backlight, and the display looks way better.

Next the SD card: it was much easier (for me) to bodge wires directly on the SD socket, than to fool with those 0603 resistors. I just ran wires up to the MISO, MOSI and SCK pins provided for the touch sensor, these are shared by all SPI devices. Also soldered a 10kΩ CS pullup from pin 2 (SD_CS) to pin 5 (3.3V) of the card socket.

Finally there's this "new" SD_CS chip select lead that isn't present on the 18-pin edge connector. Kind of a pain to have that one flying lead. We don't need 5V for anything any more, so I cut the trace between the "VCC" pin and the (now unused) onboard regulator, then repurpose that pin as "SD_CS" and hook it to the card socket.

TJCTM24028-SPI_mods_mez.jpg TJCTM24028-SPI_mods_mez_2.jpg

To make this work with Paul's Osh Park qvgatest_touch adapter board, just omit the fuse, 100 Ω resistor and 0.1µF capacitor from the BOM; jump "RST" (which receives 3.3V) to "LED"; and jump the pin formerly known as VCC to any open digital pin, which is your new SD_CS. I happened to choose D6.


Re: all that backlight current, I measured the following: TFT and touch functions draw about 13 mA in normal operation. The SD draws about 30 mA peak when reading a file. With 82 mA to the backlight, the total is 125 mA, well within the 250 mA allowed by the onboard LP38691 regulator.

Just to be certain, with a T3.2 at 72 MHz I measured 167 mA peak drawn from the USB 5V supply while reading the SD card, and 137 mA just displaying a bitmap, polling, etc. without card access.

In summary, I think this may be an easier way to enable the SD socket; the display is significantly brighter with the backlight fed straight from 3.3V; and, with a minor mod, the Osh Park TFT breakout gives you a neat, product-ready unit with no flying leads.

Last edited:
I'm using a slightly different display, it's a 2.8" ILI9341 (with touch) and with the resistor mod listed above I can get my display working AND touch screen AND the SD card on the display, and with custom fonts, here's my includes with the libraries.

Thanks for posting this fix.

#include "SPI.h"
#include "ILI9341_t3.h"
#include <UTouch.h> // touchscreen lib
#include <SdFat.h>
#include <EEPROM.h>
#include "font_ArialBold.h" // custom fonts that ships with ILI9341_t3.h
#include "font_Arial.h" // custom fonts that ships with ILI9341_t3.h
#include "font_ArialBoldItalic.h" // https://github.com/PaulStoffregen/ILI9341_fonts

I take it that since I have a Teensy 4.1 with a built in SD (Thanx so much Paul for helping me get the SD up and running) I should have no concerns about SD cards and the display working, as long as I connect the display to the pins shown in the device description and use the suggested libraries. Is this right??
I take it that since I have a Teensy 4.1 with a built in SD (Thanx so much Paul for helping me get the SD up and running) I should have no concerns about SD cards and the display working, as long as I connect the display to the pins shown in the device description and use the suggested libraries. Is this right??

Indeed the builtin SD card pins are wholly unique SDIO pins with no comflict with any 'normal' SPI or other pins on he Teensy.
Thanx SO much! I have zero experience with touchscreens so this will be an adventure. Glad to know it won't be hampered with interference from the SD applications. Must see where there is documentation on how to both drive the display and pick up on how touching the screen initiates controls.
Looks like all the above post are for older versions of the display than what I got. I got V1.2 so what, if any, modifications do I need to make to let the SD card work with a Teensy 3.1 (I happen to have 3 laying around)?
Probing the board with my multi-meter, it looks like the board was designed to interface with a 5V logic board and the resistors R1, R2, & R3 are voltage drop current limit resistor that let SD card work with 5V logic boards (with an off board pull-up resistor). So, I am guessing the only change I have to make is bypass R1, R2, & R3 with wire (aka 0R or 0 ohm resistor). The other mods in this thread are nice but I suspect they are not required so long as you apply 5V to the boards VCC and let the on-board regulator drop it to 3.3V.

Please correct me if I got anything here wrong.
Sorry, I am not sure what you have or don't have? Maybe post a picture of your display? I believe I still have some of the first ones PJRC released, which would work fine with the different displays. However I am not sure how well the SDCards worked. I believe it was mostly suggested to not use them. But again I am not sure if much of this has changed since then.