User's Manual
Table Of Contents
- 1. Introduction
- The PN7150 architecture overview
- 2. NCI Overview
- 3. DH interface
- 5. Initialization & Operation configuration
- 6. Reader/Writer Mode
- 6.1 T1T, T2T, MIFARE Ultralight, MIFARE Classic and MIFARE Plus tags
- 6.1.1 Access through the [NCI] Frame RF Interface
- 6.1.2 [PN7150-NCI] extension: TAG-CMD Interface
- 6.1.3 [PN7150-NCI] extension: Payload structure of the TAG-CMD RF Interface
- 6.1.4 [PN7150-NCI] extension: REQs & RSPs rules
- 6.1.5 [PN7150-NCI] extension: List of REQs & RSPs
- 6.1.6 [PN7150-NCI] extension: raw data exchange REQs & RSPs
- 6.1.7 [PN7150-NCI] extension: T2T & MFU REQs & RSPs
- 6.1.8 [PN7150-NCI] extension: MIFARE Classic REQs & RSPs
- 6.1.9 Access through the TAG-CMD RF Interface
- 6.2 T3T tag
- 6.3 T4T & ISO-DEP Tags/Cards
- 6.3.1 Access through the Frame RF Interface
- 6.3.2 Access through the ISO-DEP RF Interface
- 6.3.3 [PN7150-NCI] extension: Presence check Command/Response
- 6.3.4 [PN7150-NCI] extension: S-Block Command/Response
- 6.3.5 [PN7150-NCI] extension: WTX notification
- 6.3.6 [PN7150-NCI] extension: Higher bit rates in Poll NFC-A & NFC-B
- 6.4 [PN7150-NCI] extension: 15693 & I-Code tags
- 6.5 [PN7150-NCI] extension: KOVIO tags
- 6.1 T1T, T2T, MIFARE Ultralight, MIFARE Classic and MIFARE Plus tags
- 7. Card Emulation Mode
- 8. P2P Initiator & Target Mode
- 9. RF Discovery Management
- 9.1 RF Discovery functionalities
- 9.2 NFC FORUM Profile as defined in [NCI]
- 9.3 [PN7150-NCI] extension: additional technologies not yet supported by the NFC FORUM
- 9.4 [PN7150-NCI] extension: Low Power Card Detector (LPCD) Mode
- 9.5 [PN7150-NCI] extension: EMVCo Profile in Poll & Listen Modes
- 9.6 [PN7150-NCI] extension: Power optimization
- 10. Configurations
- 11. Test Mode
- 12. PN7150 Practical approach
U
M10936
P
N7150 User Manual
UM
10936 All information provided in this document is subject to legal disclaimers.
U
ser manual
CO
MPANY PUBLIC
Rev. 2.0 — 6 November 2020
348120
81 of 127
WUPA
1 NFC-A Card
=> Response
WUPB
No NFC-B Card
=> no response
WUPA
1 NFC-A Card
=> Response
Anticoll
+ Select
Payment
transaction
proceeds
1xNFC-A Card in the Field, No NFC-B Card
NFCC = PCD
HLTA
F
ig 43. EMVCo polling with NFC-A card in the field
!
I
n PN7150 the Low Power Card Detector is automatically disabled when the
EMVCo profile is enabled, since these 2 features are conflicting if
simultaneously enabled.
9
.5.1.2 Notification for RF technology collision
When the EMVCo polling loop profile is activated, PN7150 will activate the ISO-DEP RF
Interface through RF_INTF_ACTIVATED_NTF only when there is 1 single card in the field,
whatever the technology (NFC-A or NFC-B).
When PN7150 detects a collision on RF (either in one technology or between
technologies), it will report a special Status in the CORE_GENERIC_ERROR_NTF:
STATUS_EMVCo_PCD_COLLISION. The current state will remain RFST_DISCOVERY,
as graphically described in Fig 35. The identifier of this proprietary Status is defined in
→0.Note that if the cards remain in the RF Field, PN7150 will keep sending the
CORE_GENERIC_ERROR_NTF with status STATUS_EMVCo_PCD_COLLISION at
each polling loop: this can be used as a presence check mechanism.
When the EMVCo profile for Poll Mode is activated and PN7150 has detected a single
PICC (i.e. no collision) but it is unable to properly activate this PICC, then PN7150 will
send a CORE_GENERIC_ERROR_NTF with status
DISCOVERY_TARGET_ACTIVATION_FAILED as defined in [NCI].
9.5.1.3 Modification of the NCI RF State Machine in case of failure during data exchange
When the EMVCo profile for Poll Mode is activated, the PN7150 has to comply with tight
timings verified during the EMVCo PCD certification. In case the RF link with the PICC is
broken, the regular way to behave according to NCI is that the PN7150 will detect a time-
out or an unrecoverable protocol error and send then a
CORE_INTERFACE_ERROR_NTF with the appropriate status. It is then up to the DH to
stop the RF Discovery with RF_DEACTIVATE_CMD(IDLE) and to restart the RF Discovery
with RF_DISCOVER_CMD. Unfortunately, the time required to execute this sequence is
highly dependent on the DH latency and it is often not possible to match the timings
expected and checked by the EMVCo PCD certification.
To solve this issue, NXP has decided to add a transition from the RFST_POLL_ACTIVE
to RFST_DISCOVERY, triggered by the sending of the