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
22 of 127
!
T
he I²C fragmentation implemented on PN7150 requires that the DH waits until
it has received a Control Message of type Response in response to a Control
Message of type Command before it can send any Data Message.
The DH also has to wait until it has received a Credit Notification to release the
credit consumed by a previous Data Message it has sent, before it can send a
new Control Message of type Command.
3.
6.1 Description of the I²C fragmentation:
I
f the DH has limited capabilities to transport Frames of Bytes over I²C (so below the
maximum frame size of an NCI packet which is equal to 258 Bytes), it SHALL send the
NCI packet into several fragments, according to the following rules:
• The fragment size has to be an integer multiple of 4 Bytes (excluding the Slave
Address Byte required by the I²C protocol).
• The minimum fragment size supported by the DH has to be long enough to transport
the following sequence of commands, which is necessary to enable the feature by
setting bit b4 in the IRQ_POLARITY_CFG parameter (see →10.1):
- CORE_RESET_CMD
- CORE_INIT_CMD
- NCI_PROPRIETARY_ACT_CMD
- CORE_SET_CONFIG_CMD
• To implement a flow control mechanism, the DH has to follow the following sequence:
1. The DH sends a first fragment of an NCI data packet.
2. The DH waits for WaitTime = 500µs
3. The DH writes the [Address & R/Wn] Byte over the I²C bus; it has then to
check the I²C ACK bit generated by PN7150:
a. If the ACK bit is not set, this means that PN7150 is still processing
the previous fragment of the NCI packet and it is not yet ready to
receive the next fragment. The DH has to wait for an additional
WaitTime, moving back to step 2.
b. If the ACK bit is set, the DH can move to step 4.
4. The DH transmits the next Fragment
5. If the whole NCI packet has not yet been transmitted, the DH proceeds to
step 2 with another fragment. If the whole NCI packet has been transmitted,
the sequence is stopped.