Handling of hardware failures in NFC reader library

[julieronday]

Hello,

I am wondering about handling of hardware failures in NFC reader library.

I am working with version 5.12 of the library without operating system. I am using PN5180 chip and LPC2368 microcontroller.

It is not acceptable for my application to stay blocked in the NFC reader library in case the PN5180 is out of order but I note the following behaviour:

- In case the BUSY line stays at high or low level, the application is blocked in phhalHw_Pn5180_BalExchange function.

- In case the IRQ doesn't occur, the application is blocked in phOsal_EventPend function (called with argument ticksToWait = PHOSAL_MAX_DELAY for infinite wait) except if phhalHw_AsyncAbort function is called.

In case of PN5180 hardware failure, I would like to return from the library and to detect the hardware failure in order to try to recover from the failure by reinitialising the chip and the library.

My first intention was to call phhalHw_AsyncAbort in a timer interrupt in case a function of the library does'nt return in a given delay and to return PH_ERR_ABORTED from phhalHw_Pn5180_BalExchange in case the BUSY line stays at the same level for too long but it seems that, for some functions, a returned PH_ERR_ABORTED status doesn't come up to the top level API.

As a consequence, my workaround would be to handle a fault in a module outside the library (to be called at different places in the library) for relevant cases. Is there another way to handle this ? How am I supposed to handle abort ? How/when to force it and how to know that it happened ? What is the exact purpose of that feature ?

Thanks beforehand,

Julie

[m_sedlak]

Hi @jan_ch

Just "answering" to this topic, since I'm facing the same issue as you did, with the CLRC66303.

I'm using 3rd party MCU, connected to the CLRC663, and did the NullOs porting of the library "NxpNfcRdLib_07.05.00_20220527" and the issue I face is: 

For polling ISO14443B tag, from time to time, the NxpNfcRdLib gets stuck in the infinite loop, waiting for the "event" from the CLRC663.
Namely in the phOsal_EventPend(), where a while(1) loop is, waiting for an external IRQ from the CLRC663, that breaks this loop.

Unfortunately, if you are "lucky" the CLRC663 never gives you the required IRQ, and the phOsal_EventPend() waits indefinitely since it's called with the PHOSAL_MAX_DELAY parameter.

If you are interested, this is how the call stack looks like:

And this is the CLRC_IRQ pin:

The issue happens typically when the NFC reader (custom-based with the CLRC663) is not perfectly aligned with the ISO14443B tag antenna.

Based on the call stack, the CLRC663 can get the ATQB (answer to REQB), and then the library gets stuck when performing the ATTRIB command and waits for the response from the PICC. 
Here I assume, the CLRC663 can't properly decode the correct answer (since it typically happens when the antennas are not properly aligned) and it just waits indefinitely (PHOSAL_MAX_DELAY) for the answer, that never comes. 

To solve this, I'm gonna modify the library to remove this indefinite wait, so a "normal" timeout of the while loop can happen... 

(or lowering the PHOSAL_MAX_DELAY)

Kind Regards,
Milan

[jan_ch1]

Hi @m_sedlak,

thank you for your answer.

I found out that this was happening due to a missing IRQ signal from CLRC and resolved it by simply posting an abort event in my application when I detected that the reader got stuck for too long. I used phOsal_EventPost with E_PH_OSAL_EVT_ABORT event. I was more keen on this solution as I knew if the issue persisted and also I didn't want to modify the library source. 

This worked fine for me. However, I must say I am no longer getting this behaviour from CLRC, but I still kept this solution in the source. I don't know exactly what fixed this issue, could be firmware or hardware.

Best regards, Jan

[jan_ch]

Dear julieronday,

I am having the same issues with CLRC66303 frontend. May I ask you how did you solve your problem?

Best regards ,

Jan

[IvanRuiz]

Hello,

It is recommended to first start with our eval board and then move to another hardware, once comprehended.

OM25180 |PN5180 NFC Development Kit for POS Readers|NXP 

Regards,

Ivan.

[mrdjoni]

Hello Ivan,

I'm using Eval board and I'm facing the same issue. So it is not about that.

PN5180 NFC Frontend Development Board is used

BR,
Miroslav