NFC中的主题 Re: Where should RfReset be inserted within EMVCo CL1 loopback

Where should RfReset be inserted within EMVCo CL1 loopback

deniscollis — Fri, 18 May 2018 18:28:42 GMT

Reference: EMVCo PCD Analogue Test Bench and Test Case Requirements Version 2.6b,

- page 74, Section 8.3. Preliminary Set-ups
- page 91, Section 8.8.1.3 TAB113.z00 Verifying the PCD Operating Field Resetting

My contactless card reader recently failed test TAB113, as per reference b, above. The test laboratory said they could not detect the RF-Reset within the loopback. I challenged this as I believed this test case simply required manual invocation of a carrier reset by the operator.

They rebuffed that they use "loopback" mode for ALL the Type Approval test cases, as per reference a, above.

On reviewing the NXP code, and some other alternates too, I see that there is only one 25ms RF reset, EmvcoRfReset(25) when exiting the loopback on an End_Of_Test_Analog (0x72) from the PICC. Obviously this was not detected at all by the test bench.

Where, then, should an additional RF Reset be inserted?

Re: Where should RfReset be inserted within EMVCo CL1 loopback

Kan_Li — Thu, 24 May 2018 06:47:21 GMT

Hi Denis,

What is your contactless card reader? Which example project was running in the test TAB113? Was it NfcrdlibEx7_EMVCo_Polling? Please kindly clarify.

Thanks for your patience!

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Where should RfReset be inserted within EMVCo CL1 loopback

deniscollis — Thu, 24 May 2018 16:53:20 GMT

Hi Kan,

It's a K81 + PN5180, but we're using a proprietary CL1 library. The laboratory have subsequently informed us that the reader was performing within EMVCo specifications. But the test bench timed out too soon (before the end of the final carrier reset in the polling procedure), and therefore was unable to detect the reset, which gave a false failure. We've since reduced reset duration, and the test now passes.

Thanks,

Denis