PN7150 library (SW4325) has a problem in nfctask.c

[gerrikoio]

I've been working through the PN7150 code library, which is available in the SW4325 zip file as per Application Note AN11990.

I found I was having some intermittent problems when testing card Read mode, in particular with MIFARE classic cards.

I discovered the problem resides in nfctask.c in function "void task_nfc_reader(NxpNci_RfIntf_t RfIntf)".

Here, I discovered that after the message "CARD REMOVED\r\n" there are two further functions calls but there is no error checking associated with these calls and so if and when there is an error, I found that my PN7150 halts and then requires a hard reboot. Not ideal!

I found that with the MIFARE classic card it is sometimes returning a NXPNCI_ERROR instead of a NXPNCI_SUCCESS.

I found that if I change this function and repeat the call if a NXPNCI_ERROR is returned it appears to fix the problem. As in:

if (NxpNci_StartDiscovery(DiscoveryTechnologies,sizeof(DiscoveryTechnologies))) {
 // try again - note I inserted a short Sleep/delay call here 
 // just to be sure but probably its not required
 if (NxpNci_StartDiscovery(DiscoveryTechnologies,sizeof(DiscoveryTechnologies))) 
 printf("Discovery Start Error\r\n");
}

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Thus, ideally, the function task_nfc_reader should also be amended to also return NXPNCI_SUCCESS or NXPNCI_ERROR

[TonwsLee]

Sorry to bother, I recently had a similar problem, the difference is that I found that PN7150 stopped running even after repeating the NxpNci_StartDiscovery function many times, but this only happens when I plug the card with a faster speed, I can't find the reason

[Sabina_Bruce]

Hi Colin,

In order for me to better assist you I am going to need more information. As it stands I have tried to replicate the error you are describing but I have not had any luck.

So could you please provide the name of the microcontroller you are using and the library version that you have for these examples.

Also can you explain the command sequence or the context in which this behavior occurs. In other words, how or what is done that cause an NXPNCI_ERROR in the functions following the "Card Removed "message.

Let me know as soon as you can.

Thank you,

Sabina

[gerrikoio]

Thanks for the reply.

As I noted, I extracted the library from the link provided in Application Note AN11990. I carried out an extensive online search on NXP.com and community.nxp.com and could not find any other versions of this library.

I ported this library across to a FRDM-KW41Z board using the "bare metal" option and it never creates an error.

However, I did notice that there is a short delay after the "CARD REMOVED" message when using MIFARE CLASSIC cards which is not present with any other option.

I also ported this library across to a Cypress Semiconductor PSoC 6 BLE Pioneer kit. As you may know, this is a dual core ARM Cortex M0+ and M4 board. I had the firmware flashed to the M4 core. This also operated in "bare metal" mode. The only difference between this and the FRDM-KW41Z option is the TML.c file and pinout/board reference. The I2C functions are remarkably similar.

The code works in all modes (RW, P2P, CARDEMU) but I noticed that every now and then it would lock up and I had to manually reset. After extensive testing, I discovered that the problem only occurred with MIFARE CLASSIC cards and that it happened after the "CARD REMOVED" message, and that it was linked to the "NxpNci_StartDiscovery" function which would return a NXPNCI_ERROR instead of a NXPNCI_SUCCESS. I then found that the response was not being checked and thus could cause the PN7150 to stop functioning.

Following my amendment, where I repeated the function call upon an initial NXPNCI_ERROR resolved the problem.

Here is a video I created that captures the problem with MIFARE CLASSIC as compared to other cards. Note I have inserted a "printf" message to indicate when the error occurs and as it has the modification if handles the error case fine.

[Sabina_Bruce]

Hi Colin,

Thank you for the information you have provided. Unfortunately due to the porting of the code to a different board not provided in the examples. It is hard to identify the variables that are causing this in a different board. However, if you can replicate this using the recommend boards, please let me know so I can assist you. 

As it stands in the examples created, the NXPNCI_ERROR is not an expected response in the vary nature of the discovery loop. It is meant to poll and go into a listen state in a repeated manner. If the card were to be removed prior to polling its type, then it would not be detected and simply it would repeat the cycle until it polls for the correct type again. 

Best Regards,

Sabina

[gerrikoio]

Hi Sabina

Thank you for the feedback. Yes, I classify this as an edge case, which can readily be resolved by repeating the NxpNci_StartDiscovery function. Hence no real need anything else as then the edge case is properly taken care of.

Best regards

Colin