Problems communicating to the ST25R95 using SPI -- No communication from IC

[EHugh.2]

My setup is as follows:

• ST25R95 is in a QFN32 chip holder (https://www.amazon.com/gp/product/B01N6NF3ME/), which allows me to test with test leads to a breadboard.
• Powering chip (VPS and VTx) with 3.3V with a bench power supply, which reads a constant 0.25-0.26 Amps current when the IC is powered. If I disconnect the Tx power, it pulls 0.18 Amps.
• SPI interface, SSI_0, SSI_1, IRQ_IN, IRQ_OUT from a Raspberry PI 4B+. I've tied grounds from bench supply and raspberry pi to avoid floating grounds.
• SPI clock is 1 MHz.
• A Wurth 27.12 MHz crystal oscillator (model number 830014948B) with 10 pf capacitors. (Tested with and without this attached.)
• Logic Analyzer is a Digilent Analog Discovery 2 (https://digilent.com/shop/analog-discovery-2-100ms-s-usb-oscilloscope-logic-analyzer-and-variable-power-supply/) running Waveforms software (https://digilent.com/shop/software/digilent-waveforms/).
• Communication software Python 3 script and SPI using spidev. spidev ensures proper SS (Select) control. It goes low before the command and returns high after commands are sent. Logic Analyzer shows this code is working properly.

After 8 days of trying, I've not been able to get any communication out of the IC. I purchased 3 of these and have swapped out a fresh IC in case the 1st was fried.

My script setups the GPIO pins of the Raspberry Pi as well as the SPI interface. When power is supplied, the script::

• sets SSI_0 to 1 and SSI_1 to 0
• I have a buttons that:
  • sets IRQ_IN to low for 0.5 seconds
  • opens the spi communications
  • sends 0x00, 0x02 (plus other settings) for 15693 protocol
  • sends 0x01 (IDN) for requesting info
  • sends 0x02.to read 13 bytes (also attempted reading 1 byte at a time)
  • has an input box to allow me to enter commands not programmed in my buttons.

The documentation is confusing in that it says 0x00 is required to send a command. However, none of the examples show this. An IDN request should be 0x00, 0x01, 0x00 according to the written instructions. I never get any response on the IRQ_OUT pin, so I also tried polling. Even after a second between each poll request, I still could not get any response from the chip.

The examples are more confusing than helpful. The IDN command examples says to issue "0x0100" That is 256 , but I did try that as well. I also tried 0x00 and this command. And as I said, I also tried 0x00, 0x01, and 0x00.

I would like to see some form of output from the IC. What am I doing wrong? I would assume the crystal osc is not required just for communication testing, but I did also try with this.

I am more than willing to send pictures of the setup and my script. Please help.

[Brian TIDAL]

Hi,

the chapter 4 of the ST25R95 Datasheet describes the SPI communication protocol layer between a host MCU and the ST25R95. This communication protocol is used to convey the various commands such IDN, ProtocolSelect, SendReceived, etc. The command layer is described in the chapter 5. When those commands are sent over SPI, they are encapsulated as described in chapter 4.

The various commands follow the syntax: Cmd_id, Length, Data1..DataN where Cmd_id identifies the command (e.g. 01=IDN) and where Length is the length of the data related this command (Length = 0 when the command does not have data).

For example, the IDN command is 01 00 (01 = identifier of the command, 00 = length of the data)

When sending this command on SPI, it has to be prefixed by the 00 "Send command to the ST25R95" control byte. In order to read the reply from the ST25R95, a 02 "Read data from the ST25R95" has to be sent.

The various SPI frames (send command, poll, read data from the ST25R95) must be separated by a high level on the SPI SS line (see § 4.1.1).

Regarding your issue, I would recommend to check that

• the 27.12 MHz crystal is properly clocking the device (just probe and one should see something similar to figure 3 from AN3433)
• the nIRQ_OUT is high after the startup sequence (i recommend to use IRQ_OUT during SPI communication rather than polling)
• the SPI is properly configured (Motorola format, 8 bits data, MSB first, clock polarity low, clock phase 1 edge),
• the SPI SS is properly connected, MISO and MOSI are not swapped
• the SPI SS is properly driven (high level between SPI frames)
• the startup sequence follows §3.2
• the chip is replying to the SPI poll command after the startup sequence and the bit #2 of the response is 1 ("Data can be sent to the ST25R95" see table 5).
• the chip is replying to the echo command

Also, I would suggest to connect a logic analyzer on IRQ_IN, IRQ_OUT, SPI_CLK/MOSI/MISO/SS, SSI_0, SSI_1 and to send me the trace of the initialization sequence and SPI communication

Example of commands

First frame: 03 XX SPI Poll. Answer is XX 06 ==> bit #2 =1: data can be sent to the device

2nd frame: 00 55 : Send Echo command

IRQ_OUT goes low

3rd frame 02 XX XX XX read Echo response

4th frame 00 01 00: send IDN command

Rgds

BT

[EHugh.2]

Thanks for the very thorough response. I have attached my logic analyzer tests as well as a screen shot of my Python test Script. As you see from the script, I've created code to buttons so I know what is sent and when.

I'd like to respond here to some of your suggestions:

(1) Clock probe. I do not see the response with my oscilloscope when I probe the clock as shown in Figure 3 of your link. Its mostly noise.

(2) I never see anything on IRQ_OUT. The logic analyzer shows that it is always low.

(3) Section 4.1.1 of the datasheet says that CPOL=CPHA=1 or CPOL=CPHA=0. I tried both of those. Based on your suggestion, I also tried CPHA = 1 and CPOL = 0. I saw no change in performance (or lack thereof).

(4) MISO and MOSI are properly connected (see attachments)

(5) SS is being set high between commands (see attachments)

(6) The chip is not responding to the any command, including the echo command.

So I'm still not able to talk to this at all. This is not the first time I've communicated to something with SPI, so I'm quite confused as to what could be the issue. I have confirmed power is getting to the IC holder. I loaded my 3rd IC into the holder for these tests (just in case I fried the previous 2 IC's.) I ordered another 3 just in case I have damaged these 3, but I am at a lost right now as to what to try.

[Ulysses HERNIOSUS]

Hi EHugh.2,

I see you are using a socket for the ST25R95. This should work for digital experiments/bring-up however I would like to warn that this may get difficult when moving to actual RF communication (additional resistance induced by socket, trace lengths to matching network and supply buffer structures, impedance control, etc.).

Maybe an X-NUCLEO-NFC03A1 would be an alternative / additional option for you.

Best Regards, Ulysses

[EHugh.2]

I had purchased one of these from Mouser, but it came with a type A to type B USB cable. There is no type b (or any other USB type) connector on the board. It took me a while to figure out that it didn't go with the board supplied. The link for software that is supplied on the card inside goes to a general page for all Nucleo devices. If you drill down, you can finally get to the -NFC03A1 product page. I downloaded the Getting Started document, and it said needed a STM32 nucleo board for my board to attach. I see that has type b connector, so I assume that cable is for this. Its weird they included a cable for a board that isn't included. I have yet to find all the software required to run this.

So it seemed to me to be much easier going with my approach. I had the software written in a hour and the initial hookup in about 30 minutes. Of course, I haven't had any luck with my approach yet. Maybe I will have to go back to this. If you have a link for all the software I am suppose to use, I'd appreciate it. If there is also a preferred STM32 Nucleo board I should buy, please let me know.

I do agree with you about the potential of having different resistance, impedance, capacitance, etc with my setup and an external antenna. But I have a vector network analyzer, and I use it to help tune the antenna. I don't plan for this to be the final deliverable -- I''m just trying to make sure I am properly talking to the IC first.

Thanks for your help.

[Brian TIDAL]

Hi,

the digital part of the IC needs a proper clocking. If the crystal is not properly providing a 27.12 MHz clock, the IC will not be able to answer on the SPI.

After power on, the IC enters the Power-Up state: in this state the 27.12 MHz High Frequency Oscillator (HFO) is off. The HFO will be enabled during the startup sequence thanks to the IRQ_IN pulse. Once the HFO is ready, the IC can reply to the various commands on the selected interface (SPI).

I would suggest to check that:

• the IRQ_IN is properly pulled-up so that the IC can properly detect the transition from high to low. See the reference schematics in UM2479 with a 3.3kOhm pull up on IRQ_IN and IRQ_OUT
• the crystal is properly mounted
• the various GND, GND_TX, GND_RX, NC pins are properly grounded
• ST_R1 is connected to VPS (with 3.3k resistor) and ST_R0 has a 1nF capacitor connected to GND

Regarding the X-NUCLEO-NFC03A1, it can be used without a STM32 Nucleo board. You just need to connect some wire jumpers between the X-NUCLEO-NFC03A1 and your RPi board (power supply, SPI, IRQ, etc.). You can also use an ARPI600 Raspberry Pi to Arduino adapter (see UM2548 explaining a similar setup with X-NUCLEO-NFC06A1 but that can be use as well or X-NUCLEO-NFC03A1). I believe that RPI4+ARPI600 interposer+X-NUCLEO-NFC03A1 will provide you a more stable prototyping environment that a QFN chip holder.

Rgds

BT

P.-S. if you want to use an STM32 Nucleo (to see our various NFC demos), I would recommend the NUCLEO-L476RG. For the FW (C source code and binary), I would recommend the STSW-ST25R-LIB (then select STSW-ST25R017 package for ST25R95).

[EHugh.2]

Thanks BT. This was an extremely helpful response. I am talking to the chip now!

The important connections were the pull-up resistors on IRQ_IN and _OUT. Without the pull-up on the IRQ_OUT, there doesn't seem to be any communication.

I tested the oscillator as shown in the attachment. I used a function generator at 3 VDC output to drive one leg of the quartz crystal. I attached the o-scope to the other leg, and connected grounds. I increased the frequency, and at 27.12 MHz the crystal resonated and I got a 4 times increase in the waveform strength. This proved it was working. I then attached it directly to the 2 pins on the chip holder. When I powered up and started my application, the crystal came alive.

The ST_R0 and _R1 connections you suggested didn't have much of an impact. And whether I use CPOL = 0, CPHA=0, or CPOL=0, CPHA=1 seemed to have no effect. Although I haven't tried to interpret the data I'm receiving yet.

I am now getting response on the MISO line. Until today, I'd never seen any digital IO on this. And they match some of the responses you showed on the figure you supplied.

I have yet to see anything on IRQ_OUT (i.e, it going low when I send a polling command), but pulling it high is essential for communication. It could be that I have either too much or too little values for the pull-up resistor.

My next effort is to interpret the data I'm seeing, and add the antenna to test tag reads. So I may be back for more help then.

This has been somewhat painful, but it does force you to understand what's important for adding the IC to your design. I'm glad I didn't commit to my board layout before doing this. The chip holder seems to be a good way to test if you don't know whether or not you''ll be using an ST microcontroller. I think some of these things you suggested should be in the datasheet, such as, the pull-up resistors and the 27.12 MHz crystal operation.

Thanks again for your awesome support on this matter.

[Brian TIDAL]

Hi,

thanks for your feedback: good to see the digital is now up and running.

Regarding "I have yet to see anything on IRQ_OUT (i.e, it going low when I send a polling command)": when relying on IRQ_OUT interrupt mechanism, there is no need to send a SPI polling frame. The IRQ_OUT will automatically go low when a response to a previously sent command is available. See for example the logic analyzer screen shot in my initial answer (IRQ_OUT goes low when an answer to the echo command is ready to be read).

Regarding the pull up issue, can you check the configuration of the RPI4 GPIOs connected to IRQ_IN and IRQ_OUT? There might be a conflicting internal pull-up/pull-down configuration.

I have some questions related to your application: will you use python in your final application for driving the ST25R95 or do you plan to run our NFC RFAL communication stack? Can you share some details about your application? (feel free to reply in private message).

If you find another issue in your next steps, would you please create a new post ?

Thanks

Rgds

BT

[EHugh.2]

Hello BT,

Good point on the Raspberry Pi IO. I decided to use external pull ups for all the lines instead of using the built-in functions of the Raspberry Pi. But that is a good point -- I didn't proactively disable anything internally. I think there are smaller pull-downs on all pins when acting as a input. I will check it.

I would like to be able to use python for communication. The system I'm designing will require an MCU and wireless communication capability. It will read tags and I'm using the 15693 protocol. I'm now also studying the STM32 processors. I've got the board layout now for this IC done, but I have to add the MCU and communication IC's. After the prototype, my initial run will be about 10000 boards. Larger runs will likely proceed after that one. I'll send you a direct message.

I will create new posts for new issues.

Thanks again for your excellent help.