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?

[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?

[Brian TIDAL · Accepted solution]

Hi,

I confirm that the package Linux_RFAL_st25r95_v2.0.4.tar.gz properly compiles and runs on RPi3.

The SPI SS pin is managed by software as a GPIO. Make sure that the allocated pin is free to be used. If needed, reallocate the cs0_pin used by the HW to another pin (use dtoverlay spi0-1cs,cs0_pin=x in /boot/config.txt where x is an unused pin).

Again, I would recommend to probe the SPI SPI CLK/MOSI/MISO/CS + SSI0 + SSI1 + IRQ_IN and IRQ_OUT with a logic analyzer to see what is going wrong.

Note: st25r95_com_spi.c should not be modified (in particular, there should not be a dummy byte in the echo command).

Rgds

BT