To connect a 3.5-inch SPI touchscreen to a Raspberry Pi, you must map the display's 11 control pins to the Pi's 40-pin GPIO header, utilizing the SPI0 interface for display data and a secondary chip-select for the touch controller. Unlike plug-and-play DSI ribbon cables, SPI touchscreens require explicit jumper wiring, precise 3.3V logic level adherence, and custom device tree overlays to function correctly.

This walkthrough traces the exact wiring diagram for the widely used Waveshare 3.5-inch SPI TFT (ILI9486 display controller with XPT2046 touch controller), providing the terminal mapping, node-by-node signal paths, and bench verification steps you need to get it running on both Pi 4 and Pi 5 hardware.

The 3.5" SPI Touchscreen to Raspberry Pi Pinout

Before cutting wires or soldering headers, map your physical connections using this terminal table. This data assumes the standard Waveshare 3.5" Rev B/C SPI board, which accepts 5V for main power but strictly requires 3.3V for logic signals.

Display Pin Schematic Symbol Pi GPIO (BCM) Physical Pin Function & Logic Level
VCC VCC / 5V N/A (5V Rail) 2 Main power input (5.0V DC)
GND GND N/A (Ground) 6 Common ground reference (0V)
CS CS / CE0 8 24 LCD Chip Select (Active-Low 3.3V)
RST RESET 25 22 Hardware Reset (Active-Low 3.3V)
D/C A0 / DC 24 18 Data/Command Selector (3.3V)
MOSI SDA / DIN 10 19 SPI Master Out Slave In (3.3V)
SCLK SCL / CLK 11 23 SPI Clock Signal (3.3V)
LED BL / EN 18 12 Backlight PWM Control (3.3V)
MISO SDO / DO 9 21 SPI Master In Slave Out (3.3V)
T_CS T_CS / CE1 7 26 Touch Controller Chip Select (3.3V)
T_IRQ IRQ / PEN 17 11 Touch Interrupt Request (3.3V)

Decoding the Diagram Symbols

When reading the manufacturer's schematic for this display, you will encounter specific symbols that dictate how the Pi must drive the pins:

  • Active-Low Bubbles (CS, RST): A small circle on the pin entry indicates active-low logic. The Pi must pull these pins to 0V (GND) to activate the function, and hold them at 3.3V to keep them idle.
  • Tri-State Arrows (MOSI, MISO): Standard SPI data lines. MOSI points toward the display (Pi transmits), while MISO points toward the Pi (Display transmits touch data back).
  • D/C (Data/Command): Sometimes labeled as A0 on older ILI9486 schematics. A logic HIGH (3.3V) tells the display the incoming SPI byte is pixel data; a logic LOW (0V) tells it the byte is a configuration command.

Node-by-Node Wiring Trace: Power, Data, and Ground Paths

A wiring diagram is only useful if you can trace the current and signals from source to load. Here is the exact node-by-node path for the three critical circuits in this setup.

1. The Power and Ground Path

Starting at the Raspberry Pi 40-pin header, the 5V source exits Physical Pin 2 (Red wire) and travels to the display's VCC terminal. On the Waveshare board, this 5V feeds an onboard low-dropout (LDO) regulator that steps the voltage down to 3.3V for the ILI9486 logic core.

The ground path returns via Physical Pin 6 (Black wire), traveling to the display's GND terminal. This completes the circuit for both the 5V power and the 3.3V signal references, establishing a common equipotential ground between the Pi and the display controller. Never omit this ground wire; without it, the SPI data lines lack a reference voltage and will cause phantom touches or screen tearing.

2. The SPI Data Path (Display)

The display data circuit originates at the Pi's SPI0 peripheral. The clock signal (SCLK) exits Physical Pin 23, setting the timing rhythm. On the rising edge of this clock, the Pi pushes pixel data out of MOSI (Physical Pin 19) into the display's shift register. Because this is a write-heavy display interface, the MISO line (Physical Pin 21) is technically optional for the display itself, but it is physically wired to allow the Pi to read the display's ID register during boot.

3. The Touch Controller Path

