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.