cr95hf won't pole after idel command

[MUnge]

Hi i am using an cr95hf. After using an idel command and waking up afterwards any command I send after the idle wont work. I don't even get a polling response. Unfortunately I can't find anything in the cr95hf datasheet telling me if i need to reset or anything similar after exiting the idle mode. Also I am using the cr95hf as the plug and it is connected to an atmega 128 and I am communicating via SPI.

[Brian TIDAL]

​Hi Michael,

I have implemented the software polling mechanism instead of reading the IRQ_OUT. I think I have found the issue you face in Idle mode: sometime the SPI poll reply seems to be corrupted (maybe due to the RF swing sent by the tag detector). The bit b3 has a wrong 1 value. The Idle reply is also erroneous (probably reading the prepared default reply in the CR95HF SPI buffer)  and the device is still in Idle mode and ignoring the next command being sent.

I suggest the following workaround (unless you connect the IRQ_OUT to the MCU):

• in the Idle command, use Wake-up flag = 0Ah (tag detected or IRQ_IN pulse)
• when poll returns bit b3=1, send an IRQ_IN pulse to force the CR95HF to exit the Idle in case the poll reply was erroneous and the device is still in Idle mode
• read the Idle reply. if wake up is not due to tag Detected, you can resent the Idle command

If it is not too late and not changing too many things, I would suggest to connect the IRQ_OUT to the MCU and to rely on it for the polling of the data.

I've also tried to connect a logic analyzer. When the analyzer is connected, the issue disappears, that why I believe this is a kind on shielding issue on the SPI when the tag detector send the RF swings.

Let me know if the proposed workaround solves your issue.

Rgds

BT

[MUnge]

Hi Brian,

i ll sodler a connection to the IRQ_OUT pin and try the work around today. I'll get back to you with the results probably tomorrow.

thank you for your Help.

[MUnge]

Hi Brian,

so i tried the work around and unfortunately it didnt work for me. I send a log of what I did and what i got in response from the chip. I sent the idle command and afterwards did the Anticol with reading the UID (cr95hf datasheet appendix D.1.2). It feels like the chip still doesnt leave the Idle mode.

I soldered a connection to the IRQ_OUT but I didnt find anything in the datasheet as what to expect at this pin. Can you maybe link me the File of the API.

Best Regards

Michael

[Brian TIDAL]

Hi Michael

See §4.1.2 in the ST25R95 Datasheet: "When the ST25R95 is ready to send back a reply, it sends an Interrupt Request by setting a low level on pin nIRQ_OUT, which remains low until the host reads the data. The application can use the Interrupt mode to skip the polling stage."

Function st25r95SPIPollRead() in file st25r95_com_spi.c implements the polling of nIRQ_OUT with a timeout.

ReturnCode st25r95SPIPollRead(uint32_t timeout)
{
    uint32_t timer;
    ReturnCode retCode = ERR_NONE;   
    
    timer = platformTimerCreate(timeout); 
    while (platformGpioIsHigh(ST25R95_N_IRQ_OUT_PORT, ST25R95_N_IRQ_OUT_PIN) && (timeout != 0) && !platformTimerIsExpired(timer)) {;}
    
    if (platformGpioIsHigh(ST25R95_N_IRQ_OUT_PORT, ST25R95_N_IRQ_OUT_PIN))
    {
        retCode = ERR_TIMEOUT;
    }
    
    return (retCode);
}

if you don't need a timeout watchdog, you can simply read the GPIO connected to the nIRQ_OUT pin until its value is low (the GPIO connected to the nIRQ_OUT simply needs to be configured in INPUT mode, NO_PULL)

I had a quick look to your trace. It seems the ST25R95 is still in low power mode. Some tips about the nIRQ_IN:

The nIRQ_IN low pulse duration should be at least t1 then once the nIRQ_IN is high again, you have to wait t3 for the HFO setup time. On my side, the nIRQ_IN pulse reuse the same sequence as the startup sequence:

void st25r95SPI_nIRQ_IN_Pulse(void)
{
    platformGpioSet(ST25R95_N_IRQ_IN_PORT, ST25R95_N_IRQ_IN_PIN);
    platformDelay(1); /* wait t0 */
    platformGpioClear(ST25R95_N_IRQ_IN_PORT, ST25R95_N_IRQ_IN_PIN);
    platformDelay(1); /* wait t1 */
    platformGpioSet(ST25R95_N_IRQ_IN_PORT, ST25R95_N_IRQ_IN_PIN); 
    platformDelay(11); /* wait t3: seems more than 10ms needed */
}
/* platformDelay Performs a delay for the given time (ms)    */
/* platformGpioSet Turns the given GPIO High                   */
/* platformGpioClearTurns the given GPIO Low                    */

Let me knows if this works better.

Rgds

BT

[MUnge]

I Implemented the way with the IRQ_out instead of the polling and that seems to work for me.

I haven't tried again with the polling and the IRQ_In pulse as wake up source. But I can do that if that is valuable information for you.

I was also wondering how i can increase the range of the tag detection. Using the values i got from the calibration I can detect a iso 14443 a tag within 2 cm but only read it if it is right on top of the antenna. I can detect a 15693 tag within about 4 cm. I dont know what the common values are for 14443 but for 15693 that should usually be 10 cm, as far as I know thats even a requirement for the 15693 Iso. Can you maybe explain to me how i can calibrate the chip for longer range or which calues i can tune to increase the range.

