cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R3911B and Arduino SPI not working

MMcAl.1
Associate III

Hi,

I am trying to get an SPI connection working with my Arduino UNO and the ST25R3911B. I am trying to read the identity register 3Fh but am not getting a response on MISO.

My setup is as follows:

*VDD & VDD_IO connected with 5V from the Arduino UNO without filtering.

*Ground provided by Arduino since it provides the 5V too.

*Pins AGD, VSS, VSP_A, VSN_A, VSP_D, VSN_D, VSP_RF, VSN_RF, and pin 33 VSS are grounded as shown in Figure 2 or 3 in the datasheet using decoupling capacitors of 10nF and 2.2uF as stated in the DISCO and layout documents.

*13.56MHz crystal is not connected for now since I am only trying to get an SPI connection working for an inital test.

*Using a 10k pull-down resistor from MISO to GND since without it I saw a lot of noise on MISO after and while sending the 3Fh command to read the identity register.

*I am sending 10h to register 01h before the 3Fh command so that the RFID IC knows a pull-down resistor is being used.

*I am not using a particular SPI frequency since I should be slow enough and not going too fast for the IC.

*ST25R3911B IC is soldered to a breakout board with male headers and then placed in a breadboard.

*Arduino to ST25R3911B pin connections:

-Arduino SS GPIO pin 10 -> ST25R pin 32

-Arduino MOSI GPIO pin 11 -> ST25R pin 31

-Arduino MISO GPIO pin 12 -> ST25R pin 29

-Arduino SCK GPIO pin 13 -> ST25R pin 31

Below is my Arduino code (probably not that helpful) and a screenshot of the commands being sent using a logic analyzer:

CODE:

const byte SS_PIN = 10;
const byte MOSI_PIN = 11;
const byte SCK_PIN = 13;
 
byte bitArray[16] = {0x01, 0b00010000, 0x3F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF};
 
 
// Function is only run once
void setup() {
  Serial.begin(115200);
  pinMode(SS_PIN, OUTPUT);
  pinMode(MOSI_PIN, OUTPUT);
  pinMode(SCK_PIN, OUTPUT);
 
  digitalWrite(SS_PIN, HIGH);
  digitalWrite(SCK_PIN, LOW);
}
 
 
void loop() {
  delayMicroseconds(500);
 
  
  digitalWrite(SS_PIN, LOW);
  for (int n = 0; n < 2; n++){
    for (int m = 7; m >= 0; m--){ // reverse byte for MSB first
      digitalWrite(MOSI_PIN, bitRead(bitArray[n], m));
      digitalWrite(SCK_PIN, HIGH);
      digitalWrite(SCK_PIN, LOW);
    }
  }
  digitalWrite(SS_PIN, HIGH);
 
  
  delayMicroseconds(100);
 
  
  digitalWrite(SS_PIN, LOW);
  for (int n = 2; n < 6; n++){
    for (int m = 7; m >= 0; m--){ // reverse byte for MSB first
      digitalWrite(MOSI_PIN, bitRead(bitArray[n], m));
      digitalWrite(SCK_PIN, HIGH);
      digitalWrite(SCK_PIN, LOW);
    }
  }
  digitalWrite(SS_PIN, HIGH);
 
 
  delayMicroseconds(500);
}

LOGIC:

0693W000008xqMiQAI.png 

Any answers as to what I may be doing wrong to not get a response would be very appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions

Uncontrolled timing via bit banging is likely most problematic.

W​atch particularly initial chip select edge to first clock and data.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

8 REPLIES 8
MMcAl.1
Associate III

@Ulysses HERNIOSUS_O​ or @Travis Palmer_O​ would you be able to weigh in and give any recommendations?

Ulysses HERNIOSUS
ST Employee

Hi MMcAI.1,

reading registers from ST25R3911B requires setting the read-flag 0x40. So for reading chip identity register 0x3F you need to send MOSI byte 0x7F.

Regards, Ulysses

Thanks for the answer.

I am still not receiving anything over MISO. Below is the logic waveform while the 10k pull-down is connected from MISO to GND:0693W000008xruCQAQ.pngWithout the pull-down I am seeing random data on the MISO line:

0693W000008xruMQAQ.png 

Could this be some kind of GND issue? What's the best way to test all my ground connections? Again, I am setting up a minimal test like on Figures 2 & 3 of the datasheet.

Thanks for your help.

Hi,

reading random data when MISO is floating and without pull resistor is expected. However the device should respond to 7Fh with one byte. Random data is actually a good indication that nothing else is driving MISO pin. Not sure why you read two more bytes, but not important for the problem at hand.

IMO the device should respond if correctly supplied. Please check VDD_IO, VDD and VSP_D voltages. Please make also sure about proper external components especially on VSP_D.

Maybe verifying your setup by using X-NUCLEO-NFC05A1 as reference could also help.

Regards, Ulysses

Hi,

I checked VDD_IO and VDD (which are tied to the same source) and have about 4.7V on them. I have added decoupling capacitors from the 5V line to GND as is done in the DISCO and NUCLEO board schematics.

Regarding VSP_D, I am using the same value of decoupling capacitors as seen on pg. 4 of the X-NUCLEO-NFC05A1 and as recommended on pg. 18 of the ST25R3911B datasheet in Table 4.

To check VSP_D's voltage, I referred to pg. 18 of the ST25R3911B datasheet in the second paragraph below Table 4 where it says with 5V on VDD and VDD_IO I should see 3.4V on VSP_D. I am seeing 2.88V on it.

I have stopped using the pull-down resistor. See the below waveform screenshot to see the result. Still seeing random data.

0693W000008y6AiQAI.pngAny other ideas about the best course of action?

Hi,

no educated guesses anymore. We had some doubts about clock high pulse length which is not clearly visible in your screenshots. But with SW based banging of signals it should be ok. Do some of:

  • Double check connections on your board (also chip orientation)
  • Measure supply currents
  • Disconnect MCU, connect to X-NUCLEO-NFC05A1 and see if it works there
  • Unpower, disconnect MCU, use multimeter to measure protection diodes and compare against X-NUCLEO-NFC05A1 (red on GND, black on signal)
  • ....

Regards, Ulysses

Uncontrolled timing via bit banging is likely most problematic.

W​atch particularly initial chip select edge to first clock and data.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi MMcAl.1,

 

I have already provided further down some recommendation what else you could check (cross-connect to NFC05, etc.). I don't see anything wrong with your software.

 

Regards, Ulysses

(irrelevant - posted by mistake, Sorry)