4

I'm trying to put my PN532 in card-emulation mode. When i send the TgGetData command the error i get an error back from the reader.

1 . Read register

{(byte)0xFF,0x00,0x00,0x00,0x08,  (byte)0xD4, 0x06, 0x63, 0x05, 0x63, 0x0D, 0x63, 0x38 }

RESPONSE :: D507 07 07 15 9000

2 . Update registers

byte xx = (byte) 07;    
byte yy = (byte) 07;
byte zz = (byte) 15;
xx = (byte) (xx | 0x004); 
yy = (byte) (yy & 0x0EF); 
zz = (byte) (zz & 0x0F7);

3 . Write register

{(byte)0xFF,0x00,0x00,0x00,0x11,  (byte) 0xD4, 0x08, 0x63, 0x02, (byte) 0x80, 
0x63, 0x03, (byte) 0x80, (byte) 0x63, (byte) 0x05,
xx, 0x63, 0x0D,yy, 0x63, 0x38, zz}

RESPONSE :: D509 9000

4 . Set parameters

{(byte)0xFF, 0x00, 0x00 ,0x00, 0x03, (byte)0xD4, 0x12, 0x30}

RESPONSE :: D513 9000

5 . TgInitAsTarget

{(byte)0xFF, 0x00, 0x00, 0x00 , 0x27 , (byte)0xD4, (byte)0x8C , 
0x05 , 0x04, 0x00 , 0x12, 0x34, 0x56 , 0x20 , 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}

RESPONSE :: D58D 08 E0 80 9000

6 . TgGetData

{(byte)0xFF, 0x00, 0x00 ,0x00, 0x02, (byte)0xD4, (byte)0x86}

RESPONSE :: D587 29 9000

So the response of TgGetData gives a error code D587 29 9000 with means following the PN532 user manual:

  • Error code 0x29: The PN532 configured as target has been released by its initiator

Any advice or comment related to this code is welcome.

Many thanks in advance!

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
S.Pols
  • 3,414
  • 2
  • 21
  • 42
  • I believe the answer you're looking for can be found in this [answer](http://stackoverflow.com/a/21107403/2567273). Your setup may be different, but this guy had the same problem. Make sure to read the comments in my link to find more information. – Luminous Jul 24 '14 at 19:02
  • Does the `TgGetData`command immediately follow the `TgInitAsTarget` command or is there a (short) delay in between? – Michael Roland Jul 25 '14 at 06:05
  • The value (0x15) you read from register 0x6338 looks as if there is an AutoColl command ongoing. Did you freshly plug-in the reader when you retrieved those values? Also note that setting `zz = (byte) 15;` is not equal to setting `zz = (byte) 0x15;`. – Michael Roland Jul 25 '14 at 06:07
  • @user2567273 tnx for your reply. I did, i looked a lot on that answer and the comments. Unfortunately didn't came farther with it. – S.Pols Jul 25 '14 at 06:18
  • @MichaelRoland i tried several times re-plugin and testing and the register values are now 0x07, 0x07, 0x05. Thanks for your note. I will change 15 to 0x05. There is a short delay between TgGetData and TgInitAsTarget. Is it possible that the problem is that my indicator just doesn't reply before the timeout expires? – S.Pols Jul 25 '14 at 06:23
  • I mean initiator instead of indicator. – S.Pols Jul 25 '14 at 06:34
  • Yes, that's possible. I typically experienced that while single-stepping my code. Still, I don't like that that register indicates some operation is ongoing. (Btw. when I freshly plug in my ACR122U, all registers seem to be at their default values (for the avove registers this means all zeros.) Could you try to send the following command to the reader first: `FF 00 51 00 00`? – Michael Roland Jul 25 '14 at 06:34
  • Can I get full code for this as I am a beginner on this and I am stuck at sending data to Android from PN532. – SNarula Jul 03 '19 at 10:48

1 Answers1

1

First of all, there exist several different versions of the ACR122U that differ significantly in their behavior. I've successfully tested the above sequence with version 101 and 102 and could emulate a constactless smartcard with those readers. However, version 103 seems to accept those commands but is not detectable as contactless card. None of my tests revealed your issue though.

Besides that inconsistent behavior, there could be several causes for this issue:

  • The connection times out in between the TgInitAsTarget and TgGetData because there is too much delay between the response to TgInitAsTarget and the TgGetData command. I experienced this while single-step debugging my card emulation code.

  • The reader automatically enables itself for auto PICC detection (this seems to be available on version 2xx only) and consequently overrides the commands and parameters you sent for card emulation. The ACR122U manual indicates that you can disable automatic PICC detection by sending the APDU command FF 00 51 00 00. I tried this with my 10x versions and they did not understand that command.

  • The activation that causes the emulated PICC to be released (and consequently causes TgGetData to return status code 0x29) could be part of the reader's regular operation: This could indicate, for instance, that the reader activated the emulated PICC, then halted it and deactivated the HF field, the reader could then reactivate the HF field and reactivate the emulated PICC. In that case you would have to restart the PICC emulation (issue another TgInitAsTarget command as soon as you received the status code 0x29 from TgGetData.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • Point 3 of your answer: Reactive the PICC by sending another TgInitAsTarget solved my issue! Thank you so much! – S.Pols Jul 25 '14 at 10:45
  • Besides a sequent i tried a `while(true)` loop with all the commands. I noticed that it fails each time it successed. So after it fails the second `TgInitAsTarget` and `TgGetData` will success. – S.Pols Jul 25 '14 at 10:53
  • Michael, i updated my android to 4.2.2 and this solution stopped working. Is it possible that the update caused this problem? It's a very strange problem. – S.Pols Sep 15 '14 at 18:49