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

EHugh.2 · ‎2022-01-10

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.

EHugh.2 · ‎2022-01-13

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 · ‎2022-01-13

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

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

EHugh.2 · ‎2022-01-16

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.