SPI hardware (MFRC522) not working with Latest Jessie release (2016-05-10-raspbian-jessie)

[cscuilla]

The rfid reader (MFRC522) does not work with the latest release of Jessie(2016-05-10). It works fine on the previous version (2016-03-18). I believe this is due to the new version of SPI.

On previous Jessie version (2016-03-18-raspbian-jessie) if I type lsmod after installing spi I get the following..
spi_bcm2708

On recent Jessie version (2016-05-10-raspbian-jessie) if I type lsmod after installing spi I get the following..
spi_bcm2835

Others, are having the same issue as described on the raspberry pi forum at this link..
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=148890

[pelwell]

Can you describe the configuration of your system - any relevant entries in config.txt, cmdline,txt, /etc/modules or /etc/modprobe.d/*.conf?

Also, can you explain the failure mode - what do you expect to happen, and what actually happens?

[cscuilla]

To get it working on previous Jessie Release (2016-03-18) I have to add the following to /boot/config.txt

device_tree_param=spi=on
dtoverlay=spi-bcm2708
This does NOT work on latest Jessie release. I've also tried
dtoverlay=spi-bcm7835

The failure mode is as follows.. Once I run the script it appears to work as it is waiting for a card to be scanned, however when I scan a card, nothing is output.

On previous Jessie(where card reader works), when I run the script and scan a card, the UID of the card is printed.

[pelwell]

Can you confirm that with just dtparam=spi=on in config.txt (by which I mean no other spi-related settings) and spi-dev in /etc/modules that /dev/spi0.0 and /dev/spi0.1 appear but your script fails?

[pelwell]

I've just ordered one of these devices, but it probably won't arrive before next week and I can't promise much time to look at this.

[cscuilla]

what do you mean by this part

and spi-dev in /etc/modules that /dev/spi0.0 and /dev/spi0.1 appear but your script fails?
Currently, if I open /etc/modules all I have is
i2c-dev

[pelwell]

Sorry, that's correct. SPI and I2C are strangely different in that respect the layered, user-space interface to I2C (i2c-dev) isn't loaded by Device Tree because it isn't hardware-specific, but the equivalent module for SPI (spidev) is.

So, to be more accurate: can you confirm that with just dtparam=spi=on in config.txt (by which I mean no other spi-related settings) that /dev/spi0.0 and /dev/spi0.1 appear but your script fails?

[cscuilla]

OK, thanks, I am setting up a new memory card now with the latest release so I can confirm this for you.

[cscuilla]

I can confirm this.. In /boot/config.txt I have the following

dtparam=spi=on

If I go into the /dev folder and type "ls"
I see spidev0.0 and spidev0.1

When I start my script, I receive no output once I scan a card.

[cscuilla]

Thank you for ordering the hardware. I understand your time is limited but do appreciate the help. Here are the full steps to get the reader working on previous debian OS in case it helps you to troubleshoot..

1. add to the bottom of /boot/config.txt
   • device_tree_param=spi=on
   • dtoverlay=spi-bcm2708
2. Install python-dev
   • sudo apt-get install python-dev
3. Install SPI
   • git clone https://github.com/lthiery/SPI-Py.git
   • cd ~/SPI-Py
   • sudo python setup.py install
4. Install Sample RFID Reader python library and sample script.
   • git clone https://github.com/rasplay/MFRC522-python.git
5. Run sample script.
   • sudo python ~/MFRC522-python/read.py

[EECSdude]

I am running Raspberry Pi 2 B on Linux 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux with exact same behavior. I am online the next hour and happy to run any tests, provide any files.

Scope traces show the following.
GPIO 25, the RST line is always high, I don’t see it move.
GPIO 8 is always low, I don’t see it move, although I do see digital noise similar to SCLK at the millivolt level.
SCLK toggles the whole time Read.py is running, as expected.
As an experiment, I rebooted then ran a few commands to toggle GPIO25 up and down to check my scope setup. When I ran the same script with 25 set to 8, I got a runtime warning in response to GPIO.setup(8, GPIO.OUT) “this channel is already in use”.

I would expect to get that message if the GPIO was in CE0 mode, not a GPIO output as gpio readall says it is.

[pelwell]

You say that GPIO 25 is the reset line, but the code appears to use GPIO 22 - is this a non-standard numbering issue, or have you modified your version of the code?

As mentioned in the Forum thread, the spi-bcm2835 driver uses software-controlled CE lines rather than ones driven by the hardware block, to work around a hardware glitch, which means that the driver is claiming the pin for GPIO - this explains the contention.

I see there is an spidev Python module that uses the spidev interface - does the spi module also do this, or is it a pure user-space software implementation?

[EECSdude]

I have not modifed Read.py. Interesting, I'll move the wire and see what happens.

https://github.com/mxgxw/MFRC522-python shows:

Name Pin # Pin name
SDA 24 GPIO8
SCK 23 GPIO11
MOSI 19 GPIO10
MISO 21 GPIO9
IRQ None None
GND Any Any Ground
RST 22 GPIO25
3.3V 1 3V3

[pelwell]

I can answer the second question myself now - the SPI-Py (spi) module drives the spidev interface from C code.

[EECSdude]

PIN 22 is GPIO25, what pin configuration is the code using? Moving the wire now.

[cscuilla]

For me, The python script uses "board" as the mode for rip.gpio. So the reset is on pin 22 but GPIO number 25.

I'm not sure what u mean in regards to the spidev Python module.

[EECSdude]

Moving the RFID modules RST pin from Raspberry Pi pin 22 / GPIO25 to pin 15/GPIO 22 doesn't make it work.

[pelwell]

OK - I see that RPi.GPIO is configured in BOARD mode, so 22 is the header pin number but it carries GPIO 25, so that isn't the problem.

[EECSdude]

LONG - Here's all the pertinent information in my system that has been asked for in the thread above:

I did one more thing than the previous post, suggested by a website I have forgotten:

Install latest version of bcm2835, C library for Broadcom BCM 2835 as used in Raspberry Pi; version 1.46 currently.
(http://www.airspayce.com/mikem/bcm2835/)

# download the latest version of the library, say bcm2835-1.xx.tar.gz, then:
$ tar zxvf bcm2835-1.xx.tar.gz
$ cd bcm2835-1.xx
$ ./configure
$ make
$ sudo make check
$ sudo make install

The above didn’t cause MFRC522-python\Read.py to work

It felt like the problem is a conflict between 2835 and 2708, so I have added and commented out things with no success and no error indication.

Here's a snapshot of a system that runs Read.py with no error and no card read:

$ ls /dev/spi*
/dev/spidev0.0  /dev/spidev0.1

$ lsmod
Module                  Size  Used by
xt_multiport            1756  1
iptable_filter          1409  1
ip_tables              11637  1 iptable_filter
x_tables               12507  3 ip_tables,xt_multiport,iptable_filter
cfg80211              427855  0
rfkill                 16037  1 cfg80211
evdev                  11396  4
bcm2835_wdt             3225  0
bcm2835_gpiomem         3040  0
uio_pdrv_genirq         3164  0
uio                     8000  1 uio_pdrv_genirq
spi_bcm2835             7286  0
snd_bcm2835            20511  0
snd_pcm                75698  1 snd_bcm2835
snd_timer              19160  1 snd_pcm
snd                    51844  3 snd_bcm2835,snd_timer,snd_pcm
i2c_bcm2708             4770  0
i2c_dev                 5859  0
fuse                   83461  1
ipv6                  347530  45

$ cat /boot/config.txt (clipped only bottom)
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
dtparam=spi=on
dtparam=i2c_arm=on
start_x=1
gpu_mem=128

dtoverlay=spi-bcm2835

#dtoverlay=spi-bcm2708

$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

i2c-dev
i2c-bcm2708
snd-bcm2835
#i2c-bcm2835
#rtc-ds1307
#spi-dev
spi-bcm2835
#spi-bcm2708

The files “etc/modprobe.d/*.conf” are only empty blacklist files.

[pelwell]

Thanks for all of that information. A few comments:

1. Don't use dtoverlay=spi-bcm2835 - that overlay isn't needed and doesn't exist anymore.
2. You don't need to load i2c-bcm2708, snd-bcm2835 or spi-bcm2835 - they are all loaded by Device Tree nowadays.

I don't think either of these will cause your problem, I'm just trying to encourage best practises.

[EECSdude]

Just noticed the original post and I are using different libraries with same result.
Original post is: https://github.com/rasplay/MFRC522-python
I'm using: https://github.com/mxgxw/MFRC522-python.

Both are 2 years since last update.
Both use SPI-Py. Common failure point?

[EECSdude]

Thank you pelwell, followed best practices and still no joy, but I feel so much cleaner! Just FYI, I have moved this particular RFID hardware to an Arduino and it works.

[pelwell]

There was an issue around the time of the Pi2 launch caused by a change to the SPI ioctl interface - a field in a structure that was an output became an input and output, and many libraries had to be changed to zero that field before calling the ioctl in question. I'll find the details later.

[EECSdude]

Anything like this: http://stackoverflow.com/questions/10828194/issue-with-spi-serial-port-comm-stuck-on-ioctl

or this:

http://www.raspberry-projects.com/pi/programming-in-c/spi/using-the-spi-interface

Issues:
"Error – Problem transmitting spi data..ioctl: Invalid argument

Due to changes in the underlying library the spi_ioc_transfer struct now needs to be initialised to NULL, and a hacky fix is to add this to the beginning of the for loop (this has been done in the code example above)

memset(&spi[i], 0, sizeof (spi[i]));

[pelwell]

That second link is the issue I was referring to. You could try adding this to spi.c in the SPI-Py library at line 190:

                .cs_change = 1,
+               .pad = 0,
    };

A more future-proof fix would be to memset the structure to zero before setting the required fields, but that would need a bit more restructuring.

If a non-zero pad field is the cause of the problem then I'm slightly surprised that you don't see the "can't send spi message" error message.

[cscuilla]

I tried adding the change to spi.c, but the issue is the same. No error message when running script, but no output when trying to read a card.

[EECSdude]

Any more help I can provide? We have some great momentum on this.

[pelwell]

I won't do any more on this until the hardware arrives, which should be next week.

[Jbithell]

I'm having issues with this as well - I've had it working quite well for some time - a quick SD flash and new raspian install (as I change project) and nothing with SPI seems to be working.

I've tried everything I can think of, on 2 different Pi's (B+ and 3) - and nothing working on either of them. Currently resorting to banging my head against a wall

[Jbithell]

I'm going to try a rollback using http://downloads.raspberrypi.org/raspbian/images/

[pelwell]

That's true - with the newer SPI-Py, the openSPI method returns a device handle that needs to be passed to the transfer method, so something like:

  def __init__(self,spd=1000000):
    self.dev = spi.openSPI(speed=spd,mode=0x40)
    GPIO.setmode(GPIO.BOARD)
...
  def Write_MFRC522(self,addr,val):
    spi.transfer(self.dev,((addr<<1)&0x7E,val))
  
  def Read_MFRC522(self,addr):
    val = spi.transfer(self.dev,(((addr<<1)&0x7E) | 0x80,0))
    return val[1]

[cscuilla]

Thanks again @pelwell so to clarify, are you saying to make those changes to the MFRC522.py file and it should work with latest SpI-Py library?

[pelwell]

Unless I've made a mistake (I haven't tested that patch), yes - that should fix it. It's a shame there wasn't a backwards-compatible way to make the SPI-Py changes.

[ksanchez15]

Thanks guys, but even with the old version of the library it still doesn't scan my card. @pelwell I followed your instructions (#2613) but right at step 1, I don't see options named SPI in Advanced Options (in raspi-config). Therefore, when I run dtoverlay -l I get No overlays loaded

[cscuilla]

@pelwell thanks again i will test early next week.. @lesanchez try "Interface Options" under raspi-config. Enable SPI, then reboot and try again.

[ksanchez15]

@cscuilla I just did that but the command dtoverlay - l still returns the same thing. It should be noted that I do see the line dtparam=spi=on in my /boot/config.txt folder.
Also when I run lsmod | grep spi I get
spidev 20480
spi_bcm2835 20480 0

[ksanchez15]

@pelwell After your fix, I see get the following warning when I run Read.py:

/home/pi/MFRC522-python/MFRC522.py:133: RuntimeWarning: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.

[pelwell]

dtoverlay -l will only list overlays (and DT parameters) applied by Linux at run time. Overlays applied by the firmware become part of the base DTB, so Linux isn't aware that is what they are.

[cscuilla]

@lesanchez It's probably your wiring or soldering that is the problem then.

[ksanchez15]

@cscuilla @pelwell all right thank you guys

[pelwell]

That warning is because GPIO 25 (pin 22) has been left as an output by a previous failed run. Run raspi-gpio set 25 ip and try again. Once the script is working, provided you exit cleanly with Ctrl-C you shouldn't see that warning.

[ksanchez15]

I have quadruple check my wiring (even asked a colleague who is an electrical engineer) and everything is good. I have checked out the old version of SPI-Py and I'm using https://github.com/mxgxw/MFRC522-python's latest version.
Still, the tag (which was sent with the RC522 board) doesn't trigger anything. Could the issue come from somewhere else?

[ksanchez15]

@pelwell I tried to run this and I get this output

00: 00 82 84 86 88 8a 8c 8e
08: 90 92 94 96 98 9a 9c 9e
10: a0 a2 a4 a6 a8 aa ac ae
18: b0 b2 b4 b6 b8 ba bc be
20: c0 c2 c4 c6 c8 ca cc ce
28: d0 d2 d4 d6 d8 da dc de
30: e0 e2 e4 e6 e8 ea ec ee
38: f0 f2 f4 f6 f8 fa fc fe

which tells me that, at least, the spi part of the equation is working properly. Also, every time I run the script, the values change entirely.

[pelwell]

The values the test app is reading back are the same as those it is sending. (If you are curious, you could try deliberately connecting MOSI to MISO to see what the results are.)

Is the CS line connected correctly? And is the device powered. As part of the diagnostic process you can disconnect each pin, one at a time (but not GND) and observe the changes in the output.

[cscuilla]

That's true - with the newer SPI-Py, the openSPI method returns a device handle that needs to be passed to the transfer method, so something like:

  def __init__(self,spd=1000000):
    self.dev = spi.openSPI(speed=spd,mode=0x40)
    GPIO.setmode(GPIO.BOARD)
...
  def Write_MFRC522(self,addr,val):
    spi.transfer(self.dev,((addr<<1)&0x7E,val))
  
  def Read_MFRC522(self,addr):
    val = spi.transfer(self.dev,(((addr<<1)&0x7E) | 0x80,0))
    return val[1]

@pelwell i can confirm your patch works with latest spi library! thanks again.