PN7160 SPI EVK (OM27160B1EVK) on Raspberry Pi4 : no NFC tag detected

[fr5]

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

[fenix358]

Hi, @steve_delahunty. Could you please share the solution? We also have the same problem(

[adnanml]

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

[embedded123]

I am facing this issue as well, did you ever find a solution?

[jeremygeslin]

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.

[fr5]

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

[jeremygeslin · Accepted 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.

[fr5]

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

[fr5]

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.

[steve_delahunty]

I'm running into the same issue. Was a solution ever found?

[jeremygeslin]

Hi,

Fix was delivered in latest libnfc-nci PN7160 drop https://github.com/NXPNFCLinux/linux_libnfc-nci/commit/ee8ad71123b07b5a33012df0c614ab3e9278c080.

Regards,

Jeremy.

[steve_delahunty]

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):

    if (index != std::string::npos)

to

    if (index != std::string::npos && index != -1)

Anway, I'm getting the same thing as before. That is, the discovery seems to be started by this command: 21031309000101010201030180018101060174017001

But I get back this: 41030105

From a previous post, this indicates a syntax error? Here's a GDB backtrace. It's still stuck waiting for an event. Perhaps this is due to the initial syntax error?

#0 futex_wait_cancelable (private=0, expected=0, futex_word=0xfffff7fccbd0 <sNfaEnableDisablePollingEvent+40>)
at ../sysdeps/nptl/futex-internal.h:183
#1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0xfffff7fccbd8 <sNfaEnableDisablePollingEvent+48>,
cond=0xfffff7fccba8 <sNfaEnableDisablePollingEvent>) at pthread_cond_wait.c:508
#2 __pthread_cond_wait (cond=0xfffff7fccba8 <sNfaEnableDisablePollingEvent>,
mutex=0xfffff7fccbd8 <sNfaEnableDisablePollingEvent+48>) at pthread_cond_wait.c:638
#3 0x0000fffff7c3b7e4 in CondVar::wait (this=0xfffff7fccba8 <sNfaEnableDisablePollingEvent>, mutex=...)
at src/nxp_nci_hal_nfc/nci/jni/CondVar.cpp:79
#4 0x0000fffff7c46784 in SyncEvent::wait (this=0xfffff7fccba8 <sNfaEnableDisablePollingEvent>)
at src/nxp_nci_hal_nfc/nci/jni/SyncEvent.h:57
#5 0x0000fffff7c84f44 in startRfDiscovery (isStart=1 '\001') at src/nxp_nci_hal_nfc/nci/jni/NativeNfcManager.cpp:2461
#6 0x0000fffff7c8383c in nfcManager_enableDiscovery (technologies_mask=-1, enable_lptd=1 '\001', reader_mode=0 '\000',
enable_host_routing=0, enable_p2p=1 '\001', restart=0 '\000') at src/nxp_nci_hal_nfc/nci/jni/NativeNfcManager.cpp:1583
#7 0x0000fffff7c70488 in doEnableDiscovery (technologies_mask=-1, reader_only_mode=0, enable_host_routing=0, restart=0)
at src/service/linux_nfc_api.cpp:209
#8 0x0000aaaaaaaad028 in InitMode (tag=1, p2p=1, hce=0) at demoapp/main.c:638
#9 0x0000aaaaaaaafbe0 in cmd_poll (arg_len=0, arg=0xfffffffffbc8) at demoapp/main.c:1882
#10 0x0000aaaaaaab0434 in main (argc=2, argv=0xfffffffffbb8) at demoapp/main.c:2145

[steve_delahunty]

SOLVED! There was a bug in the codebase. I'll try to post a patch when I have a moment..

[replicater81]

Hi Steve,
After discovery start, I also get a return of 41030105. Do you have a solution to this problem?

Regards,
Vladimir.

[steve_delahunty]

Hi. Yes, I found the solution. I'll download the latest and diff it against mine to create a patch for you. Give me some time though.

[steve_delahunty]

Here's the solution: The problem is in this file:

  src/nxp_nci_hal_libnfc-nci/utils/config.cc

Go to the bottom of this file. There's a function called GetNumValue. Check out the "switch" statement at the bottom of this function. There is no case for "int". I added one:

case sizeof(unsigned int):
        *(static_cast<unsigned int*>(pValue)) = (unsigned int)v;
        break;

I believe this affects platforms based on aarch64

[DoIt]

How to fix the problem in 32bit system? tks.

[replicater81]

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.

[steve_delahunty]

You are welcome. Glad I could help. I spent a lot of time too. Hopefully, NXP picks this up and the next release will work on the aarch64. Take care.

[adnanml]

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

[andraz_skupek]

Hi @adnanml ,

Please check this patch.

We are planning to fix this in next release.

Best regards