Intermittent presence check failures on PN7150

[KnutZaptec]

Hi!

We are integrating the PN7150 with an iMX6ULL, but are having problems with the presence detection for generic MIFARE cards. When holding a card in front of the reader (in poll mode), the NFC stack will repeatedly report that the tag is lost and then found again, at very irregular intervals.

From what I can see, it is caused by a NCI_MSG_CORE_GEN_ERR_STATUS-message being returned from the NFCC during the presence check, but I don't know what causes this "generic error".

For our application, we only need to read the ID of the card, so we have patched out ndef detection & MIFARE commands from nfcDemoApp, as it seemed to cause other problems, and eased debugging.

The only other changes we have made is to disable LPCD, and raising the poll frequency (see the attached diff).

Note that the presence check seems to work fine with ISO15693 cards.

We are using the latest Linux release for the iMX6ULL (kernel 5.4.47, release 2.2.0), and the latest commit from linux_libnfc-nci (2aff644). We have also tested the earliest version possible for libnfc-nci (R2.1), but the problem happens there as well.

I have attached a log of the startup of nfcDemoApp and what happens when holding a card steadily over the reader for a few seconds, then removing it.

I have also attached an oscilloscope picture that shows the field turning off and on intermittently during polling.

Do you know why we are getting very unstable presence detection?

[Brian_Liu_SA]

I also met this problem, after studied, I found the default value in PN7150 is 0x0021 (A0, 0D, 04, 34, 44, 21, 00,). Why the default value is different with libnfc-nxp-pn548.conf file? And what range I could set? If I change the value to 0x0621 (A0, 0D, 04, 34, 44, 21, 06, ) is there any side-effect?

I will appreciate it if someone could answer my questions!

[KnutZaptec]

Can someone from NXP please take a look at this?

[jimmychan]

In case of such instability, it may be due to poor RF performances requiring optimizing RF settings as depicted in https://www.nxp.com/docs/en/application-note/AN11755.pdf.

[KnutZaptec]

I forwarded this to one of our hardware engineers, and he told me that the antenna design & matching shouldn't be an issue.

Both of us think this seems like more of a software issue. Is there something else that can cause this?

Our design detects cards in the range from 0 to 6 cm from the antenna, but no matter how close or far away it is, MIFARE cards always behave erratically.

As I mentioned before, ISO15693 cards work fine, so to me it seems more like there is an issue with the MIFARE presence check?

[jimmychan · Accepted solution]

I got the reply from the expert

======================

Indeed notification CORE_GENERIC_ERROR_NTF(DISC_TRGT_ACT_FAILED) "600701A1" interrupts the presence check procedure. This notification indicates errors while re-activating the MIFARE card. This is usually observed when noise is catch on RF. To limit this, RX sensitivity must be adapted to the customer integration (provided values refering to PN7150 demokit integration). https://www.nxp.com/docs/en/application-note/AN11755.pdf chapter 5.5 describes how to tune the RF settings. Basically customer must look to CLIF_ANA_RX_REG for transition RF_CLIF_CFG_BR_106_I_RXA_P. Inside provided libnfc-nxp-pn548.conf file (NXP_RF_CONF_BLK_1) value is set to 0x0022 (A0, 0D, 04, 34, 44, 22, 00,), I would suggest customer to check tuning this value to limit the appearance of the CORE_GENERIC_ERROR_NTF notification. Else, it may be possible to ignore this notification in the libnfc-nci code to prevent interrupting the presence check procedure.

By the way, I saw customer modified libnfc-nxp-pn547.conf file to disable LPCD mode. While using PN7150, libnfc-nxp-pn548.conf file must be considered, libnfc-nxp-pn547.conf file being related to PN7120.

================

[Hedashen]

Hi! How to ignore this notification？Just ignoring this notification in uppper layer can't prevent interrupting the presence check procedure.

[KnutZaptec]

This is perfect!

I quickly tried to modify the parameter suggested by the expert, and it seems like it was indeed the source of our issues! I will get our hardware engineer to do a proper tuning of the value going forward.

Thanks a lot for the detailed reply, it helped us a lot!