AnsweredAssumed Answered

Handling of hardware failures in NFC reader library

Question asked by Julie Ronday on Oct 10, 2018
Latest reply on Oct 23, 2018 by IvanRuiz



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,