ST25R95/CR95HF Wake-up from Hibernate

[TMido.1]

I'm using a X-NUCLEO-NFC03A1 board with a NRF52 as host controller. I'm able to read/write commands and set the chip to WFE mode with Tag Detection and IRQ pulse as WU sources.

Now I'm setting it to hibernate and, as far as I understood from the datasheet, it should go from hibernate to active state only by setting the IRQ_OUT pin to low state, and then I'd be able to read the chip response that should return the WU source as IRQ pulse (0x000108).

However, I seem to be unable to use the chip once it's back from hibernate state, and it only works again after I send a RESET command. I found this strange as the startup sequence shows it differently. Is this correct or am I doing something wrong?

ps. I also get 0x0000 as a first response from the chip, which is also strange as it is not mapped as a valid response in the datasheet for an IDLE command.

[Brian TIDAL]

Hi,

I have some questions to better understand your issue:

• do you use the UART or the SPI interface? I guess this is the SPI interface as you mentioned the RESET command, but prefer to make sure.
• If using the SPI interface, do you use the SPI Poll control or do you wait forIRQ_OUT event before reading the reply from the ST25R95. Note that In low power consumption mode the device does not support SPI poll mechanism. Application has to rely on IRQ_OUT before reading the answer to the Idle command (see ST25R95 datasheet §5.9).
• you mentioned using IRQ_OUT for the wake up source. Is it a typo? (IRQ_OUT is not one of the wake source whereas IRQ_IN is one of the wake up source)
• do you use X-CUBE-NFC3 library or your own driver?
• can you provide the hex value of the IDLE command sent to the ST25R95

Rgds

BT

[TMido.1]

Hi Brian,

Thanks for the quick response!

First lemme answer your questions:

1. I'm using SPI interface and the IRQ_OUT before reading the chip response.
2. Oops, it was a typo indeed. I use IRQ_IN as WU source.
3. I am using my own driver
4. The HEX I send for hibernation is: 0x07 0e 08 04 00 04 00 18 00 00 00 00 00 00 00 00 (the same as in the datasheet)

I found out that it's not the RESET command that is waking it up, but the IRQ_IN inside of it as expected (yay)

BUT (there's always a but) I also noticed that right after sending a IDLE-hibernate command, the chip sets the IRQ_OUT to low and replies with that 0x00 00 hex. I assumed this was a confirmation that it went to hibernation, but this is not stated in the datasheet...

My mistake was that I was expecting this response (thus my semaphore was waiting for a low IRQ_OUT) only after waking up, and it was also expecting a 0x00 01 08, and not 0x00 00<anything else>.

1. Is this the expected response for hibernate state?
2. I'm writing some tests and I can't seem to set it to receive the "confirmation" for hibernation in the second time I hibernate/wakeup - hibernate/wakeup. Is there a reason for this?

Thanks again!

[Brian TIDAL]

Hi,

in §5.9.4 of the Datasheet it is stated that "The wake-up flag value is NOT significant when returning to Ready state from hibernate state or after a POR" , therefore I guess the device does return 0x00 00 when returning from hibernate state. I'll do some experiments to confirm this behavior and will ask a datasheet update to clarify this behavior.

The reply to the Idle command occurs:

• immediately in case of error (e.g. 0.82 00)
• otherwise only when ST25R95 exits WFE mode

I suspect that the IRQ_IN may be somehow floating and causing premature exit from WFE. Do you have a 3.3kOhm pull up resistor on the IRQ_IN signal? See R12 resistor in schematics in UM2479. Can you probe IRQ_IN, IRQ_OUT and SPI signals with a logic analyzer and send me the trace?

Thanks

Rgds

BT

[Brian TIDAL]

Hi,

here are some clarifications of the Idle command behavior.

The Idle command does not return a reply in case of low pulse IRQ_IN wake up.

In the X-CUBE-NFC3 firmware code:

• the reading of the reply is conditional (i.e. if IRQ_OUT is low, the reply is read, otherwise the code continue).
• Then in case of Idle command being killed by IRQ_IN, a SPI Poll command is sent to check the readiness of the ST25R95 (and bit #2 "Data can be sent to the ST25R95 when set." in the flags is checked)

Rgds

BT

[TMido.1]

Hi,

Sorry for the delay. I had managed to solve this issue by setting the power up sequence delays exactly as in the datasheet (I had set with a bit of margin before).

Apart from this, it works as Brian described in the previous answers.