I'm trying to read out an MCP3008 chip using hardware SPI on a pi4, it wasn't working and in an effort to debug the problem I ended up connecting the spi input pin (MISO) directly to a 3.3V pin. I can read the pin as GPIO 9 and see that it is indeed correctly being set to HIGH.

I expect in this setup I would only be able to read bits on HIGH, which should result in maxed out values from the spi transaction, regardless of the setup of any other pins. But it actually still only gives me 0. I'm guessing I messed something up with the raspberry's spi or GPIO setup which is preventing spidev from actually reading any data from the MISO pin.

Here is the python code I'm using:

import time
import sys
import spidev

def buildReadCommand(channel):
    startBit = 0x01
    singleEnded = 0x08

    return [startBit, (singleEnded|(channel & 0xff))<<4, 0]

def processAdcValue(result):
    byte2 = (result[1] & 0x03)
    return (byte2 << 8) | result[2]

def readAdc(channel):
    r = spi.xfer2(buildReadCommand(channel))
    return processAdcValue(r)
if __name__ == '__main__':
        spi = spidev.SpiDev()
        spi.open(0, 0)
        # testing code, no changes:
        # spi.max_speed_hz = 500000
        # spi.no_cs = True

        i = 0
        while True:
            channel = i % 8
            i += 1
            val = readAdc(channel)
            print(str(channel) + ": " + str(val))
    except KeyboardInterrupt:

Any direction I can look for debugging? I'm completely at a loss. Note that software SPI seems to work fine, but this is not an option for my application.

  • For debugging this sort of interface have a look at piscope. As long as you keep the SPI speed to less than 100kbps during testing it will show you what's going on.
    – joan
    Feb 22, 2021 at 11:35

2 Answers 2


I would start by sending dummy data and checking that MOSI and CLK pins toggle. Perhaps you will discover that you forgot to activate the SPI overlay, or made a mistake calculating which pin is which.

This is safer than fiddling with MISO: you can't kill the Pi by measuring the wrong pin, but you can indeed blow it up if you apply voltages to the wrong pin.


I took another look at how I'm enabling the spi overlay, I was using dtoverlay-spi=on in /boot/config.txt to do so, which indeed gave me spi0.0 and spi0.1 when i check via the command dir /sys/bus/spi/devices.

I replaced this line with dtoverlay=spi0-cs, which still gives me the same devices, but suddenly the whole thing worked and I can succesfully read the MCP3008.

I'm still very confused, it's as if the former command gives you a dummy spi driver that doesn't actually do anything? Or maybe the spi driver is broken on my specific pi somehow...

Well I'm glad it works but still hoping for an explanation :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.