CR95HF Linux kernel driver

[GLi.6]

Hi,

I am working on linux kernel v4.19 to bring up the cr95hf via SPI, there is a existing driver called st95hf, I enabled it, and it can be probed. can get ECHO back.

when I used nfc neard to test the driver, it always gives errors like below:

[ 501.027260] spi_geni 988000.spi: Zero length transfer

[ 501.027307] st95hf spi1.0: SPI transfer failed: -22

[ 501.027393] spi_master spi1: failed to transfer one message from queue

[ 501.027436] st95hf spi1.0: spi_recv_resp, data read error = -22

[ 501.027471] st95hf spi1.0: spi error from st95hf_spi_recv_response(), err = 0xffffffea

[ 501.027506] nfc nfc0: protocol sel send field off, err = 0xffffffea

[ 501.036499] digital: digital_in_configure_hw: in_configure_hw failed: -22

[ 501.037971] spi_geni 988000.spi: Zero length transfer

[ 501.038042] st95hf spi1.0: SPI transfer failed: -22

[ 501.038181] spi_master spi1: failed to transfer one message from queue

[ 501.038246] st95hf spi1.0: spi_recv_resp, data read error = -22

[ 501.038298] st95hf spi1.0: spi error from st95hf_spi_recv_response(), err = 0xffffffea

[ 501.038351] nfc nfc0: protocol sel send field off, err = 0xffffffea

[ 501.048640] digital: digital_in_configure_hw: in_configure_hw failed: -22

[ 501.050030] spi_geni 988000.spi: Zero length transfer

[ 501.050090] st95hf spi1.0: SPI transfer failed: -22

I would like to know is there any verified cr95hf driver for linux kernel?

[Brian TIDAL]

Hi,

I would not recommend to use cr95hf kernel driver but rather a use space application. See https://community.st.com/s/question/0D50X0000AxElqLSQS/cr95hf-linux-rfal-demo for a user space package.

Rgds

BT

[GLi.6]

Hi Brian,

Thanks for your reply. I just checked the HW set up, cr95hf-linux-rfal-demo uses raspberry pi,

my HW set up is Qualcomm chipset (ARM) + SPI + CR95HF based on Ubuntu 18.04.

is there any driver in respberry pi that I need to extract? any idea that I can configure to fit my HW?

[Brian TIDAL]

Hi,

as this is a user space application, the changes should be minimal. This application uses open to access /dev/spidev0.0 (you'll need to customize according to your spi device) and sysfs to access the GPIO (you'll need to customize platform.h to fit with your pin assignment).

Rgds

BT

[GLi.6]

Hi Brian,

thanks for your response.

I just would like to confirm that ST25R95_N_SS_PIN would connect to SPI_CS, does it?

I have configured the HW set up according to my HW. seems SPI device node open/ioctl has no problem. but still got errors. like "RFAL initialization failed..."

and I looked into it, it seems exampleRfalPollerRun() -> rfalInitialize() --> st25r95Initialize() -> st25r95CommandEcho() -> st25r95SPICommandEcho() --> st25r95SPIPollRead()

when it got into st25r95SPIPollRead it will read platformGpioIsHigh, it is high, so got retCode = ERR_TIMEOUT, which is ST25R95_N_IRQ_OUT_PIN which is not changing to low.

Do you have any idea? or did I miss something?

Best Regards

George

[Brian TIDAL]

Hi,

I confirm ST25R95_N_SS_PIN is the SPI Chip Select or Slave Select. Can you check the configuration of the SSI0 pin and the  ST25R95_N_IRQ_IN pin? I would suggest to connect a logic analyzer on SPI CLK/MOSI/MISO/CS + SSI0 + SSI1 + IRQ_IN and IRQ_OUT during startup and to send me the trace.

Rgds

BT

[GLi.6]

Hi Brian,

Thanks for the confirmation.

Unfortunately, I do not have the logic analyzer, but I do have a scope, I probed the IRQ_OUT, IRQ_IN, and SPI_CS, SPI_CLK. because I only have 2 probes, so each time I only be able to probe 2 channels.

please see the attached scope_results.zip

From the scope, it seems, when SPI_CS pull low, the SPI_CLK would never come, and lead to the IRQ_OUT never gets low. Even there is no error happened during the SPI code executed. I think SPI might be something wrong.

For the SSI0, SSI1, SSI0 is pulled high, SSI1 is pulled low physically for SPI. so did not set ST25R95_SSI0_PIN

Also, I synced up a SPI test program (https://github.com/rm-hull/spidev-test), and I run it, I could get the expected results, and I probed the SPI_CLK, it was coming.

I was able to get the results like below: which means Qualcomm chip side has no problem.

$ ./spidev_test -v

spi mode: 0x0

bits per word: 8

max speed: 500000 Hz (500 KHz)

TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....?..................?.

RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....?..................?.

looking forward to hearing from you.

[Ulysses HERNIOSUS]

Hi GLi.6,

clearly something wrong with your signals. Your scope shots are not conclusive to me. Maybe you can go signal by signal and verify it behaves as expected when stepping the application (you may even want to disconnect the ST25R95 at first to see only what your MCU is driving).

Best Regards, Ulysses

[GLi.6]

Hi Ulysses,

Thanks for your reply. Actually I have enabled linux driver /driver/nfc/st95hf with my Qualcomm chipset.

I even can read back the IDN at the beginning of the probe. but when I tried neard based on linux driver, it gave me errors like I attached at the beginning of this thread.

as you suggested, I will disconnect CR95HR, and run nfc_poller to see what is happening by signal, right?

[GLi.6]

By the way, as I said above, I can get the SPI test program working which means my MCU is driver fine.

Please see the attached SPI_CLK_MOSI

[GLi.6]

but when I run nfc_poller, there was nothing coming out, at least the spi CLK should be coming.

[GLi.6]

I can get the spi working when run ./nfc_poller/nfc_poller_st25r95. please see the attached. but still got failed initialization. Any idea?

Welcome to the ST25R95 NFC Poller Demo on Linux.

Scanning for NFC technologies .

RFAL initialization failed...

[GLi.6]

By the way, here is my changes by my HW configuration. please check if anything missing?

[Ulysses HERNIOSUS]

Hi,

I see changes some changes in there without reasoning: Default state of SSI0 and SPI dummy byte. What is your rationale of performing those?

As already indicated by Brian it is very hard to trace down the issue without following the flow of all the signals. Please try to get a logic analyzer and do traces of the initialization sequence. It shortens a lot the debugging process.

BR, Ulysses

[GLi.6]

Thanks for your reply, Ulysses.

Let me tell you why I changed that: in order to choose SPI, we need to set SSI0: 1, SSI1: 0. so I already set that on HW, so I commented out the SSI setting in the code. SPI dummy byte is because Linux driver is sending 00 01 00 for the reset. and it can get interrupt.

Did you really run the code Linux_RFAL_st25r95_v2.0.4.tar.gz on your platform (Raspberry pi)?

Can you even compile it without changing anything?