SPI ADC was working fine last week and now it's not

[frasmacon]

A few weeks ago I managed to get a MCP3004 ADC chip to work over my SPI which was amazing after two weeks of trying. Since then I went on to mess about with the I2C bus and that all worked but I went back to the ADC yesterday, wiring it up exactly as I'd done before and now all I get is a load of zero's and an occasional 1023 (It's got a 10 bit resolution so fully off and fully on). I know the code works as I haven't touched it since I last got it to work, I haven't even moved most of the cables.

The only thing I changed was I changed some stranded wire on my breadboard to single core wire so I don't damage my breadboard and now it doesn't work. I don't think it's crappy wire as I can run other things from the wire like LED's and the I2C chip I messed about with. I tried with the stranded wire and that didn't do anything, moving it around the breadboard didn't do anything, this is really confusing me as it was working perfectly and now it's not.

In fact I wonder as to whether the chip is really working or anything as I tested the SPI bus with spidev_test.c and that works but regardless of whether the chip is connected or not, and I've checked I haven't done any of the wiring wrong.

This is really confusing me as it was working perfectly and now it can't even register the chip being there with all the cables the same as before. Any help would be greatly appreciated.

Also if you want any diagrams/code/pictures just ask.

Thanks in advance,
Fraser

[frasmacon]

Hello? I rewired again for the third time using a picture and video I made of it before and it working perfectly and it still doesn't work. I even swapped out the MCP3004 with another MCP3004. I would really like some help. It just returns random numbers from 0 to 23 (out of 1023). Some help would be really great as this is really confusing. Nothing has changed at all but now it just won't work.

[bgreat]

Please post a drawing of how you have MCP3004 connected and your code. Unless there is a hardware failure, the issue is either wiring or software. With the additional information, it will be possible to help you determine the cause.

Enjoy!
Bill

[frasmacon]

Please post a drawing of how you have MCP3004 connected and your code. Unless there is a hardware failure, the issue is either wiring or software. With the additional information, it will be possible to help you determine the cause.

Enjoy!
Bill

OK

Here's a Fritzing drawing, this is pretty much a duplicate of what I have made (Click to make bigger). Made just now by actually looking at the Pi


And here's the code

Code: Select all

# Python Code to communicate with MCP3004

#Import SpiDev wrapper to enable hardware SPI
import spidev

#Establish SPI connection with Bus 0, Device 0
spi = spidev.SpiDev()
spi.open(0,0)

def get_adc(channel):
    #Check valid channel
    if((channel > 3) or (channel < 0)):
        return -1

    #Perform SPI transaction and store returned bits in 'r'
    r = spi.xfer([1, (8+channel)<<4, 0])
    #Filter data bits from returned bits
    adcout = ((r[1]&3) << 8) + r[2]
    #Return value from 0-1023
    return adcout


while True:
    print get_adc(0)

I don't see how it can't be working. I haven't touched the code and everything is the same as it was before. I did an RPi-update to try and update the SPI drivers or something and that didn't work either. I think it may be something to do with software as I understand that SPI chip select is active low, so when the CS goes low it starts, however, probing with an LED I found that the chip select stays high and no data is coming out the chip.

[bgreat]

Sorry for the delay, but I have been rather busy. Nothing obvious in the wiring. I will take a closer look at this tonight on my Raspberry Pi and post back.

Enjoy!
Bill

[frasmacon]

Sorry for the delay, but I have been rather busy. Nothing obvious in the wiring. I will take a closer look at this tonight on my Raspberry Pi and post back.

Enjoy!
Bill

Thanks very much

[bgreat]

I reviewed the code and connections again and I see nothing incorrect in the implementation. I can only suggest a few rudimentary tests to confirm everything is as you expect.

1. Confirm that you are using xfer and not xfer2.
2. Using a multimeter, confirm the ADC input from the potentiometer varies from ground to 3v3 as you rotate.
3. Pick two of the other inputs. Connect one to ground and the other to 3v3. Do you consistently read 0 and 1023 from the respective inputs.
4. Check all of the wiring to confirm that there are no open connections/bad jumpers. Turn off the Raspberry Pi and use an ohmmeter to verify there are no breaks.
5. Try setting the SPI speed... i.e. spi.max_speed=1000000

Per an earlier posting you made, it may be difficult to capture the CS line low with an LED as the time interval is very short. If you want to confirm

Enjoy!
Bill

[frasmacon]

OK here goes...

1. xfer not xfer2.
2. I don't have a multimeter but I can confirmed using an LED the value changes properly when I rotate it.
3. Tried this and it didn't work. Just got a lot of zeros
4. Not too sure what you want me to do with this one...
5. Tried this and it didn't work either (Used the frequency's the datasheet said). This worked without specifying a speed before...

Surely the chip select line is slow enough not to light an LED as bright as connecting it straight to 3v3? Using the clock lines of both the SPI and the I2C buses I can make the LED glow dimly but using the chip select, it's as if the line doesn't even go low!? Also when I move the wires around I can get a load of 1023's, supposedly from interference of some kind.

