I am using an Adafruit PN532 breakout board to emulate an NTAG213 ISO/IEC 14443-2 tag. I have configured the board for emulation with TgInitAsTarget as follows:
[ 0x8C, 0x01,
0x44, 0x00, 0x7B, 0x58, 0x80, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00,
0x00 ];
in response to which I get a ReadSig request for the originality signature:
[ 0x8D, 0x00, 0x3C ]
which confirms communication with the initiator is working. I successfully handle the request by returning the originality signature shown in part and obscured here for obvious reasons:
[ 0x90, 0x??, 0x??, 0x??, ... ]
to which I get a positive response:
[ 0x91, 0x00 ]
I then repeatedly send an explicit GetInitiatorCommand instruction at 100ms intervals (I have tried up to 250ms with no luck) in order to retrieve the next command from the initiator:
[ 0x88 ]
to each of which the PN532 responds with a CRC error:
[ 0x89, 0x02 ]
I am using the same algorithm to calculate the checksum on all these commands when I send them so I don't think my CRC is actually wrong, but to be explicit the full data frame sent to the PN532 is:
[ 0x00, 0x00, 0xFF, 0x02, 0xFE, 0xD4, 0x88, 0xA4, 0x00 ]
When I run the calculations manually this appears to have the correct CRC's for both length and data.
Incidentally if I use a completely different device as the initiator it behaves similarly - though responding initially with a Read command (0x30) - which suggests the problem is on my end.
Does the CRC error maybe apply to something else, the packets going between PN532 and the initiator perhaps? Am I submitting instructions in the wrong order? I admit I don't fully understand the implications of all the options in the TgInitAsTarget data set which I copied from another known good app, maybe I have set up my PN532 emulator incorrectly? Clearly I'm doing something wrong.
Any tips as to what I'm doing wrong or how to diagnose the root cause?
