RPi not working with spidev

[n8henrie]

I have RF24 and RF24Network working great with BCM2835 but decided to give spidev a shot. Unfortunately, I'm not having any luck.

I think I have spi loaded properly:

$ lsmod | grep spi
spi_bcm2835
$ ls -l /dev/spi*
crw-rw---T 1 root spi 153, 0 Dec 31  1969 /dev/spidev0.0
crw-rw---T 1 root spi 153, 1 Dec 31  1969 /dev/spidev0.1

I cleaned the RF24 repo, then followed the instructions to change arch/BBB/spi.cpp to point to /dev/spidev0.0 instead of 1.0 (actually just commented and uncommented the already included RPI lines below). Then I did sudo make install -B RF24_SPIDEV=1. It seems to work properly. Then sudo ldconfig. It looks like the spidev uses the same pins definitions as BCM2835, so I should be able to just leave it as it was working: RF24 radio(22,0);.

Next I clean and compile my text.cpp file, which I've eliminated everything possible to just make it print the connection details, and it's clearly not working.

#include <cstdlib>
#include <iostream>
#include <RF24/RF24.h>
#include <ctime>
#include <stdio.h>
#include <time.h>

using namespace std;

RF24 radio(22,0);

int main(int argc, char *argv[]) {
    radio.begin();
    radio.setPALevel(RF24_PA_MAX);
    radio.setAutoAck(1);
    radio.setDataRate(RF24_250KBPS);

    radio.printDetails();
    return 0;
}

Output:

sudo ./test.cpp
STATUS           = 0x00 RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=0 TX_FULL=0
RX_ADDR_P0-1     = 0x0000000000 0x0000000000
RX_ADDR_P2-5     = 0x00 0x00 0x00 0x00
TX_ADDR          = 0x0000000000
RX_PW_P0-6       = 0x00 0x00 0x00 0x00 0x00 0x00
EN_AA            = 0x00
EN_RXADDR        = 0x00
RF_CH            = 0x00
RF_SETUP         = 0x00
CONFIG           = 0x00
DYNPD/FEATURE    = 0x00 0x00
Data Rate        = 1MBPS
Model            = nRF24L01
CRC Length       = Disabled
PA Power         = PA_MIN

Next, just to verify, I cleaned everything, re-cloned the repos, and reinstalled with the default (BCM2835) driver. My sketches send and receive data, everything works great. So I re-cleaned again and reinstalled with spidev as described again, and get the exact same result.

Am I doing something wrong? Can anybody else verify that spidev is still working with the latest RPi firmware?

$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 2.00
Features        : half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0010
Serial          : XXXXXXXXXXXXX

$ uname -a
Linux raspi 4.1.7+ #815 PREEMPT Thu Sep 17 17:59:24 BST 2015 armv6l GNU/Linux

[TMRh20]

I know it may sound kind of odd, but have you tried rebooting the RPi?

If I remember correctly, I had a number of problems when attempting to get SPIDEV working fully because the bcm driver + examples tends to leave the SPI pins active/enabled. The most simple way to ensure they are cleared is just to reboot and test SPIDEV immediately.

Since SPIDEV now uses kernal driven chip-select toggling, this likely won't work until compile for SPIDEV then reboot.

[n8henrie]

Thanks for chiming in. Yes, I've done numerous reboots at various stages, and definitely after everything was compiled.

[TMRh20]

Can you give this a try: https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md#troubleshooting with the wire between MOSI and MISO to see if SPIDEV is working correctly for you?

[n8henrie]

I actually did that last night after my post. Seems to confirm that SPI is working fine.

[TMRh20]

Ok, so we know SPI works, and that would maybe point at the CE/CS pins, or a general problem with the RF24 spi code...

Here is a shot in the dark, and a bit of a 'hack', but if you open the RF24/arch/BBB/spi.c in a text editor and look at the uint8_t SPI::transfer(uint8_t tx_) and void SPI::transfernb(char* tbuf, char* rbuf, uint32_t len) you will see there are two different sections commented out.

I don't understand the differences/details myself, but at one point I upgraded (via apt-get) and had to switch between the two methods. If you are comfortable with making these changes and recompiling, its at least something to try ( uncomment the 'other' sections and comment out the corresponding section of the 'current' code )

Unfortunately one of my RPis just decided to do the solid red pwr light after a power outage, so it looks like I am one down, and am just upgrading my main one to jessie from wheezy, so I can test further with the latest updates eventually...

[TMRh20]

Per the above commit, once I upgraded to 4.1.7+ from 3.18something 3.18.7+ I ran into the same issue. Simply initializing the SPI device before each write seems to fix it. No idea why, but hopefully somebody with older firmware can confirm the fix is backwards compatible.

[n8henrie]

Awesome, I cherry-picked the commit and can confirm it works. I wonder why it needs to be initialized first now. I need to learn more about SPI!