ST25R95/CR95HF wake up from tag detector without tags

[Stellar]

Hi,

I'm using an X-NUCLEO-NFC03A1 board with an nRF52840DK. I'm running my own driver on Zephyr and I'm able to read tags by polling. I plan to set the chip in the tag detector WFE so that once a tag is detected, it can wake up the host to handle the tag.

The problem is it always returns immediately after I send the Idle command even if there are no tags.

Here's the command to put in the WFE tag detector state:

{IDLE_CMD, 0x0e, 0x02, 0x21, 0x00, 0x38, 0x01, 0x18, 0x00, 0x20, 0x60, 0x60, 0x64, 0x74, 0x3f, 0x08},

The response is {0x0, 0x1, 0x2} which means tag detected.

 

I know the tag calibration procedure is needed, but my calibration command got no response, the IRQ_OUT interrupt was never generated.

Here's the command for tag calibration:

{IDLE_CMD,  0x0e,  0x03, 0xa1, 0x00, 0xf8, 0x01, 0x18, 0x00, 0x20, 0x60, 0x60, 0x00, 0x00, 0x3f, 0x01}.

 

So I decided to go through all the DacData from (0x04, 0x14) to (0xe4, 0xf4) in the command of entering WFE tag detector, no tags tap on the antenna, but they all responded with {0x0, 0x1, 0x2}.

 

I also noticed this post: https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/problem-with-nfc-st25r95-tag-detection/td-p/596946,  I use an official X-NUCLEO-NFC03A1, may not be the matching circuit/antenna problem, right?

 

Could you give me some advice？

Regards.

[Brian TIDAL]

Hi,

regarding the Idle command being used in your application, I would recommend to set <WU Source> to 0x0A to keep the possibility to exit the WFE mode thanks to an IRQ_IN pulse. As the timeout is not used, the <MaxSleep> parameter is not used and can be kept to 0x00. In the RFAL implementation of the Idle command, the following values are used: 

static uint8_t Idle[] = {ST25R95_COMMAND_IDLE, 0x0E, 0x0A, 0x21, 0x00, 0x38, 0x01, 0x18, 0x00, 0x20, 0x60, 0x60, 0x74, 0x84, 0x3F, 0x00};

The <DacDataL> and <DacDataH> values (0x74 and 0x84) in this command are the usual ones for an X-NUCLEO-NFC03A1. Anyway the RFAL includes the DAC calibration feature and those values are updated after the DAC calibration procedure. The calibration procedure has to be performed in free air (make sure that the antenna of the X-NUCLEO-NFC03A1 board is not close to some shielding or some metallic parts in your application). Also make sure to rely on IRQ_OUT rather that the SPI polling mechanism (see ST25R95 datasheet §5.9).

An implementation in C language of the calibration procedure can be found into the X-CUBE-NFC3 package (see st25r95CalibrateTagDetector function). It follows the AN3433 application note. The following calibrate command is being used:

static uint8_t Calibrate[] = {ST25R95_COMMAND_IDLE, 0x0E, 0x03, 0xA1, 0x00, 0xB8, 0x01, 0x18, 0x00, 0x00, 0x60, 0x60, 0x00, 0x00, 0x3F, 0x01};

The <DacDataH> is modified to use the various steps during the dichotomy.

The calibration procedure first checks that the Idle command returns tag detect when using the minimum DAC value and returns timeout using the maximum DAC value. Here are the various calibration steps:

MOSI : MISO, MOSI : MISO, etc.
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,0 : 6,3F : 6,1 : 6
2 : C,0 : 0,0 : 1,0 : 2 // Check that tag detect is received when using DacDataH=0x00
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,FC : 6,3F : 6,1 : 6
2 : E,0 : 0,0 : 1,0 : 1 // Check that timeout is received when using DacDataH=0xFC
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,7C : 6,3F : 6,1 : 6
2 : C,0 : 0,0 : 1,0 : 2 // Dichotomy starts with DacDataH=0x7C, Tag Detect received ==> use DacValueH=0xBC in next step
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,BC : 6,3F : 6,1 : 6
2 : E,0 : 0,0 : 1,0 : 1 // Timeout received ==> use DacValueH=0x9C in next step
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,9C : 6,3F : 6,1 : 6
2 : E,0 : 0,0 : 1,0 : 1 // Timeout received ==> use DacValueH=0x8C in next step
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,8C : 6,3F : 6,1 : 6
2 : E,0 : 0,0 : 1,0 : 1 // Timeout received ==> use DacValueH=0x84 in next step
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,84 : 6,3F : 6,1 : 6
2 : E,0 : 0,0 : 1,0 : 1 // Timeout received ==> use DacValueH=0x80 in next step
0 : 6,7 : 6,E : 6,3 : 6,A1 : 6,0 : 6,B8 : 6,1 : 6,18 : 6,0 : 6,0 : 6,60 : 6,60 : 6,0 : 6,80 : 6,3F : 6,1 : 6
2 : C,0 : 0,0 : 1,0 : 1 // Last step. Timeout received ==> use 0x7C for the DacDataRef, 0x74 for DacValueL and 0x84 for DacValueH

