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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

Jump to solution
13,442 Views
fr5
Contributor IV

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

Labels (1)
0 Kudos
Reply
1 Solution
13,397 Views
jeremygeslin
NXP Employee
NXP Employee

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.

 

 

 

View solution in original post

24 Replies
10,442 Views
fenix358
Contributor I

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

10,674 Views
adnanml
Contributor I

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

0 Kudos
Reply
7,823 Views
embedded123
Contributor I

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

0 Kudos
Reply
13,036 Views
jeremygeslin
NXP Employee
NXP Employee

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.

0 Kudos
Reply
13,031 Views
fr5
Contributor IV

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

0 Kudos
Reply
13,398 Views
jeremygeslin
NXP Employee
NXP Employee

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.

 

 

 

13,014 Views
fr5
Contributor IV

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

13,041 Views
fr5
Contributor IV

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.

0 Kudos
Reply
12,320 Views
steve_delahunty
Contributor II

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

12,314 Views
jeremygeslin
NXP Employee
NXP Employee

Hi,

 

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

 

Regards,

Jeremy.

0 Kudos
Reply
12,290 Views
steve_delahunty
Contributor II

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
12,192 Views
steve_delahunty
Contributor II

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

 

10,837 Views
replicater81
Contributor I

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

Regards,

Vladimir.

10,651 Views
steve_delahunty
Contributor II
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.
10,131 Views
steve_delahunty
Contributor II

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
 
4,150 Views
DoIt
Contributor I

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

0 Kudos
Reply
10,126 Views
replicater81
Contributor I

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.

0 Kudos
Reply
10,123 Views
steve_delahunty
Contributor II
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.
0 Kudos
Reply
10,527 Views
adnanml
Contributor I

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

7,508 Views
andraz_skupek
NXP Employee
NXP Employee

Hi @adnanml ,

Please check this patch.

 

We are planning to fix this in next release.

Best regards

0 Kudos
Reply