ST25R: Unable to communicate via NFC-V

[stepanoplustil]

Hello,

I'm running a demo from STSW-ST25R-LIB which uses NFC-V. The Inventory poll returns RFAL_ERR_FRAMING as the SOF does not match. Also I have to push the tag really close to get this behaviour. The tag (M24LR64) should be fine as I can communicate with it via ST25 Android app.

I assume that my HW and rfal_platform.h is set right as NFC-A tag is found successfuly after enabling it via RFAL_FEATURE_NFCA.

HW I'm using is EFM32 development board with click shield and NFC 5 Click module by Mikroe.

 

I have following questions:

Is it possible that the board layout is problematic for NFC-V, but NFC-A is fine?

Is it possible that the chip itself could be faulty and behave like this?

I found macro RFAL_USE_COHE. Could this help? I have not found any information about this.

Is there anything else that could cause this problem?

 

Thank you very much for help or suggestions!

[Ulysses HERNIOSUS]

Hi,

I assume you are using the ST25R3916 (X-NUCLEO-NFC06A1)?

I could imagine that in your case the strong coupling may amplify some noise (from card/power supply) to be recognized as additional modulation from the card. At the beginning of a message the gain is typically at highest and AGC may not be fast enough filtering out noise in the beginning. 

I expect RFAL_USE_COHE to not having an effect as I expect default analog config not being used. And even if you move to coherent you may actually worsen the situation. 

I would do the following:

1. Look at the actual error in VICCDecode: Is it already failing at SOF, with which data byte?
2. Enable IQ demodulator which should give more noise resistance. This could also be activated for other protocols
3. Increase the gain reduction, play with values to find a good compromise

The necessary changes are detailed here:

diff --git a/source/rfal_iso15693_2.c b/source/rfal_iso15693_2.c
index cf9f5e07..10fd9061 100644
--- a/source/rfal_iso15693_2.c
+++ b/source/rfal_iso15693_2.c
@@ -297,7 +297,7 @@ ReturnCode rfalIso15693VICCDecode(const uint8_t *inBuf,
 *outBufPos = 0;

 /* first check for valid SOF. Since it starts with 3 unmodulated pulses it is 0x17. */
- if ((inBuf[0] & 0x1fU) != 0x17U)
+ if ((inBuf[0] & 0x1fU) != 0x17U) // what is received here?
 {
 ISO_15693_DEBUG("0x%x\n", iso15693PhyBitBuffer[0]);
 return RFAL_ERR_FRAMING;
diff --git a/Projects/STM32L476RG-Nucleo/Applications/X-NUCLEO-NFC06A1/ndef_rw/Src/analogConfigTbl_NFC06A1.c b/Projects/STM32L476RG-Nucleo/Applications/X-NUCLEO-NFC06A1/ndef_rw/Src/analogConfigTbl_NFC06A1.c
index bccb9657..9354cf31 100755
--- a/Projects/STM32L476RG-Nucleo/Applications/X-NUCLEO-NFC06A1/ndef_rw/Src/analogConfigTbl_NFC06A1.c
+++ b/Projects/STM32L476RG-Nucleo/Applications/X-NUCLEO-NFC06A1/ndef_rw/Src/analogConfigTbl_NFC06A1.c
@@ -437,13 +437,13 @@ const uint8_t rfalAnalogConfigCustomSettings[] = {

 /* Mode Name: POLL_V_COMMON_RX, Mode ID: 0x1002 */
 MODE_ENTRY_7_REG(0x1002,
 0x000a,0x04,0x00, /* Receiver Operation Selection (dis_corr) : Correlation operation ; Use Correlator Receiver */
 0x000b,0xff,0x13, /* User Defined */
- 0x000c,0xff,0x2d, /* User Defined */
+ 0x000c,0xff,0xed, /* switch to IQ demodulator - potentially better noise resistance */
 0x000d,0xff,0x00, /* User Defined */
- 0x000e,0xff,0x00, /* User Defined */
+ 0x000e,0xff,0x22, /* Increase gain reduction a bit, can also play with higher values */
 0x004c,0xff,0x13, /* User Defined */
 0x004d,0xff,0x01 /* User Defined */
 ),

 /* Mode Name: POLL_AP2P_COMMON_RX, Mode ID: 0x0802 */

Line numbers may not apply 1:1 for your code but the locations should be easily identifiable.

BR, Ulysses

 

[stepanoplustil]

Hi,

thank you for quick reply and your suggestions.

I'm not sure, if you understood correctly. The suggestions you gave me solves, I guess, over-gained demodulator. In fact, the reader can't read anything when using NFC-V and only after I put the tag really close, the framing error pops. I think my interpretation was a bit misleading, sorry for that.

 

However, I tried your suggestions, including the coherent receiver and here's what I found:

• Failed SOF byte

I tried it with different gain reduction values 0x00, 0x22, 0x66 and 0xAA, all with AM/PM and I/Q demodulator, each case 20 results. 5 most common values were:

• 0x11 → 47 occurrences
• 0x04 → 33 occurrences
• 0x21 → 18 occurrences
• 0x91 → 10 occurrences
• 0x51 → 10 occurrences

Increasing gain reduction resulted in more different values. With I/Q demodulator turned on there were actually some cases when the SOF was alright but failing afterwards and even few where UID was read successfuly.

• Coherent receiver mode

Although you said this would worsen the situation, I tried this mode. In this mode, I was able to successfuly receive the UID every time (with I/Q demodulator and 0x00 gain reduction value). 

However, I still have to put the tag right to the antenna to get the UID. Is there any way to longer the range when the gain is already to full?

 

Thank you very much

Stepan

 

[Ulysses HERNIOSUS]

Hi,

yes I was initially under the impression that NFC-V would be working in farther distances and fail in close proximity. What is the range you are achieving with NFC-A tags? Which tags with which antenna sizes?

I think you will need to look into signals on RFI and the RF field with a scope to see Reader modulation and subsequently also the tag response. Maybe also look in parallel on the power supply of the RF driver.

Also smith charts of your antenna system might give some insights if available.

This ticket how-to-use-st25r3911b-for-long-reading-distance-40cm explains some debugging techniques. 

BR, Ulysses