SPI fails after Idle command, or refuses to work at all

[herringfish]

I am using an ST25R95 controlled over SPI by an STM32L452RE MCU. It has been running just fine and reading NFC tags using a custom driver for it, but recently has stopped working. The ST25 chip appears to stop responding to SPI commands after it enters the idle command. Previously, it was able to wake up from idle after being reset and then given an nIRQ_IN pulse. This issue seems to be getting worse, as sometimes the chip doesn't even respond at all now even after being power cycled.

Does anyone know why this might be happening? I can't figure out what is wrong.

Here is the schematic for our RFID reader, mostly copied from the dev board for this chip.

 

[Brian TIDAL]

Hi,

when in Idle mode, some parts of the device are no longer powered/clocked to achieve the low power state. In particular, the SPI is no longer available for communication until Idle mode is exited. Thus, it is not possible to send SPI control frame such as SPI Poll (see §5.9 in the ST25R95 datasheet) and application has to rely on IRQ_OUT before reading the answer to the Idle command. If the application wants to exit the device from Idle mode, the wake-up source has to include "low pulse on IRQ_IN". The pulse on IRQ_IN has to follow the same sequence as the startup sequence (in particular the t3 delay has to be respected to have the HF oscillator being stable). After the t3 delay,  send an SPI Poll frame. If the response flag indicates "Data can be read from the ST25R95", you can read the Idle response with the wakeup flags. Depending on the Idle parameters being used, there might be no response to the Idle command when exiting from Wait for Event. In that case the SPI Poll response flag indicates "Data can be sent to the ST25R95".

I would recommend to connect a logic analyzer on the SPI (CLK/MISO/MOSI/CS) + IRQ_IN + IRQ_OUT and to send me the trace.

Rgds

BT

 

[herringfish]

Hi Brian,

Thanks for the response. It seems like we were not respecting the 10ms wait time strictly enough. We had an 8ms wait time which could have been contributing to this inconsistent behavior.

Additionally, we were setting up the ARC_B register but realized we don't need to modify its values from what is set in the protocol select command, so this may have also caused us issues with receiving and waking up the chip.

Let me know if you have any thoughts about these changes. It's possible it's just a coincidence and we have a deeper issue.

[Brian TIDAL]

Hi,

ARC_B values are used to override default protocolSelect values. Therefore, there should be no impact of modified ARC_B values on Idle command.

After the t3 delay after sending IRQ_IN in Idle mode, the IRQ_OUT should get high to signal the availability of the response to the Idle command. If IRQ_OUT is low, send an SPI poll control and check the response flag.

Can you share the dump of the Idle command sent by your application?

Rgds

BT

[herringfish]

Here is our logic analyzer output. You can see constant reads from the reader, and resets of the PCB around 34, 50, and 60 seconds. You can see that after the reset at 50, it stops trying to search for tags, and after that point, it is unable to reset properly or communicate over SPI.
I've also included a screenshot of our idle bytes.

 

 

 

[Brian TIDAL]

Hi,

if I am not wrong, the wake source in your application is only tag detection (0x02) and therefore a pulse on IRQ_IN will not exit from Idle mode. 

If your application has to support wake up by both IRQ_IN pulse and tag detection, make sure to have WU source = 0x0A (low pulse on IRQ_IN | tag detection).

The wakeup control parameter does not have the value recommended in the ST25R95 datasheet (0x3801):

As I can read Salae files, feel free to send me the trace (make sure to include both IRQ_IN and IRQ_OUT)

Rgds

Bruno