NFC Tag reading unreliable

[Mik]

Hi,

Sometimes our custom board is not readable with the reader uTrust3700 from Identive and it might be related to this post. We are usind SDK 14.2 with our custom board, but after some investigation the problem does also exist with the Nordic DK (PCA10040, V1.1.1) and SDK16. We have tested with writable_ndef_msg example. We have logged received messages  in the nrfx_nfct_irq_handler in NRFX_NFCT_EVT_ACTIVE(RXFRAMEEND) and found out that when this problem occurs the first received Byte (either 0x02 or 0x03) is missing in the nfct_evt.params.rx_frameend.rx_data.p_data of the nrfx_nfct.c driver. The reader is continously polling for cards and when everything works fine we ge the following sequence of received Messages with RXFRAMEEND, each line is a received Message, with the first byte containing the Message size, the message itself and with the last two bytes as crc :

11 02 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 05 65
06 03 00 ca 7f 68 00 33 bd
08 02 00 a4 00 00 02 3f 00 e9 4e
0f 03 00 a4 04 00 09 a0 00 00 03 08 00 00 10 00 69 66
0f 02 00 a4 04 00 09 a0 00 00 03 97 42 54 46 59 8a fd

When the problem occurs, we get following sequence, the first line contains the last correctly received message, followed by some single byte receptions. After the single byte receptions the received messages are one byte shorter then previously and the first byte (either 02 or 03 is missing). all other data is the same except the crc bytes.

0f 02 00 a4 04 00 09 a0 00 00 03 08 00 00 10 00 43 2e
01 b2 67 c7
01 b2 67 c7
01 c2 e0 b4
01 c2 e0 b4
01 c2 e0 b4
01 c2 e0 b4
0e 00 a4 04 00 09 a0 00 00 03 97 42 54 46 59 cd bb
10 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 59 49
05 00 ca 7f 68 00 ab 86
07 00 a4 00 00 02 3f 00 9b 97
0e 00 a4 04 00 09 a0 00 00 03 08 00 00 10 00 04 68
0e 00 a4 04 00 09 a0 00 00 03 97 42 54 46 59 cd bb

Logging was quite difficult, as using NRF_LOG_HEXDUMP_INFO forces that the problem always to occurs. So we implemented a buffer for storing the received messages and reading them in debugger.

I suspect this is a timing Issue in the Driver, as when using HEX_DUMP it always fails. Do you have a solution or a workaround for this problem?

Kind Regards

Michael

[Susheel Nuguru]

Hi Michael,

Sorry for the late response. This one slipped my radar somehow. I will ask Michal if they have capacity to look into this. 

Normally, the expert developers has a very tight schedule. Probably you can send your reader to Michal but looking into this would totally depend on his capacity to give this debugging extra time. 

[Mik]

Hi Susheel,

I would really appreciate if Michal could spend some additional time on this case. Please let me know where to ship the reader.

kind regards

Michael

[kapi]

Hi Michael,

I reproduced the packet scenario which you described in your first post and I tested it with writable_ndef_msg example. As an NFC reader, I used the following one:

http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/include/st25r3911b_nfc.html#nfc-reader-hardware

Here is how the Reader / Tag data exchange looked like for your packet scenario starting from the last correctly received message:

--- Start of ISO-DEP exchange ---

> E0 80 (RATS)
< 05 78 80 42 02 (ATS)
> 02 00 a4 04 00 09 a0 00 00 03 08 00 00 10 00 (I-block - last correct data message)
< 02 6a 82 (I-block)
> b2 (R(NAK))
< 02 6a 82 (I-block retransmitted)
> b2 (R(NAK))
< 02 6a 82 (I-block retransmitted)
> c2 (S(DESELECT))
< c2 (S(DESELECT))

--- End of ISO-DEP exchange ---

> 02 00 a4 04 00 09 a0 00 00 03 97 42 54 46 59 (I-block)
< (Tag silent - ISO-DEP not active)

I didn't notice any truncation of the RX frame for the last packet.

Looking at the error log for nfc_uart_tag, it seems that the NFC reader behaves incorrectly. After ISO-DEP is deselected with a one-byte packet (C2), the Reader tries sending data packets straightaway (00 CA 7F 68 00) with missing header byte (02).

To activate ISO-DEP protocol, the reader should send RATS command (E0 80) as a first packet. If that's not the case, the NFC tag will ignore all ISO-DEP packets as you can see in your error log (no Tx start log = no response from tag). At this point it doesn't matter if the header byte (02) from ISO-DEP data packet is missing or not - it will still be ignored by the tag (like in the writable_ndef_msg scenario).

Best regards,
Kamil

[Mik]

Hi Kamil,

thanks for the detailed answer and i will forward this to identiv, to get a clarification.

kind regards

Michael