Questions and problems with processing IRQ requests from TRF7963A Reader/Writer IC

Hello,

I am using the TRF7963A Reader/Writer IC to read and write tags that use an NXP NTAG213 device.

I was wondering if there is a recommended method for determining what actions to take in the interrupt handler based on the bits that are set in the IRQ Status Register when an IRQ service request is raised by the device. In particular are there certain conditions that take priority over others, and are any of the bits in the IRQ Status register mutually exclusive?

I believe I am not processing the IRQ interrupts correctly because I am encountering some unexpected results when going through the procedure for selecting a tag. I am also not obtaining the data I expect when reading from a (selected) tag using the NFC Forum READ command.

Some additional information:

-          The NXP NTAG213 device is compliant with NFC Forum Type 2 Tag and ISO/IEC14443 Type A specifications

-          It has a 7-byte NFCID1

-          I am not implementing any of the anti-collision procedures.

To show what the interrupt handler is seeing I am logging the value of the IRQ Status Register (0x0C) each time the IRQ request is processed.

Example 1

One example of something I am encountering occurs when sending an SDD_REQ command for cascade level 2. This problem does not always occur and when it does not happen I am able to successfully select the device and obtain its UID. I ask the TRF7963A to transmit the following (so the listening tag should transmit back the complete cascade level 2 of its NFCID1):

 0x95 0x20

I then receive 2 successive IRQ interrupts with the bits of the IRQ status register as shown (note that only the positions numbers of bits that are set are shown and zero bits are represented by underscores):

First interrupt                    {7_______}         (End of transmit phase)

Second interrupt              {_6_____0}        (Receive started AND no response timeout)

The logic I use in my interrupt handler stops processing the transaction because the “no response” (bit 0) is set. However it seems contradictory that the both the “RX start” (bit 6) and the “no response” bits are set at the same time.

If I re-try the same transaction again, the next interrupt has the IRQ status register as:

{76______}

My interrupt handler ends the transaction on account of bit 6 being set without the “FIFO high/low” (bit 5) also set. However, I haven’t found anything in the documentation to indicate how to proceed when both bits 7 and 6 are set at the same time.

If I re-try the same transaction a third time I see the following, which is typically what I will see for any transaction when there are no listening devices in the field:

First interrupt                    {7_______}

Second interrupt              {_______0}

Example 2

A second problem I am having occurs when I have a tag properly selected and I send the READ command and expect to receive 16 bytes.  Below are the IRQ service requests I see and how I process each.

 When the transaction is finally over I have received the expected number of bytes (16), however when I compare them to what I expect to receive there is a discrepancy (see table below). The first 10 bytes read from the FIFO are correct. However the next 6 bytes are not. It appears that either data is missing or possibly the internal FIFO buffer pointer is offset by one position for the second read (hard to tell for sure because of the multiple zero values).

If anyone can point out any mistakes that I am making in processing these interrupts, or point me to some guidelines on how to do this I would really appreciate it.

Thank you,

Steve