best regards Michael

[Brian TIDAL]

​Hi Mickael,

regarding the polling, I've discussed with hw guys and they confirmed what I was suspecting: in Hibernate/Tag Detector/Sleep states, it is no longer possible to communicate through the SPI as some parts of the device are  no longer powered/clocked. Therefore, it is not possible to poll through SPI for the reply of the Idle command: IRQ_OUT has to be used in that case.  See § 3.1 of the ST25R95 DataSheet "Hibernate, Tag detector and Sleep/Field detector states can only be activated by a command from the external host. As soon as any of these three states are activated, the ST25R95 can no longer communicate with the external host. It can only be woken up." I will manage to improve the documentation to clarify the usage of the Idle command and to explicitly mention that the SPI polling cannot be used.

Regarding the read range, the ISO15693 gives requirement about the minimum operating field (Hmin) and maximum operating field  (Hmax). As far as I know, there is no defined requirement regarding the distance.

The read range depends of many parameters, in particular  the tag antenna and the reader antenna.

For the best reader antenna performances,  see AN5248 ST25R95 transceiver antenna tuning circuit with EMI filter.

It is also possible to tune the Analog Config Register (ARC_B) to adjust the receiver gain. The X-CUBE-NFC3 v2.0.0 uses value 53h for ISO15693 (command Write Register 090468010153) and D3h for ISO14443-A (0904680101D3).  See § 5 .11 of the ST25R95 DataSheet. For ISO14443, the Timer Window parameter is adjusted to 0x58 (command Write Register 09043A005804)

On my X-NUCLEO-NFC03A1 with the X-CUBE-NFC3 v2.0.0 firmware, depending on the tag, I can achieve the following read ranges

• 3.2 cm and up to 5.2 cm for ISO14443  tags
• 4.6 cm and up to 9.2 cm for ISO15693 tags

Rgds

BT

[MUnge]

Hi Brian,

thx for clearifying the problem with the polling.

I am using the built in antenna with the cr95hf plug so i can't really change anything on the circuit.

Regarding the other parameters I used the gain and modulation values that are recommended for the evaluation board. BAsically I am using the exact commands mentioned in D.1.1 in the attached document. Even with changing the gain and modulation I can't seem to read the Tag.

[Brian TIDAL]

​Hi Michael,

I guess this is PLUG-CR95HF-B.

Make sure not to have metallic parts under the board when doing read range test. Can you try with tags having credit card size antenna (for example a ski pass)?

Rgds

BT

[MUnge]

Hi

yes we are using the PLUG-CR95HF-B.

Do you know if that is using the same antenna as the one you are using? Because i basically ran a loop with all the possible combinations for gain, modulation and timerW values and for none i could read the data on the tag that was located 2cm away from the antenna(this was a larger tag than before in the size of a ski pass).

We know soldered another antenna on to the plug an did some minor tests which already gave us better results with more distance. We just soldered it to the free resistor space Rq which is right before the antenna. Can you maybe find out if there is a better place or if that was the right place?

Since we will integrate the chip into our own design, if we can get it to do all the things we need, using the attached antenna of the plug is not really important for us. But to figure out if it does all we want we it would be nice if we could attach another antenna or get it running with the antenna that is already attached.

We will do some more testing with both antennas attached and see if we can get the expected distance for tag reading.

Best Michael

EDIT: So i did the calibration with the new antenna and got a dacref of 48h pluggin that into the idle function i get the same problem as before, where i only get a read for a tag right on top. This leads me to the assumption, that not the antenna is the problem but rather the calibration,which seems to return a dacref value only suited for tag detection really close to the antenna.

[Brian TIDAL · Accepted solution]

Hi Michael,

the antenna on the PLUG-CR95HF-B board has the following characteristics:

• dimension: 43 x 34 mm.
• number of turns: 2

the antenna on the X-NUCLEO-NFC03A1 board has the following characteristics:

• dimension: 47 x 34mm
• number of turns: 4

I will try to grab a PLUG-CR95HF-B and make some read range tests and detection range tests. On your side, can you request your local distributor to send you an X-NUCLEO-NFC03A1 board?

For your own design, ST provides the following application note and calculation tool that should help to improve the performances

• AN5248: ST25R95 transceiver antenna tuning circuit with EMI filter
• STSW-ST25R003: antenna tuning circuit with EMI filter calculation tool

Also, feel free to send to me (in private) your schematics so that I can manage to have them being reviewed by RF experts team.

Note: if you change the antenna on the PLUG-CR95HF-B, the matching circuit will need to be updated.

I would also recommend to base your firmware on top of ST RF Abstraction Layer (RFAL) firmware provided in X-CUBE-NFC3 v2.0.0: this RFAL abstracts the reader being used so that you can easily move to ST25R3911B or ST25R3916 reader in case high performances are needed without having to change your code. The RFAL can be easily tailored to fit your flash/ram constraints.

Regarding the calibration, make sure to calibrate when no tag are in in the operating volume. Make sure to have no metallic parts (cables, ...) under the antenna. With my X-NUCLEO-NFC03A1, in Idle mode, I am able to detect a Type 4A tag at ~3 cm and then able to read it.

Rgds

BT