I'm Developing with the PN7150
With the LPC82X
And have been following and using the given Example (AN11990) as a baseline
~ NXP-NCI MCUXpresso example Project (REV 1.5)
So far I've gotten the board to function as expected when operating in the Reader/Writer and Card Emulation Modes,
where I've been focusing on performing Raw exchanges (Non-NDEF) of data between the PN170 and other NFC-Devices.
I have found a Bug in either the Software, Hardware or both that causes the
PN7150 to Stop Detecting Any NFC Devices;
Specifically it occurs after repeated Read Failures reading against an NFC-Card or NFC-Host-Card-Emulated device
For my example, I am using an Android-Device operating in Host-Card-Emulation mode.
But where I am purposefully having the Android-Device send back a Response APDU with Null
values for both the SW1 and SW2 bytes.
For the PN170-Example, I have the following settings changed from the default state;
- P2P_SUPPORT symbol not defined (global)
- RW_RAW_EXCHANGE defined (/Application/nfc_task.c)
- CARDEMU_RAW_EXCHANGE defined (/Application/nfc_task.c)
- in the PCD_ISO14443_4_scenario function (/Application/nfc_task.c),
I've changed the SelectPPSE array (SELECT APDU Command) to use a custom AID to target the HCE Application running on the Android-Device;
{
0x00, 0xA4, 0x04, 0x00,
0x09,
0xF0, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
0x00
};
The resulting behavior is as follows;
- I bring the Android-Device to the PN170
- within /Application/nfc_task.c we have the following sequence of function calls repeat while the Android-Device
is by the PN170;
task_nfc ->
task_nfc_reader ->
PCD_ISO14443_4_scenario ->
NxpNci_ReaderTagCmd
Ending with a "Select PPSE failed with error.." print line, before we start back at the top of the task_nfc main loop once more.
- Eventually (within a minute or less), the prior sequence stops occuring.
Removing the Android-Device, then bringing it, or any other NFC device to the PN170 will now not have any effect. The PN170 can no longer detect any NFC devices at this point!
- From pausing execution, we seem to be stuck in an NFC signal detection loop of;
tml_WaitForRx (/TML/src/tml.c) ->
gpio_GetValue (/Drivers/src/gpio.c) ->
Chip_GPIO_GetPinState (/LPC82X/inc/gpio_8xx.h)
Where gpio_GetValue(PORT_IRQ, PIN_IRQ) == LOW is now forever true.
- Only in restarting the PN170 can I get it to again detect NFC Devices normally as before.
Is there anything that can be done to fix the state of the PN170 application without having to restart it,
once it gets into this state?
Perhaps a command to drive a signal to the affected Pins/Ports, to get them to reset themselves?
I ask since I view this behavior as a potential exploit, that could be carried out either by chance or through malicious intent.
Hi Andrew,
Sorry for the late reply. I am working on this issue that you are facing
I want to confirm the modification or the set up that you did.
For the PN170-Example, I have the following settings changed from the default state;
Could you please define the properties of the project?
However, I am running the same test and I reproduced the same issue that you are facing. I am checking this and I will get back to you as soon as possible.
Regards,
Mario
Hello Mario,
below is a screenshot of the Preprocessor-Settings I have been using as of late for the PN170-Example-Project
Besides the settings I had mentioned in my last post;
- I have removed DEBUG_SEMIHOSTING symbol since redirecting the Trace-Output to Serial/COM output allows the program to perform faster and with better success in communication
- I have defined the NO_NDEF_SUPPORT symbol, as I am only interested in performing Raw exchanges (Non-NDEF) of data between the PN170 and other NFC-Devices
But even with these symbols as defined, the issue as I'd reported still persists.
Below are some modifications I made to the code that seem help mitigate the issue, such that I do not
have to restart the PN170 in order to get NFC detection working again.
The gist of it is that I periodically restart the NCI-Discovery, based on the last time it was started/restarted which seems to reset the Pins/Ports back to a working state.
The only issue with this approach is that it seems to negatively affect the success rate of NFC communication in general, especially if I run it over shorter intervals.
Let me know if you are able to determine a more viable solution.
(/Application/nfc_task.c)
/* Callback function to restart NCI-Discovery */
void restartDiscovery(){
// We will restart discovery if it has not been restarted in the last 60 seconds
if (difftime(time(0), last_discovery_restart) > 60){
bool successStop = NxpNci_StopDiscovery();
bool successStart = NxpNci_StartDiscovery(DiscoveryTechnologies,sizeof(DiscoveryTechnologies));
/* Start Discovery */
if (successStart != NFC_SUCCESS) {
PRINTF("Error: cannot Restart discovery\n");
}
else {
last_discovery_restart = time(0);
}
}
}
/* Modification of existing task_nfc function */
void task_nfc(void){
...
int rw_interval = 1000; // Interval to periodically break from NxpNci_WaitForReception loop
/* Wait until a peer is discovered */
while(NxpNci_WaitForDiscoveryNotification(&RfInterface, restartDiscovery, rw_interval) != NFC_SUCCESS);
...
}
(/NfcLibrary/NxpNci/src/NxpNci.c)
/* Modification of existing NxpNci_WaitForDiscoveryNotification function */
bool NxpNci_WaitForDiscoveryNotification(NxpNci_RfIntf_t *pRfIntf, void (*rw_callback)(), int loopInterval){
...
do {
// We callback to restart discovery as needed
rw_callback();
// Set loopInterval to interval to periodically break from NxpNci_WaitForReception loop
if(NxpNci_WaitForReception(Answer, sizeof(Answer), &AnswerSize, loopInterval) == NXPNCI_ERROR) {
return NXPNCI_ERROR;
}
}
while ((Answer[0] != 0x61) || ((Answer[1] != 0x05) && (Answer[1] != 0x03)));
...
}
Hi Andrew,
I am checking this and I will get back to you as soon as possible.
Regards,
Mario
Hi Andrew,
I have been following the issue that you are facing.
I confirmed with the R&D Team and the workaround that you are implemented is correct.
Please let me know if you still have this issue.
Regards,
Mario