PN5180 SEND PPSE COMMAND (For EMV Cards)

cancel
Showing results for 
Search instead for 
Did you mean: 

PN5180 SEND PPSE COMMAND (For EMV Cards)

Jump to solution
330 Views
EkArge
Contributor II

I have a pn5180 reader. I can send WUPA command to an EMV card (ISO 14443-A) with PN5180. I can also get the UID information of the card. I can also send a RATS command to the card and get the ATS statement, which is the answer.

However, after sending a RATS command (a PICC receiving a RATS command goes into a "protocol state") some strange situations can occur. These can be listed as:
a- I cannot read a Register of pn5180.
b- When I send a PPSE command, the responses I get are 0xFF.
c- I get a response to the DESELECT command, but when I send WUPA to the card again, a problem occurs.

In short, why doesn't a PPSE command I send after the RATS command return a proper response? I wonder if some adjustments need to be made before or after the RATS command?

Labels (1)
  • RF

Tags (4)
0 Kudos
1 Solution
190 Views
AlexanderB
NXP Employee
NXP Employee

Hi @EkArge ,

The relation is quite easy once you understood it. You always will get the integer within the ATS but what you, most probably, need for your timer is the actual FWT (Frame Waiting Time). Which is calculated as follows: FWT = (256 * 16/fc) * 2 ^ FWI

So at your EOF (End of Frame) you start the FWT timer. The external tag must answer within this time. If it does not you either have a receiver problem or the tag is really not answering within time. For actual Tags this is very very rarely the case. If it is some external card emulator this is another story. Here it often is bad implementation. 

After the timer elapsed your point of view is that the PICC didn't send. You issue a NACK to request resending of the last frame. 

All that is very well explained at Annex B of the ISO/IEC 14443-4 specification. 

A proper implementation of PCB (Protocol Control Byte) with its I-Frames, R-Frames and S-Frames is crucial. I highly recommend, in case you didn't do it already, to get familiar with it and its way of working. Also a WTX (waiting time extension) is important to be implemented correctly. Those you will encounter most if your target is a mobile phone.

Best regards,
Alexander

 

View solution in original post

6 Replies
241 Views
AlexanderB
NXP Employee
NXP Employee

Hello @EkArge ,

from what I can read above I guess you are not using our NFC Reader Library, right? If there is no particular reason why you don't use it I strongly recommend to check it out NXP NFC Reader Library . It will handle all protocol related wrapping as well as settings and taking care of timings. If you do not wanna use it, it might be also nice to just have a look how things are handled as a kind of guide.

To your questions: 

1. The PN5180 is adding the CRC automatically in case it is turned on. As you correctly pointed out. It is not necessary for you to add the EDC(CRC) manually.

2. Yes, you have to set FWI (--> FWT) by yourself (if you are not using our library which is doing that for you). Else the PN5180 doesn't know about the right FWT and might cancel the transaction too early. In case the default FWT is shorter as the FWT asked by the external tag. 

If you are using our HAL (hardware abstraction layer) of the NP5180 this can be done by using the Set Config "PHHAL_HW_CONFIG_TIMEOUT_VALUE_MS".

Else you have to use an PN5180 (timer1 for example) to do count the FWT and interrupt on elapse on your own. Here I would, again, recommend to take reference in the NFC Reader Library how this can be handled (there are obviously a lot of ways to implement that and often it boils down to personal flavours how it will be done, nevertheless the reader library can be a valueable reference and taking guidance).

I hope that was helpful. Do not hesitate to ask if anything is unclear.

Best regards,
Alex

194 Views
EkArge
Contributor II

@AlexanderB  Thanks a lot for your answers.

From the answers you gave, I understand that I am not wrong on other issues, except for the FWI issue.

I am not using "NFC Reader Library" in this project. Because I could not supply the necessary components to be able to use the library in question. (3rd party problems with the import process in my country).

I am currently doing research to understand the working principle of the system. So that I will be able to use the PN5180 with different devices (host).

I theoretically understood the relationship between FWI (Frame Wait Integer) and FWT (Frame Wait Time) and their meaning.

But at the moment I have not yet figured out how to implement this into my source code (any help is welcome). If I succeed, I will know if the only cause of my problem is FWI related.

If I can implement FWI in my source code correctly and my problem is solved, your answer will be enough for me.

In any case, since you cleared my doubts about FWI, I went one step further.

Thanks!

0 Kudos
191 Views
AlexanderB
NXP Employee
NXP Employee

Hi @EkArge ,

The relation is quite easy once you understood it. You always will get the integer within the ATS but what you, most probably, need for your timer is the actual FWT (Frame Waiting Time). Which is calculated as follows: FWT = (256 * 16/fc) * 2 ^ FWI

So at your EOF (End of Frame) you start the FWT timer. The external tag must answer within this time. If it does not you either have a receiver problem or the tag is really not answering within time. For actual Tags this is very very rarely the case. If it is some external card emulator this is another story. Here it often is bad implementation. 

After the timer elapsed your point of view is that the PICC didn't send. You issue a NACK to request resending of the last frame. 

All that is very well explained at Annex B of the ISO/IEC 14443-4 specification. 

A proper implementation of PCB (Protocol Control Byte) with its I-Frames, R-Frames and S-Frames is crucial. I highly recommend, in case you didn't do it already, to get familiar with it and its way of working. Also a WTX (waiting time extension) is important to be implemented correctly. Those you will encounter most if your target is a mobile phone.

Best regards,
Alexander

 

171 Views
EkArge
Contributor II

Thanks for your answer.
I haven't had a chance to adapt the information for my source code yet. But I realized that this information would solve my problem.

0 Kudos
270 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi EkArge:

 

After a RATS/ATS exchange, the tag is in Layer-4 and you have to use the ISO-DEP protocol for communication.

 

Regards

Daniel

 

 

251 Views
EkArge
Contributor II

Thank you very much for your reply, Mr. Daniel.
I have already implemented the ISO-DEP (ISO-14443-4) protocol as follows. Please indicate if you see a missing or error?

( Device I use: PN5180, All configuration operations are for an EMV contactless card.)

1- RATS sent. ->( 0xE0, 0x80). (0x80 = FSD + CID)

2- ATS received. <- ( FWI, SFGI, FSDI etc. and historical bytes)

3- PPS sent. -> (0xD0, 0x11,0x00). ( 0xD0 = D + CID , 0x11=PPS1 + 1 , 0x00= DSI + DRI )

4- PPS Response received.<- 0xD0

5- I-bloc created. -> as 0x02. ( No CID & NAD, no chaining)

6- APDU was created. -> (0x00,0xA4,0x04,0x00,Lc,PPSE_bytes,Le)

7- I-bloc code + APDU is wrapped and sent ( CRC calculation is on). -> (0x02, {APDU})

8- Response buffer read. <- 0xFFs only.

IMPORTANT NOTE: I am not manually calculating a value for the "Epilogue Field" EDC for the "Block Format" in the attached picture. Because I'm assuming: EDC bytes (if CRC calculation is turned on) are automatically generated by PN5180 and automatically added to the end of the sequence in step-7. (?)
Is this true ? Or do I have to manually generate the EDC bytes and add them to the array?

In addition, do I need to configure according to the FWI and SFGI information that comes with the ATS?

Thanks.

nxpSoru.png

Tags (5)
0 Kudos