AnsweredAssumed Answered

Unreliable Communications between PN532 and NTAG I2C Plus (NT3H2111) over NFC

Question asked by Tony Garland on Oct 6, 2016
Latest reply on Oct 19, 2016 by Tony Garland

I'm close to having pass-through mode working to support the ability to transfer data in two directions (RF->I2C and I2C->RF) in a product I'm working on.  I'm driving the RF side of the interface using an Arduino Uno with PN532 cape (and a slightly modified version of the Arduino PN532 library).  The PN532 reports its firmware version as 1.6.

 

There are times when I'm able to successfully achieve multiple alternating data transfers through the NTAG I2C Plus 1K without any problems. But, many other times, part way through operation, the PN532 returns a reply indicating error 0x01 which, from what I see in the PN532 manual indicates a timeout when waiting on the NFC tag to reply.

 

Once I see this timeout occur, it seems to "latch" and subsequent reads and writes continue to fail with this error code returned.  The only solution to the situation that I've found is to reset the PN532 and start over.

 

I've read the PN532 manual and tried to boost timeout and retry-related values, all to no avail:

  • Boosted RF configuration item 4 (MaxRtyCOM) to 5.
  • Boosted RF configuration item 2 so that ATR_RES timeout is boosted from 102.4 ms to 204.8 ms and fRetryTimeout has been set to 204.8 ms (and much higher values when experimenting).

 

I'm also seeing occasional error 0xB (RF protocol error), although these can be worked around by repeating the command--they do not 'stick' like the timeout condition seems to.

 

I'm at a loss to know what I need to do to fix these problems?  I'm relatively new to the world of NFC RF communication, especially the nitty-gritty details, so some of the configuration/customization settings that are possible using the PN532 are still a bit mysterious to me.

 

Is the PN532 compatible with the NT3H2111 (NTAG I2C PLUS 1K)?  Are there changes to the default PN532 configuration I should be aware of to allow this to work reliably?

 

I've appended a representative trace of a failed write attempt (but reads can also fail) below.  First it encounters error 0xB (RF protocol error) and then sees errors 0x1 (timeout) which continue "forever."

 

Thanks for any guidance you can provide. - Tony

 

Checking for RF_LOCKED in NS_REG to be sure we can write.

Sending: 0x0 0x0 0xFF 0x5 0xFB 0xD4 0x40 0x1 0x30 0xED 0xCE 0x0

Reading: 0x0 0x0 0xFF 0x13 0xED 0xD5 0x41 0x0 0x8 0x1 0x21 (RF LOCKED, RF_FIELD_PRESENT) 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xC0 0x0

 

Writing to end of SRAM (page 0xFF):

Sending: 0x0 0x0 0xFF 0x9 0xF7 0xD4 0x40 0x1 0xA2 0xFF 0x1 0x2 0x3 0x4 0x40 0x0

Reading: 0x0 0x0 0xFF 0x3 0xFD 0xD5 0x41 0xB (RF protocol error) 0xDF 0x0

 

Retry after the above failure has exact same exchange.

 

Third retry to write now returns timeout error (and from that point "forever"):

Sending: 0x0 0x0 0xFF 0x9 0xF7 0xD4 0x40 0x1 0xA2 0xFF 0x1 0x2 0x3 0x4 0x40 0x0

Reading: 0x0 0x0 0xFF 0x3 0xFD 0xD5 0x41 0x1 (timeout error) 0xE9 0x0

 

(Repeats ad-nauseum...)

Outcomes