PN532 PICC emulation mode issues

[euttsov]

Hi all. I am trying to emulate PICC 14443-A card with PN532 using HSU communication mode with Microsoft IoT bindings libraries. 

Here is my InitAsTarget command:

(modeInitialized, retData) = pn532.InitAsTarget(
                                        TargetModeInitialization.PiccOnly,
                                        new TargetMifareParameters() { Atqa = new byte[] { 0x08, 0x00 }, Sak = 0x60 },
                                        new TargetFeliCaParameters() { NfcId2 = new byte[] { 0x01, 0xFE, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7 }, Pad = new byte[] { 0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7 } },
                                        new TargetPiccParameters() { NfcId3 = new byte[] { 0xAA, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11 }, GeneralTarget = new byte[0], HistoricalTarget = new byte[0] });

I tested two cases:
1) invoke pn532.InitAsTarget() command in cycle

2) split pn532.InitAsTarget() command into two separate commands:
2.a) one write TgInitAsTarget and read ACK
2.b) second just wait for response from pn532 when external reader appeared

In the first case the phone read a module for a very long time, but finally I got the NDEF from records from the module, providing them by host.
In the second case the phone never got info from the module. 

I decided to dump NFC exchange between phone and module by Proxmark 3 and here what I got:

This is dump for second case - TgInitAsTarget written into PN532, ack received and I waiting for TgInitAsTarget response from UART.

Start	End	Src	Data (! denotes parity error)	CRC	Annotation
0.0	73.2	Rdr	52(7)		WUPA
165.5	340.1	Tag	08  00
886.1	1237.8	Rdr	50  00  57  cd	ok	HALT
64599.4	64672.6	Rdr	52(7)		WUPA
502345.7	502418.9	Rdr	52(7)		WUPA
502563.1	502577.3	Tag	01(0)
503231.9	503583.5	Rdr	50  00  57  cd	ok	HALT
566953.4	567026.5	Rdr	52(7)		WUPA
1004770.5	1004843.7	Rdr	52(7)		WUPA
1004936.0	1005110.6	Tag	08  00
1005656.6	1006008.3	Rdr	50  00  57  cd	ok	HALT
1069372.3	1069445.4	Rdr	52(7)		WUPA
1515000.6	1515073.7	Rdr	52(7)		WUPA
1515886.7	1516238.3	Rdr	50  00  57  cd	ok	HALT
1579601.2	1579674.3	Rdr	52(7)		WUPA
2017453.7	2017526.8	Rdr	52(7)		WUPA
2017619.2	2017793.8	Tag	08  00
2018341.0	2018692.6	Rdr	50  00  57  cd	ok	HALT
2082054.3	2082127.4	Rdr	52(7)		WUPA
2519814.7	2519887.9	Rdr	52(7)		WUPA
2520700.9	2521052.5	Rdr	50  00  57  cd	ok	HALT
2584417.7	2584490.9	Rdr	52(7)		WUPA
3030027.1	3030100.3	Rdr	52(7)		WUPA
3030913.3	3031264.9	Rdr	50  00  57  cd	ok	HALT
3094632.4	3094705.6	Rdr	52(7)		WUPA
3532444.8	3532518.0	Rdr	52(7)		WUPA
3532610.3	3532785.0	Tag	08  00
3533331.0	3533682.6	Rdr	50  00  57  cd	ok	HALT
3597056.0	3597129.2	Rdr	52(7)		WUPA
4034805.9	4034879.1	Rdr	52(7)		WUPA
4035692.0	4036043.7	Rdr	50  00  57  cd	ok	HALT
4099411.2	4099484.4	Rdr	52(7)		WUPA
4545023.0	4545096.2	Rdr	52(7)		WUPA
4545188.5	4545363.1	Tag	08  00
4545909.1	4546260.8	Rdr	50  00  57  cd	ok	HALT

In the dump above I've noticed the same repeat pattern - phone issue WUPA command. Module accepts it and answer 08 00. Than phone decide to start whole sequence from the beggining and issue HALTA command (50  00  57 cd) and then WUPA(52) again.
First WUPA remains unanswered and phone issue WUPA command, that the PN532 answer this time. Phone restarts whole sequence after the answer.

And for first case we've got:

Start	End	Src	Data (! denotes parity error)	CRC	Annotation
13121188.2	13121539.8	Rdr	50  00  57  cd	ok	HALT
13184913.3	13184986.4	Rdr	52(7)		WUPA
13630572.3	13630645.4	Rdr	52(7)		WUPA
13630737.5	13630912.1	Tag	08  00
13631458.4	13631810.0	Rdr	50  00  57  cd	ok	HALT
13695188.2	13695261.4	Rdr	52(7)		WUPA
14132999.4	14133072.6	Rdr	52(7)		WUPA
14133163.4	14133338.1	Tag	08  00
14133885.5	14134237.2	Rdr	50  00  57  cd	ok	HALT
14197602.4	14197675.5	Rdr	52(7)		WUPA
14197767.6	14197942.2	Tag	08  00
14198488.5	14198670.2	Rdr	93  20		ANTICOLL
14198757.5	14199191.7	Tag	08  00  00  00  08
14199733.3	14200505.0	Rdr	93  70  08  00  00  00  08  f4  0f	ok	SELECT_UID
14200597.1	14200861.4	Tag	60  f8  32	ok
14210462.5	14210814.2	Rdr	e0  80  31  73	ok	RATS
14212232.4	14212831.9	Tag	05  75  33  92  03  ac  63	ok
14223313.3	14223575.2	Rdr	c2  e0  b4	ok
14225215.3	14225474.9	Tag	c2  e0  b4	ok
14229224.8	14229297.9	Rdr	52(7)		WUPA
14229390.0	14229564.6	Tag	08  00
14230110.9	14230882.6	Rdr	93  70  08  00  00  00  08  f4  0f	ok	SELECT_UID
14230974.6	14231238.9	Tag	60  f8  32	ok
14231780.5	14232132.2	Rdr	e0  80  31  73	ok	RATS
14233238.9	14233838.3	Tag	05  75  33  92  03  ac  63	ok
14241905.6	14243272.0	Rdr	02  00  a4  04  00  07  d2  76  00  00  85  01  01  00  35  c0	ok
14250518.0	14250867.3	Tag	f2  07  a7  25	ok
14251410.0	14251761.7	Rdr	f2  07  a7  25	ok
14278827.1	14279256.6	Tag	02  90  00  f1  09

Looks like in successful case WUPA answer comes immediately after the first WUPA command, while in failed case only the second WUPA command gots answered. 

And there is a question - does anybody faced already wtih the same problem and how to solve it if it possible?

Thanks in advance.