Rgds

BT

[Stellar]

 

Hi, Brain,

Thank you for your quick answer.

I set  <WU Source> to 0x02 just because I want to make sure it's not waking up by IRQ_IN. I also try 0x0A to get the same results.

Yes, I have seen the st25r95CalibrateTagDetector in RFAL. I ported it to run on Zephyr OS,  the IRQ_OUT interrupt was not raised after I sent the calibrate command with DACDATA_H=0x0, can you help to check the code? 

 

*** Booting Zephyr OS build v3.3.99-ncs1 ***
NFC tag reader sample

I: Execute CMD: CMD_CALI_TAG_DETECT
03 a1 00 b8 01 18 00 20 60 60 00 00 3f 01
E: Response IRQ not ready in time 500 ms
E: CMD_CALI_TAG_DETECT for minimum failed, err = -5

 

By the way, is there any other configuration for the chip before Calibration? I call the calibrate function just after the power sequence and check the chip ID.

 

[Brian TIDAL]

Hi,

 

I had a look on the st25r95_cal.c and haven't seen issues.

Can you connect a logic analyzer on SPI (CLK/MISO/MOSI/CS) + IRQ_IN + IRQ_OUT and send me the trace from power on up to the calibrate commands (i.e. including the startup sequence)?

Can you try on another X-NUCLEO-NFC03A1 board?

How is connected the X-NUCLEO-NFC03A1 board to the nRF52840DK: wire jumper or interposer board? make sure to have the 3V3 supply on CN6.2 and CN6.4 with 2 different wires/pins. Same for CN6.6 and CN6.7 (GND) to be connected on 2 different GND pins.

Rgds

BT  

[Stellar]

Hi,

Attached is the capture with a Saleae logic analyzer.

Yes, I've tried others X-NUCLEO-NFC03A1 and they also have the issues.

The nRF52840DK is compatible with the Arduino Uno Rev. 3 standard so they are wired with the connector. 

The 3V3 supply on CN6.2 and CN6.4 are different pins, as well as GND. But they are connected on the nRF52840 respectively.

 

 

[Brian TIDAL]

Hi

The normal behavior is the following:

When entering in WFE mode for a given calibration step, [<Maxsleep> + 1] bursts of <SwingsCnt> pulses at 13.56MHz are transmitted every tINACTIVE milliseconds.  tINACTIVE is  (<WUPeriod> + 2) x tREF with tREF=8ms and therefore tINACTIVE is 16ms (this is actually closer to 17ms due to some processing after each burst). So, with <Maxsleep>=1 and <SwingsCnt>=63, there are 2 bursts of 63 RF pulses transmitted every 17ms and then a response is returned.

The burst can be observed on a scope (just connect the gnd of the probe to the tip of the probe and put the probe in the field and you should be able to capture the field):

The full sequence for 1 step of calibration is:

The red signal is the SPI CS. The first low red pulse on the SPI CS is the Idle command transmission, then 17ms later the first burst is sent in blue, then 17ms later the second burst is sent in blue and the second low red pulse on the SPI CS corresponds to the response to the Idle command. So a response arrives ~34ms after the Idle command.

I suspect that the transmission of the first burst causes a voltage drop that resets the ST25R95 chip. Can you try to probe the field and check whether you see part of the burst 17ms after the Idle SPI CS pulse? See also the table 47 of the datasheet for the 100mA  peak current during burst detection. Can you try to supply the 3V3 of the ST25R95 from an external lab supply (just bend the CN6.2 and CN6.4 pins)?

Rgds

BT

 

P.-S. the antenna of the X-NUCLEO-NFC03A1 board seems quite close to the MCU PCB. This will therefore cause issue during tag detection. I would suggest, for test purposes, to use some wires between the MCU board and the  CN5/CN6/CN8/CN9 connectors of the X-NUCLEO-NFC03A1 to make sure the antenna is in open field.

[Stellar]

Hi,

I am using wires to connect the MCU board and X-NUCLEO-NFC03A1 now.

Seem that the interval of the 2 bursts is more than 200ms in my tests. I forgot to trace SPI CS, will confirm it later.

 

 

[Brian TIDAL]

Hi,

I've seen that the <WUperiod> parameter inside the tag calibration command is 0x20 instead of 0x00:

It should be 0x00:

Can you change the <WUperiod> to 0x00 and check again?

Rgds

BT

[Stellar]

Thank you, Brian.

