Problems with SPI communication with ST25R95

[JCres.1]

Hi,

We are facing a lot of problems with the SPI communication with an ST25R95 device.

We are using as a main CPU an Silicon Labs EFR32MG13 with the next configuration:

 config.master    = true;      // master mode

 config.baudrate   = 1000000;      // CLK freq is 1 MHz

 config.autoCsEnable = true;      // CS pin controlled by hardware, not firmware

 config.clockMode  = usartClockMode0; // clock idle low, sample on rising/first edge

 config.msbf     = true;      // send MSB first

 config.autoCsHold = 1; /** Auto CS hold time in baud cycles */

 config.autoCsSetup = 1; /** Auto CS setup time in baud cycles */

For example, if we send the next stream of bytes in order to execute an echo command:

{0x01, 0x55, 0x03, 0x03, 0x02, 0x03}

We receive the correct answer only if we stop the execution after sending each byte, if not what we receive is:

{0x06, 0x06, 0x00, 0x00, 0x00, 0x00}

And since this moment the ST25R95 will just only send us zeros.

Is there any way to restart the chipset from this state without remove the power supply?

Also, we don't know if the chip select pin must remain low during all the read and write transaction or if it must be set and reset for each byte.

Thanks a lot and regards,

[Ulysses HERNIOSUS]

Hi,

the ST25R95 does not support UART communication.

The compatible older CR95HF had UART but UART is not recommended to be used. There may happen situations where a power cycle is needed.

Regards, Ulysses

[JCres.1]

Hi.

I mean SPI, not UART. Excuse me for the mistake.

[Brian TIDAL]

HI,

the ST25R95 does not have a dedicated RESET pin. There is a reset command (control byte 0x01, see ST25R95 Datasheet §4.1.1) but likely not usable in case the SPI is stuck.

Regarding the stream {0x01, 0x55, 0x03, 0x03, 0x02, 0x03},this does not send a command but reset the ST25R95. The proper stream to send an echo is 0x00 0x55.

I would recommend to poll the nIRQ_OUT pin rather than sending poll command (0x03) due to limitation mentioned in ST25R95 Datasheet §5.9.

The behavior of the SPI_SS (Chip select) is described in ST25R95 Datasheet §4.1.1:

"The SPI_SS line is used to select a device on the common SPI bus. The SPI_SS pin is active low. When the SPI_SS line is inactive, all data sent by the Master device is ignored and the MISO line remains in High Impedance state.

[...]

‘Sending’, ‘Polling’ and ‘Reading’ commands must be separated by a high level of the SPI_SS line. For example, when the application needs to wait for data from the ST25R95, it asserts the SPI_SS line low and issues a ‘Polling’ command. Keeping the SPI_SS line low, the Host can read the Flags Waiting bit which indicates that the ST25R95 can be read. Then, the application has to assert the SPI_SS line high to finish the polling command. The Host asserts the SPI_SS line low and issues a ‘Reading’ command to read data. When all data is read, the application asserts the SPI_SS line high. [...]"

I would recommend to have the CS pin being controlled by the firmware, not by the HW.

I would also recommend to use the X-CUBE-NFC3 package that provides an NFC communication stack API and a ST25R95 driver that can be easily ported to a 32-bits ARM based MCU.

In order to investigate your SPI communication, can you send me a logic analyzer trace of the init sequence (i.e. from power up) up to the ECHO command. Please include the following signals: SPI: CLK/MISO/MOSI/SS, SSI_0/SSI_1, IRQ_IN and IRQ_OUT

Rgds

BT