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 · Accepted solution]

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