PN7120 RF Prot=ISO_DEP, Mode=POLL, RF Inf=frame problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PN7120 RF Prot=ISO_DEP, Mode=POLL, RF Inf=frame problem

839 Views
frank689
Contributor I

I'm trying write my own library interface with our EMV kernel.

Somehow when I run rf_discover_map_cmd with RF Prot=ISO_DEP, Mode=POLL, RF Inf=frame, it will stuck after first apdu data exchange.

DH Send =>

0000 | 00 00 16 0a 01 00 a4 04 00 0e 32 50 41 59 2e 53  ..........2PAY.S
0010 | 59 53 2e 44 44 46 30 31 00                       YS.DDF01.

NTF < =

0000 | 60 06 03

0000 | 01 00 01

PICC Response <=

0000 | xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
0010 | xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
0020 | xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
0030 | xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx

DH Send =>

0000 | 00 00 0f 0a 01 00 a4 04 00 07 a0 00 00 00 03 10  ................
0010 | 10 00

NTF <=

0000 | 60 06 03

0000 | 01 00 01

DH send 2nd command to the RFID card, The PN7120 return Connection credit Notification = 1

and then got stuck.

I have for 4 cards. 2 card got stuck . 2 card works fine.

When I try reconfigure rf discovery map command with isodep/isodep mode, all cards work fine.

Labels (2)
0 Kudos
3 Replies

524 Views
christianeisend
NXP Employee
NXP Employee

Hi,

why do you want to use RF_Intf=Frame and not Rf_Intf=ISO_DEP ?

In case you use Frame RF_Intf you need to implement the full ISO_DEP protocol on your host controller which at the end will not be possible since you also need to come up with the exact timing requirements, which is difficult to fulfill knowing there is a latency over the host interface and your host stack which needs to be considered.

In case you *really* may want to use Frame RF_intf then the problem with the sequence above is that the second frame sent by DH (0000 | 00 00 0f 0a 01 00 a4 04 00 07 a0 00 00 00 03 10 ) sequence has a wrong PCB (protocol control byte) where you need to toggle the block number.

HTH,

Christian.

524 Views
frank689
Contributor I

Thanks It works after I alternate the block_number bit it works fine.

To answer your question, it seems that RFIntf=ISO_DEP seems to hiding all extra information (like ATS). I'm not sure we will need those in the future when we work with our own Emv Kernel. The Emv Kernel library API we received from our vendor do need ATR.
Is there any way to retrieve ATS when using RF Intf=ISO_DEP mode?

0 Kudos

524 Views
christianeisend
NXP Employee
NXP Employee

Hi,

also in case of ISO_DEP RF interface you will be receiving the ATS. It's part of the RF_INTF_ACTIVATED_NTF (61 05 xx). The payload of this RF_INTF_ACTIVATED_NTF contains beside other information also the activation parameters. The last bytes within that NTF are the ATS (RATS response). Please refer to NFC-Forum NCI Technical Specification 1.1 for more information.

HTH,
Christian.

0 Kudos