Using CR95HF in tag detect mode

[ADoug.1]

Hello,

I am trying to use the CR95HF chip in tag detect mode. I am communicating with the chip over UART and am trying to save power by putting the chip into tag detect mode so it will only wake up when a tag is detected.

However, in case of a system error I want to have the chip either wake up due to a timeout if it has not detected a tag or be able to wake it up using a low pulse on IRQ_IN.

Could you please tell me if waking the chip using a low pulse on IRQ_IN is possible if communicating with the chip over UART? I have set the WU source byte to 0x0A to include tag detection and low pulse on IRQ_IN as wake-up sources but when I do this only the tag detection causes the chip to wake. Full command being sent in this case: 07 0E 0A 21 00 79 01 18 00 20 60 60 64 74 3F 28.

If it is impossible to wake the chip using IRQ_IN, then how do I have the chip go into tag detect mode and wake it EITHER when a tag is detected or when the timeout is triggered. In this case I have tried setting the WU source to 0x09 to include tag detection and timeout but then the chip then will not wake up due to tag detection and will timeout every time. Full command being sent in this case: 07 0E 09 21 00 79 01 18 00 20 60 60 64 74 3F 28.

Thanks in advance.

Amy

[Brian TIDAL]

Hi,

when communicating over UART, the IRQ_IN pin is actually used as UART_RX and your MCU is probably preventing you from driving this pin directly. It is rather recommended to use a low pulse on SPI_SS as a wake up source from the MCU in case of UART communication. The WU Source is then 12h (SPI_SS and tag detect) or 13h (SPI_SS, tag detect and timeout).

The WU Source format is the following:

• bits 7:6 LFO prescaler
• bit 5 RFU
• bit 4 Wake-up source: low pulse on SPI_SS
• bit 3 Wake-up source: low pulse on IRQ_IN
• bit 2 Wake-up source: field detected
• bit 1 Wake-up source: tag detected
• bit 0 Wake-up source: timeout

When using WU source = 09h, the wake source are: timeout or low pulse on IRQ_IN and therefore this does not include the tag detection.

Rgds

BT

[ADoug.1]

Hello,

Thanks very much, I can now have the chip waking due to a timeout or a tag detection by setting the WU source byte to 0x03.

For waking the chip through the IRQ_IN pin, is there a reason why the CR95HF chip would not respond to this when configured to use UART communication? As I use the IRQ_IN pin to wake the chip originally, after the UART on my MCU has already been configured so this would make me think it is possible to toggle the pin at the MCU side.

Thanks again for your help!

Amy

[Brian TIDAL]

Hi Amy,

the datasheet does not give much details on this, but reading between the lines:

• when using SPI communication mode, IRQ_IN should be used as a WU source
• when using the UART communication mode, SPI_SS should be used as a WU source

This is the way the Idle command has been implemented in our X-CUBE_NFC3.

By the way, I would recommend to use our X-CUBE_NFC3 that provides a portable stack supporting the various NFC technologies (ISO15693, ISO 14443 A/B, Felica). It supports by default the SPI communication but UART communication mode can be provided on demand.

Can you share (maybe in private) more information regarding your application? Do you use a X-NUCLEO-NFC03A1 board or your own custom board?

Rgds

BT

[ADoug.1]

Hi Brian,

I thought that might be the case, thanks for confirming.

I am actually using the M24LR-DISCOVERY kit for development at the moment but unfortunately I cannot use SPI_SS in my final application, hence why I was hoping to use the IRQ_IN pin instead. However, I will be able to make it work using the timeout.

Thanks again for all your help!

Amy

[Brian TIDAL · Accepted solution]

Hi Amy,

even if your MCU does not have SPI, you can still use a simple GPIO connected to SPI_SS pin to wake up the CR95HF.

For your information, the M24LR-DISCOVERY firmware is based on different library than our common RFAL API provided for ST25R95/CR95HF, ST25R3911B and ST25R3916 readers. Using the RFAL API provides sw portability to the various NFC Readers of the ST25R familly. Of course, if the M24LR-DISCOVERY library already contains all the features you need for your application, you may prefer to keep it.

Rgds

BT