Hi,
I followed instructions provided in these documents :
https://www.nxp.com/docs/en/application-note/AN12991.pdf
https://www.nxp.com/docs/en/application-note/AN13287.pdf
https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/Easy-set-up-of-NFC-on-Raspberry-Pi/ta-p/1099... by @jeremygeslin
I have tested with nfcDemoApp on two different configurations.
On first configuration I used a Raspberry yocto image with https://github.com/NXPNFCLinux/meta-nxp-nfc/blob/master/recipes-nfc/nxp_nfc/nxp-nfc_git.bb recipe, with SRC_URI overrided to git://github.com/NXPNFCLinux/linux_libnfc-nci.git;branch=NCI2.0_PN7160 and SRCREV to "6bf9f42b94e267f6384043009bda84c11e7ebbaa".
On second configuration I used directly Raspberry debian distribution (debian version 11.2) on which I installed linux_libnfc-nci library got from git clone https://github.com/NXPNFCLinux/linux_libnfc-nci.git -b NCI2.0_PN7160
In both cases I am not able to detect a NFC tag (I attach the corresponding log files).
Can anyone help on this please ?
Regards,
Fabien
Solved! Go to Solution.
Hi Fabien,
From your logs, I can observe the discovery loop is started with the following NCI command:
21031309000101010201030180018101060174017701
This RF_DISCOVER_CMD is rejected by PN7160 with SYNTAX_ERROR:
41030105
FYI, the command detail is:
[NCI][COMMAND][21 03 13 09 00 01 01 01 02 01 03 01 80 01 81 01 06 01 74 01 77 01]
RF_DISCOVER_CMD
* Number of Configurations = 9 [0x09]
--> Configuration N° 1
- RF Technology and Mode = {Std} NFC_A_PASSIVE_POLL_MODE [0x00]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 2
- RF Technology and Mode = {Std} NFC_B_PASSIVE_POLL_MODE [0x01]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 3
- RF Technology and Mode = {Std} NFC_F_PASSIVE_POLL_MODE [0x02]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 4
- RF Technology and Mode = {Std} NFC_A_ACTIVE_POLL_MODE (RFU) [0x03]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 5
- RF Technology and Mode = {Std} NFC_A_PASSIVE_LISTEN_MODE [0x80]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 6
- RF Technology and Mode = {Std} NFC_B_PASSIVE_LISTEN_MODE [0x81]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 7
- RF Technology and Mode = {Std} NFC_15693_PASSIVE_POLL_MODE (RFU) [0x06]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 8
- RF Technology and Mode = Reserved for Proprietary Technologies in Poll Mode [0x74]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 9
- RF Technology and Mode = Reserved for Proprietary Technologies in Poll Mode [0x77]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
The "RF Technology and Mode" value 0x77 relates to KOVIO, as defined for PN7150, while it should be 0x70 for PN7160. We are currently analyzing why the proper value is not internally used by the libnfc-nci, but nevertheless disabling KOVIO from POLLING_TECH_MASK should remove the related configuration in the RF_DISCOVER_CMD.
Thus can you please verify the configuration files located under /usr/local/etc/, since those are the one dynamically loaded during libnfc-nci initialization (there are copied there during "make install" operation).
Regards,
Jeremy.
Hi, @steve_delahunty. Could you please share the solution? We also have the same problem(
Hello!
Very interesting all the comments here.
I also have PN7160 with RPi4 version B (64 bit). I have downloaded and build the linux_nfclib (git clone https://github.com/NXPNFCLinux/linux_libnfc-nci.git -b NCI2.0_PN7160) and run the commands as mentioned in PN7160 evaluation kit quick start guide (nxp.com)
make
sudo make install
export LD_LIBRARY_PATH=/usr/local/lib
However, after running nfcDemoApp poll (or any other command) I get an error. The program throws an exception and exits, and I'm not able to find where the problem is happening and fix it. Have anyone of you experienced a similar error?
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr: _pos (which is 4292967296) > this->size() (which is 2)
Aborted
Thank you in advance!
Adnan
I am facing this issue as well, did you ever find a solution?
Hi,
The issue looks to be related to KOVIO reader mode. It seems you updated the configuration file libnfc-nci.conf to set POLLING_TECH_MASK to 0xEF (while by default it is 0xCF).
As a temporary workaround I would suggest to disable KOVIO support (keeping 0xCF setting of POLLING_TECH_MASK).
Regards,
Jeremy.
Hi Jeremy,
Thank you for your answer.
I have checked POLLING_TECH_MASK value, it is still set to 0xCF default value, so NFA_TECHNOLOGY_MASK_KOVIO should be disabled. What made you think to a problem related to KOVIO reader mode ?
I attach currently used configuration files, may be there is another setting that could be incorrect ?
Regards,
Fabien
Hi Fabien,
From your logs, I can observe the discovery loop is started with the following NCI command:
21031309000101010201030180018101060174017701
This RF_DISCOVER_CMD is rejected by PN7160 with SYNTAX_ERROR:
41030105
FYI, the command detail is:
[NCI][COMMAND][21 03 13 09 00 01 01 01 02 01 03 01 80 01 81 01 06 01 74 01 77 01]
RF_DISCOVER_CMD
* Number of Configurations = 9 [0x09]
--> Configuration N° 1
- RF Technology and Mode = {Std} NFC_A_PASSIVE_POLL_MODE [0x00]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 2
- RF Technology and Mode = {Std} NFC_B_PASSIVE_POLL_MODE [0x01]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 3
- RF Technology and Mode = {Std} NFC_F_PASSIVE_POLL_MODE [0x02]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 4
- RF Technology and Mode = {Std} NFC_A_ACTIVE_POLL_MODE (RFU) [0x03]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 5
- RF Technology and Mode = {Std} NFC_A_PASSIVE_LISTEN_MODE [0x80]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 6
- RF Technology and Mode = {Std} NFC_B_PASSIVE_LISTEN_MODE [0x81]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 7
- RF Technology and Mode = {Std} NFC_15693_PASSIVE_POLL_MODE (RFU) [0x06]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 8
- RF Technology and Mode = Reserved for Proprietary Technologies in Poll Mode [0x74]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
--> Configuration N° 9
- RF Technology and Mode = Reserved for Proprietary Technologies in Poll Mode [0x77]
- Discovery Frequency = RF Technology and Mode will be executed in every discovery period [0x01]
The "RF Technology and Mode" value 0x77 relates to KOVIO, as defined for PN7150, while it should be 0x70 for PN7160. We are currently analyzing why the proper value is not internally used by the libnfc-nci, but nevertheless disabling KOVIO from POLLING_TECH_MASK should remove the related configuration in the RF_DISCOVER_CMD.
Thus can you please verify the configuration files located under /usr/local/etc/, since those are the one dynamically loaded during libnfc-nci initialization (there are copied there during "make install" operation).
Regards,
Jeremy.
Jeremy,
Thank you for this additional explanation.
It appears that for some reason values set in libnfc-nci.conf are not taken into account by the library.
Even if I did not modify default POLLING_TECH_MASK=0xCF in libnfc-nci.conf, it can be seen in log file that value is not correct :
2018:03:09-15:05:04.517 nfcManager_doInitialize: tag polling tech mask=0xFF
As a workaround, I modified DEFAULT_TECH_MASK value in nxp_nci_hal_nfc/nci/jni/NativeNfcManager.cpp, removing NFA_TECHNOLOGY_MASK_B_PRIME and NFA_TECHNOLOGY_MASK_KOVIO
Now, NFC Sample Card is correctly detected !
Thank you very much for your answers that quickly showed the right direction to follow.
Regards,
Fabien
I add more information about the problem.
nfcDemoApp application seems to be blocked in InitMode function, then in doEnableDiscovery.
In NativeNfcManager.cpp it seems to correspond to startRfDiscovery(true) call, then waiting for this event which does not occur :
sNfaEnableDisablePollingEvent.wait(); // wait for NFA_RF_DISCOVERY_xxxx_EVT
I attach another log file : same situation as before, with additional "nfc" traces enabled.
I'm running into the same issue. Was a solution ever found?
Hi,
Fix was delivered in latest libnfc-nci PN7160 drop https://github.com/NXPNFCLinux/linux_libnfc-nci/commit/ee8ad71123b07b5a33012df0c614ab3e9278c080.
Regards,
Jeremy.
Thanks for the update. I downloaded the latest code and built it. It was throwing an error in android/utility/base/strings.cpp when trying to parse this:
NFA_PROPRIETARY_CFG={05:FF:FF:06:81:80:70:FF:FF}
It seems the code walked off the end which caused the exception. I fixed it by changing this line (line 28):
SOLVED! There was a bug in the codebase. I'll try to post a patch when I have a moment..
Hi Steve,
After discovery start, I also get a return of 41030105. Do you have a solution to this problem?
Regards,
Vladimir.
Here's the solution: The problem is in this file:
How to fix the problem in 32bit system? tks.
Hi, Steve,
I checked this fix - everything works! I spent a lot of time to find the cause of the error, but could not. Thanks for the help!
Regards,
Vladimir.
Hello @steve_delahunty !
I have also run into the same problem. Would appreciate very much if you can indicate us the changes, or post the git diff here so we can fix the issue.
Best regards,
Adnan