[bgreat]

It almost seems that the SPI is not enabled for the GPIO lines. I recall an earlier thread that discussed an issue with using the SPI for GPIO and then attempting to use it for SPI required a reboot. Can you confirm that no other application has used the same GPIO pins for IO before you run your program?

If you have not added any code to the system start up, this is as simple as rebooting the Raspberry Pi and testing your program before doing any other action.

Another option is to simply unload and reload the spidev module:

Code: Select all

sudo rmmod spi_bcm2708
sudo modprobe spi_bcm2708

You could also try using my spiConfig() function from this SPI display thread to make certain the configuration settings are correct.

Enjoy!
Bill

[frasmacon]

It almost seems that the SPI is not enabled for the GPIO lines. I recall an earlier thread that discussed an issue with using the SPI for GPIO and then attempting to use it for SPI required a reboot. Can you confirm that no other application has used the same GPIO pins for IO before you run your program?

If you have not added any code to the system start up, this is as simple as rebooting the Raspberry Pi and testing your program before doing any other action.

Another option is to simply unload and reload the spidev module:

Code: Select all

sudo rmmod spi_bcm2708
sudo modprobe spi_bcm2708

You could also try using my spiConfig() function from this SPI display thread to make certain the configuration settings are correct.

Enjoy!
Bill

I'm afraid nothing on this post made it work, the spiConfig function didn't say anything was wrong, I rebooted multiple times and tried that rmmod and modprobe commands and nothing. Is there a way simply to uninstall and reinstall the SPI drivers or something. Maybe it thinks it's working but doesn't know which pin is the chip select or something?

[bgreat]

The rmmod/modprobe commands basically remove the SPI driver from memory and then restart it. If the driver is corrupted or an incompatible version you should receive a message indicating a problem when the modprobe command is executed.

Barring an issue with your wiring or ADC, it is possible you have have a hardware issue with the Raspberry Pi GPIO. I would recommend wiring the SPI pins to LEDs with resistors and use a test program to confirm they function as GPIO outputs. Then test the same GPIO pins as inputs. If these tests work, I am at a loss as to where to look next without direct access to your system and connections.

Enjoy!
Bill

[frasmacon]

The rmmod/modprobe commands basically remove the SPI driver from memory and then restart it. If the driver is corrupted or an incompatible version you should receive a message indicating a problem when the modprobe command is executed.

Barring an issue with your wiring or ADC, it is possible you have have a hardware issue with the Raspberry Pi GPIO. I would recommend wiring the SPI pins to LEDs with resistors and use a test program to confirm they function as GPIO outputs. Then test the same GPIO pins as inputs. If these tests work, I am at a loss as to where to look next without direct access to your system and connections.

Enjoy!
Bill

Well I did the tests and they work fine. The pins work as both inputs and outputs perfectly fine. I left the LEDs hooked up to the pins and reenabled the SPI module and ran the SPI program and I can see that it's sending data and the clock is running as the LEDs light up dimly, but both chip select lines stay high.

So now the problem has been narrowed down to: SPI chip select lines don't go low.

Why this is, I do not know but I am 99.99% recurring that this is why the program doesn't work.

I'm going to take a wild guess that it's going to be something to do with some config file somewhere not knowing which pin is the chip select pin.

[notro]

So now the problem has been narrowed down to: SPI chip select lines don't go low.

You can verify this by emulating the Chip Select line on another gpio that you control from your program.
Set it initially HIGH
Set it LOW
Send data with SPI
Set it HIGH

Have you tried the loopback test, to see if send/receive works?
It's in the kernel source: https://github.com/raspberrypi/linux/bl ... dev_test.c
Connect a wire between MISO and MOSI.

Code: Select all

gcc -o spidev_test spidev_test.c
./spidev_test --device /dev/spidev0.0

It will not test the Chip Select signals.

[frasmacon]

So now the problem has been narrowed down to: SPI chip select lines don't go low.

You can verify this by emulating the Chip Select line on another gpio that you control from your program.
Set it initially HIGH
Set it LOW
Send data with SPI
Set it HIGH

Have you tried the loopback test, to see if send/receive works?
It's in the kernel source: https://github.com/raspberrypi/linux/bl ... dev_test.c
Connect a wire between MISO and MOSI.

Code: Select all

gcc -o spidev_test spidev_test.c
./spidev_test --device /dev/spidev0.0

It will not test the Chip Select signals.

I never thought about that...

Yes I tried the loopback tests and they work fine. The only problem is the chip select lines.

[devindunseith]

Are you definitely giving the ADC enough power? I had a similar problem with an AD7908 ADC because I was trying to drive it off the Pi's 5V supply (which actually sits at ~4.7 V). The Pi's supply lines and ground are also a bit noisy which can cause errors in the ADC.