The XPT2046 touch controller shares the same SPI bus (MOSI, MISO, SCLK) but requires its own dedicated chip select to avoid colliding with display data. When the Pi wants to read touch coordinates, it pulls T_CS (Physical Pin 26) LOW. The touch controller then pushes X/Y coordinate data back to the Pi via MISO. Once the physical touch is registered, the controller pulls the T_IRQ line (Physical Pin 11) LOW, triggering a hardware interrupt on the Pi so the OS knows to poll the SPI bus for coordinates.

Warning: 3.3V Logic Limit. The Raspberry Pi GPIO pins operate at 3.3V. The ILI9486 and XPT2046 chips are also 3.3V logic. If you are using a level-shifter board or wiring a 5V microcontroller (like an Arduino Uno) to this display, you must step the logic down to 3.3V. Pushing 5V into the Pi's MISO pin or the display's D/C pin will permanently destroy the silicon.

Verifying the Connections with a Multimeter

Before applying power and loading the OS, verify your physical wiring with a digital multimeter (DMM). This prevents short circuits from frying the Pi's PMIC (Power Management IC).

  1. Continuity Check (Ground Path): Set your DMM to continuity mode (the diode/sound wave symbol). Place the black probe on the Raspberry Pi's metal USB port shield (a known ground) and the red probe on the display's GND pin. You should hear a continuous beep, and the display should read less than 1.0 Ω. If it reads OL (Open Loop), your ground wire is broken or mis-pinned.
  2. Short Circuit Check (Power): With the Pi unpowered, set the DMM to resistance mode. Measure between the display's VCC pin and GND pin. You should see a reading in the kilo-ohm range (typically 10kΩ - 50kΩ) due to the onboard capacitors and LDO regulator. If it reads near 0 Ω, you have a solder bridge or a shorted Dupont wire. Do not apply power.
  3. Voltage Verification (Live Test): Power on the Pi. Set the DMM to DC Voltage. Place the black probe on GND and the red probe on the display's VCC pin. It must read between 4.8V and 5.2V. Next, probe the CS pin. Because it is active-low and idle at boot, it should read a steady 3.3V.
  4. The SCLK 'Half-Voltage' Trick: If you probe the SCLK pin with a standard DC multimeter while the screen is updating, you will likely read ~1.6V instead of 3.3V. Do not panic. This is normal. The multimeter is averaging the 3.3V square wave's 50% duty cycle. To see the actual 3.3V peaks, you must use an oscilloscope or a logic analyzer.

Software Configuration and Common SPI Faults

Wiring the display is only half the battle. The Raspberry Pi OS does not natively drive SPI framebuffers without explicit device tree overlays. Furthermore, the transition to the Raspberry Pi 5 and the Bookworm OS release changed how SPI peripherals are addressed due to the new RP1 southbridge chip.

Pi 4 and Older (Bullseye OS)

For a Pi 4 running Bullseye, you edit the /boot/config.txt file. Add the following lines at the bottom to enable the SPI bus and load the Waveshare overlay:

dtparam=spi=on
dtoverlay=waveshare35b
gpu_mem=128

Pi 5 (Bookworm OS)

The Pi 5 routes GPIO through the RP1 chip, meaning older display overlays often fail silently, resulting in a white or black screen. On Bookworm, the configuration file has moved to /boot/firmware/config.txt. You must explicitly enable the SPI1 bus if your touch controller uses CE1, and ensure the framebuffer module is loaded. According to the official Raspberry Pi configuration documentation, you should use:

dtparam=spi=on
dtoverlay=spi1-1cs,cs0_pin=7
dtoverlay=waveshare35b
Bench Tip: The 'White Screen' Failure Mode. If your backlight turns on (you see a glowing white screen) but no graphics appear, your power and LED wiring are correct, but your SPI data is failing. 90% of the time, this is caused by the D/C pin being wired to the wrong GPIO. If D/C is stuck HIGH, the display interprets all configuration commands as pixel data, resulting in garbage or a blank white screen. Re-verify Physical Pin 18 (BCM 24) with your multimeter.

For comprehensive hardware schematics and overlay source code, refer to the Waveshare 3.5-inch LCD Wiki. Always verify your specific board revision, as touch controller interrupt pins occasionally shift between hardware revisions.

By strictly following the pinout table, tracing the ground and logic paths, and verifying with a meter before booting, you eliminate the hardware variables. This leaves only software configuration, turning a frustrating weekend project into a reliable, responsive embedded interface.