This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NFC Tag reading unreliable

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

Parents Reply Children
No Data
Related