Send TgInitAsTarget command to PN532 (ELEHOUSE module)，get ACK frame back, but lost the normal information frame

Question

I am getting started with a PN532 NFC module recently. I can successfully read/write M1 and S50 cards.

Now I am trying to learn how to use P2P communication. However, when I send a TgInitAsTarget command to the PN532 (ELEHOUSE module), I receive an ACK frame, but I never receive the normal information frame that should follow afterwards.

Here are my steps:

1. Get PN532 into target mode by sending TgInitAsTarget command:

   TgInitAsTarget:
   { 00 00 ff 0x27 0xd9
     d4 8c 04
        08 00 12 34 56 40
        01 fe a2 a3 a4 a5 a6 a7   c0 c1 c2 c3 c4 c5 c6 c7   ff ff
        aa 99 88 77 66 55 44 33 22 11
        00
        00
     fd 00 }
   

2. Get a second PN532 into initiator mode by sending InJumpForDEP command:

   InJumpForDEP:
   { 00 00 ff 0a f6
     d4 56 01 02
        01   00 ff ff 00 00
     d4 00 }
   

3. Put the initiator above the target.

4. When I read the information received from the target through UART, I get the following:

   target->pc:
   { 01
     00 00 ff 00 ff 00 }
   

   This seems to be an ACK frame indicating that the TgInitAsTarget command was processed correctly. But afterwards the PN532 does not send the normal information frame containing the result of the TgInitAsTarget command and the target is always in busy state.

What is going wrong here?

Answer 1

Several things seem to be wrong with your commands.

1. First of all, the InJumpForDEP command seems to be malformed. That command decodes to the following:

   d4 56   InJumpForDEP
      01   ActPass = Active Mode
      02   Baud Rate = 424 kbps
      01   Next = NFCID3i
      00 ff ff 00 00  NFCID3i ? (HERE is the problem)
   

   The NFCID3i field of that command is not valid. An NFCID3i must consist of 10 bytes (e.g. 11 22 33 44 55 66 77 88 99 AA). The easiest way would be to let the PN532 automatically generate a random NFCID3i by not specifying an NFCID3i field at all:

   d4 56   InJumpForDEP
      01   ActPass = Active Mode
      02   Baud Rate = 424 kbps
      00   Next = none
   

   Note that length field and checksum of the command frame need to be adapted accordingly.

2. The initiator is polling in active mode at baud rate 424 kbps. However, with your TgInitAsTarget command, you instruct the target to listen in PICC mode only:

   d4 8c   TgInitAsTarget
      04   Mode = PICC only ! (HERE is the problem)
      08 00 12 34 56 40   MifareParams
      01 fe a2 a3 a4 a5 a6 a7   c0 c1 c2 c3 c4 c5 c6 c7   ff ff   FelicaParams
      aa 99 88 77 66 55 44 33 22 11   NFCID3t
      00   no Gt
      00   no Tk
   

   Consequently, the target will only operate as ISO/IEC 14443-4 PICC (which is similar to passive mode at 106 kbps). Therefore, the initiator and the target are configured to speak two completely different protocols and, hence, do not understand each other. As a result, the PN532 in target mode will never be invoked by the PN532 in initiator mode and will, consequently, never return from the TgInitAsTarget command.

   In order to configure the target in a way that is compatible to your initiator configuration, you could use this:

   d4 8c   TgInitAsTarget
      02   Mode = DEP only
      08 00 12 34 56 40   MifareParams (not used in active mode)
      01 fe a2 a3 a4 a5 a6 a7   c0 c1 c2 c3 c4 c5 c6 c7   ff ff   FelicaParams (not used in active mode)
      aa 99 88 77 66 55 44 33 22 11   NFCID3t
      00   no Gt
      00   no Tk (not used in active mode)
   

Answer 2

Finally,I solved the problem, it is a hardware problem ,and i buy new PN532 module. The normal information frame return successfully。 Thanks anyway @Michael Roland .