After a few days of it not working today I finally powered the ADC off an DC power supply, and connected the supply's ground to the ADC ground and it worked first time. It's possible your SPI chip select is working fine but you can't see it go low with an LED. I spent a lot of time trying to work out what was wrong with my RPi and code only to realise it was just that the chip didn't have enough power.

If you're not having any joy getting the MCP3004/8 chip to work with SPI, it should actually be pretty easy to run it directly through the GPIO pins using the RPi.GPIO python libraries (I can send you my code which I used to do just this with the AD7908 - it's on my work computer so I'll have to get it tomorrow).

[frasmacon]

Are you definitely giving the ADC enough power? I had a similar problem with an AD7908 ADC because I was trying to drive it off the Pi's 5V supply (which actually sits at ~4.7 V). The Pi's supply lines and ground are also a bit noisy which can cause errors in the ADC.

After a few days of it not working today I finally powered the ADC off an DC power supply, and connected the supply's ground to the ADC ground and it worked first time. It's possible your SPI chip select is working fine but you can't see it go low with an LED. I spent a lot of time trying to work out what was wrong with my RPi and code only to realise it was just that the chip didn't have enough power.

If you're not having any joy getting the MCP3004/8 chip to work with SPI, it should actually be pretty easy to run it directly through the GPIO pins using the RPi.GPIO python libraries (I can send you my code which I used to do just this with the AD7908 - it's on my work computer so I'll have to get it tomorrow).

I'm sure it's getting enough power as the 3v3 is one of the recommended voltages for the chip and I have used it before. I think I could have captured the CS line go low with the LED as it's low more than it's high and even with the function where it doesn't put the CS line high again, the LED stays on max brightness. I will try various ways of getting it work. Worst case scenario just bitbang it I guess without trying another language.

[frasmacon]

I tried doing the chip select line manually, turning it low before doing the transfer function then turning it back on and it didn't seem to work. Is there any way it could accidentally use the wrong pins for the proper SPI?

[Wholetthesmokeout]

I don't know if this will help, but I was having issues with the I2C bus (http://www.raspberrypi.org/phpBB3/viewt ... 44&t=39925) and I think what solved the issue was setting the I2C speed to a whopping 1 Hz and then back to 32KHz. It's just a suggestion akin to 'turn it off and back on again'.

[frasmacon]

I don't know if this will help, but I was having issues with the I2C bus (http://www.raspberrypi.org/phpBB3/viewt ... 44&t=39925) and I think what solved the issue was setting the I2C speed to a whopping 1 Hz and then back to 32KHz. It's just a suggestion akin to 'turn it off and back on again'.

Unfortunately I have already tried the SPI equivalent with no joy. I am going to wipe the SD card and try with a fresh distro. If I could have some code to do what I said further up the post in C or something incase it's the Python wrapper.

[frasmacon]

OK, just re installed the OS using the Occidentalis thing from Adafruit and that's not working either. Although I used the program I used before. Maybe it's something to do with that. But it still has the problem with chip select not going low. I'll mess about with it some more.

EDIT: Tried changing the which device to use in my code and that didn't help. Can I have a simple SPI program in C or something to try?

[IanH2]

I tried doing the chip select line manually, turning it low before doing the transfer function then turning it back on and it didn't seem to work. Is there any way it could accidentally use the wrong pins for the proper SPI?

Did you check that the CE line is going low when you did this? If you're wiggling it manually you can put in a sleep() or input() when it's low, to make sure you don't miss it.

If you can't set GPIO 7 or 8 low from Python, perhaps the hardware is broken.

Ian

[frasmacon]

I tried doing the chip select line manually, turning it low before doing the transfer function then turning it back on and it didn't seem to work. Is there any way it could accidentally use the wrong pins for the proper SPI?

Did you check that the CE line is going low when you did this? If you're wiggling it manually you can put in a sleep() or input() when it's low, to make sure you don't miss it.

If you can't set GPIO 7 or 8 low from Python, perhaps the hardware is broken.

Ian

Yes I checked. I can manually make the chip select lines go high and low but that still makes a problem which makes me think the may be something wrong with the code but I don't know what...

[trouch]

/dev/spidev0.0 => Chip Enable 0 (CE0 / Pi header pin 24 / GPIO 8)
/dev/spidev0.1 => Chip Enable 1 (CE1 / Pi header pin 26 / GPIO 7)

[frasmacon]

Well I tried using the BCM2835 C library and although it did do things with the chip select, it didn't really work. I'll post my code in a few hours after I go to sleep as I'm in bed and PC is off. I wouldn't mind someone taking a look at it as I don't normally use C.

[frasmacon]

/dev/spidev0.0 => Chip Enable 0 (CE0 / Pi header pin 24 / GPIO 8)
/dev/spidev0.1 => Chip Enable 1 (CE1 / Pi header pin 26 / GPIO 7)

In theory it almost defiantly should work that way but I don't know what it's doing...