Setting <WUperiod> to 0x00 solves the problem. If the boards are connected with wires, the DAC pairs by calibration are (0x68 and 0x78) and if they are connected with the interposer it is (0x48 and 0x58).

Getting in the tag detector state and waking up also works properly. And one more question:

Do we need the calibration at each start-up, or do we just save the calibration value to the NVM and load them at the next power-on?

[Brian TIDAL]

Hi,

well done. Good to see that this issue is now fixed. Would you please click on "Accept as solution" in my previous answer?

Regarding the calibration, several strategies can be used:

1. calibration done once during product development and same calibration value stored for all products
2. calibration done in factory during manufacturing and stored in NVM
3. calibration done after each power on
4. calibration done just before entering tag detection phase

Each strategy has pros and cons:

1. simple but does take into account part to part variation
2. increase manufacturing time, does not take into account the local environment where the product will be installed 
3. increase the boot time
4. increase the duration before entering the tag detection phase

I would use a mix of iii. and iv.:

• calibration done after each power on
• recalibration in case of several exits from WFE without successful answer to polling i.e. the device exits from WFE with response=wake-up by tag detect but there is no reply to the polling, if this happens several successive times (e.g. 5), it can be assumed that a recalibration is needed.

Rgds

BT

[Brian TIDAL]

Hi,

when using a mix of iii. and iv., if the user places a tag in the operating volume during calibration or recalibration, the calibration value will be deviated (e.g. let's say the DacL and DacH will be 0x48 and 0x58 instead of 0x68 and 0x78). When removing the tag, there will be 'false' TagDetect events and no responses from the tag when polling. A recalibration should then be triggered. 

The timeout wake-up source can also be enabled in the Idle command (let say ~5s or ~10s). This will cause periodic wake up where the application can poll for tag. This avoids being stuck e.g. in case a user has placed a tag in the operating volume during calibration and has kept it in the operating volume. The timeout value depends on the application and on the power saving needs for your application

Rgds

BT

 

[Stellar]

Got it. By the way, does the ST25R95 sense a tag removal and notify with an IRQ_OUT pulse? I would like to set the chip in tag detection at first,  once a tag approaches I will read the tag, and then set it in tag detection again if the tag is removed.

I have seen this and I think the AN3433 does not help with it: https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/cr95hf-tag-removal-detection/td-p/427257.

Regards

[Brian TIDAL]

Hi,

I've never seen the Idle command being used for tag removal detection. 

Which tag technology (ISO14443A or B, Felica(TM), ISO15693) do you plan to use in your application?

In our demos, we use the following tag removal detection methods:

• method#1: the field is kept ON after the application has completed its stuff and periodic check presence are sent to the tag, e.g. for ISO15693 /NFCV tags, rfalNfcvPollerInventory with the UID of the tag is sent every e.g. 130ms until an error is detected. Once the tag is considered as removed (no response), the application can enter the WFE tagDetect mode. See ndef_demo.c in the X-CUBE-NFC3 package for example of tag removal detection using the RFAL.
• method #2: the field is switch off after the application has completed its stuff. Periodically e.g. every 130ms, the field is switch on, and the reader polls using only the tag technology to try to see whether the same tag is still present. Once the same tag is not seen in the operating volume, the application can enter in the tagDetect WFE mode. This method has a drawback when a tag uses random UID (the UID changes after a field off).

Rgds

BT

 

[Stellar]

Hi, 

We use ISO14443A  tag Type 2.

BTW,  I checked both the st25r95 and cr95hf data sheets, the st25r95 shows a Filed detector mode in Table 3 while cr95hf doesn't.  My X-NUCLEO-NFC03A1 has a cr95hf on it, does it mean the field detector WFE is not supported? 

What's the complete idle command to enter Field detector WFE  for st25r95?

[Brian TIDAL]

Hi,

Basically, since the CR95HF has joined the ST25R family, ST25R95 is the part numbering for this device (actually ST25R95-VMD5T is the full part number). The marking on the IC is still CR95HF. As ST25R95 is recommended for new designs, CR95HF documentation is kept only for legacy purpose. Hence, I would recommend to use ST25R95 datasheet rather than CR95HF datasheet as ST25R95 datasheet is up to date (some typos have been fixed and some extra information has been provided).

The field detector WFE is designed for the Card Emulation mode (i.e. when the device emulates a tag). Example of Idle command for this mode: 0x07 0E 04 01 42 38 00 18 00 00 60 00 00 00 00 00. Can you share more information about your use case for this feature?

Rgds

BT

[Stellar]

Hi,

The command works! We don't need the Card Emulation, we just use it to wake up the host MCU from deep sleep mode.

Thanks. 

[Brian TIDAL]

Hi,

Well done!

If your initial issue is now solved, would you please click on Accept as Solution on the relevant post? For any new question, I would recommend to create a new thread rather than posting new questions in this current thread.

Thanks

Rgds

BT