NXP Semiconductors PN722X Controller Development Kit User Manual
- June 17, 2024
- NXP Semiconductors
Table of Contents
PN722X Controller Development Kit
“`html
Product Information
Specifications:
- Product Name: PN722X NFC Controller
- Manufacturer: NXP Semiconductors
- Interfaces: NFC Forum, EMVCo Mode
- RF Output: Up to 2.0 W
- Receiver Sensitivity: High
- Middleware: NCI 2.2 compliant
Product Usage Instructions:
1. Overview:
The PN722X NFC controller is designed for Android-based designs
for payment, POS, and mPOS terminal applications. It offers
superior RF performance and supports NFC Forum and EMVCo Mode.
2. Features:
- High RF output for robust solution in payment terminals
- EMVCo 3.x analog compliancy even in metal environments
- NCI 2.2 compliant middleware for digital compliancy
- Support for contact interface using TDA8035
3. Installation:
Ensure proper connections are made according to the device
specifications and guidelines provided in the user manual.
4. Configuration:
Configure the PN722X NFC controller based on the requirements of
your application to ensure optimal performance.
5. Usage:
Utilize the PN722X NFC controller for NFC operations in your
Android-based devices for payment processing and other related
activities.
Frequently Asked Questions (FAQ):
Q: What is the maximum RF output of the PN722X NFC
controller?
A: The PN722X NFC controller supports a maximum RF output of up
to 2.0 W.
Q: What is the middleware supported by the PN722X NFC
controller?
A: The PN722X NFC controller is supported by an NCI 2.2
compliant middleware.
“`
UM11810
PN722X NFC controller
Rev. 1 — 2 February 2024
User manual
Document information
Information
Content
Keywords
PN722X NFCC, NFC, NFCC, NCI
Abstract
This is a user manual for the PN722X NFCC IC. The aim of this document is to describe the PN722X NFCC interfaces, modes of operation and possible configurations (NFCC view).
NXP Semiconductors
UM11810
PN722X NFC controller
1 Introduction
The PN722X is a NFC controller product that provides the most advanced
generations of NXP Semiconductors NFC controller. The PN722X family is
targeting Android based designs for PAYMENT, POS & mPOS TERMINAL applications.
The PN722X solution defines the state of the art in terms of NFC superior RF
performance with support for both NFC Forum and EMVCo Mode with high RF output
(up to 2.0 W) and high receiver sensitivity is a robust solution for payment
terminals. This NFC controller allows to achieve EMVCo 3.x analog compliancy
even in metal environment and for through-display applications.
As an product with NCI 2.2 interface, the PN7220 supports a secure switching
between NFC Forum and EMVCo modes, allowing the fast development of terminals
which need to support NFC Forum applications as well as EMVCo payment. A
dedicated pre-configuration of the RF settings for each EMVCo and NFC Forum
mode simplifies the design and takes care of the dedicated RF requirements of
each mode without the need of frequent re-configurations of the RF
functionality from a host. The internal processing of the device had been
optimized for fast NCI data transfer with low latency, to meet EMVCo
application timing requirements.
The PN722X is supported by an NCI 2.2 compliant middleware which allows to
achieve both EMVCo3.x digital compliancy as well as NFC Forum compliancy.
PN722X products provide support to connect to contact interface using TDA8035
which is the cost efficient integrated contact smart card reader IC.
Additionally, the PN7221 NFCC supports all features of PN7220 plus “Enhanced
Contactless Polling” (ECP) by Apple. Note, that the ECP feature is available
after formal authorization from Apple only.
The user manual describes the software interfaces (API), based on the NFC
Forum standard, NCI, referencing the version 2.2.
As this document assumes pre-knowledge on certain technologies, check Section
3 to find the appropriate documentation.
For further information, refer to the PN722X data sheet [PN722X_DS].
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
2 / 141
NXP Semiconductors
2 Abbreviations
Table 1.Abbreviations Abbreviation CE CITO COTI CLIF COTS CPoC CT DH DH-NFCEE
DPC GID HDLL LPCD MT NCI NFC NFCC NFCEE OID PRBS PBF RF RFU RSSI
Definition Card emulation controller input / target output (former MISO) controller output / target input (former MOSI) contactless interface commercially of the self contactless payment on COTS contact device host NFC execution environment running on the DH dynamic power control group identifier host data link layer low power card detector message type NFC controller interface near field communication NFC controller NFC execution environment opcode identifier pseudo random binary sequence packet boundary flag radio frequency reserved for future use received signal strength indication
UM11810
PN722X NFC controller
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
3 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
3 References
PN722X refers to PN7220 [PN722X_DS] PN7220 data sheet [NCI] NFC Forum NFC
controller Interface, version 2.2 [NCI_Table1] Status Codes table: table 129
in [NCI] [NCI_Table2] RF technologies table: table 130 in [NCI] [NCI_Table3]
RF Technology and Mode table: table 131 in [NCI] [NCI_Table4] Bit Rates table:
table 132 in [NCI] [NCI_Table5] RF protocols table: table 133 in [NCI]
[NCI_Table6] RF Interfaces table: table 134 in [NCI] [NCI_Table8] Config.
Parameters table: table 138 in [NCI] [NCI_Table9] CORE_RESET_NTF table: table
5 in [NCI] [NCI_Chap2] State Machine: chapter 5.2 in [NCI] [DIGITAL] NFC Forum
Digital Protocol Specification version 2.3 [ACTIVITY] NFC Forum Activity
Specification version 2.2 [7816-4] ISO/IEC 7816-4 [14443-4] ISO/IEC 14443-4
2018-07 CTS configuration part of NFC Cockpit, https://www.nxp.com/products
/:NFC-COCKPIT
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
4 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
4 PN722X architecture overview
The PN722X NFC controller simplified architecture view is depicted in Figure
1:
· The top part describes the Device Host architecture with Higher Layer Driver
(i.e. Middleware stack) hosting: the user applications (Reader/Writer, Card
Emulation in the DH-NFCEE) the NCI driver and the transport layer driver.
· In addition to DH-NFCEE, PN722X supports NFCEEs for CT support. · The middle
part describes PN722X. PN722X is connected to the DH through an I2C physical
interface. The
PN722X NFCC firmware supports the NCI specification 2.2. PN722X supports NCI
specification [NCI] and additional extensions. DH uses the NFCEE Interface to
encapsulate the ISO 7816-4 APDU and sent to NFCC, allowing the communication
with Contact Interface card connected over TDA 8035.
· The Bottom part of the figure contains the RF antenna connected to the
PN722X NFCC, which can communicate over RF with a tag (card), a reader/writer
or another NFC device. The PN722X NFCC firmware is stored both in ROM and in
FLASH: This means that it can be updated when required. The PN722X NFCC User
Data is stored in RAM and in FLASH. The data stored in FLASH can also be
updated, after updating the data stored in FLASH, a POR is required to use
these updated data. NXP provides a download mechanism for the binary content
of the firmware stored in FLASH and the user data. All PN722X variants work in
two types of Device Host configuration: Single host device (HD) configuration:
· HIF1-I2C interface connects PN722X to the device host. For contactless
operation, NFC Forum and EMVCo modes of operation are supported. The host
device controls the PN722X mode of operation by toggling Mode_Switch_GPI as
described in Table 8. Dual host device configuration:
· PN722X NFCC can work in multi-host configuration, with a main and a target
host. The main host acts as controller.
· For contactless operation, the main host supports NFC Forum mode, and the
target host supports EMVCo mode.
· The main host device controls PN722X mode of operation, and the target host
EMVCo mode of operation. Once the EMVCo operation is completed, the Main Host
takes back the control to work in NFC Forum mode of operation.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
5 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
DH-NFCEE
Reader Card Contact / Writer Emulation Card
NCI driver
Transport layer driver
Device Host
HIF1-I2C
NFCC
Transport Layer FW
NCI
CT
firmware
FW
TDA 8035 1
I/O AUX
TDA 8035 2
RF
TDA 8035
3
Antenna
TAG or
Card
Figure 1.PN722X system architecture with Single Host
Reader/Writer
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
6 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
MAIN DH-NFCEE
Reader Card Contact / Writer Emulation Card
NCI driver
Transport layer driver
HIF2-I2C
Main Device
Host
TARGET DH-NFCEE
Reader / Writer
NCI driver
Target
Transport layer Device
driver
Host
HIF1-SPI
NFCC
Transport Layer FW
NCI
CT
firmware
FW
I/O AUX
RF
Antenna
TDA 8035 1
TDA 8035 2
TDA 8035 3
TAG or
Card
Figure 2.PN722X system architecture with dual host
Reader/Writer
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
7 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
4.1 Reader/writer operation in poll mode
4.1.1 Reader/writer hosted by the Main DH The Reader/Writer application
running on the Main DH is accessing a remote contactless Tag/Card, through the
PN722X NFCC.
DH-NFCEE
Reader Card Contact / Writer Emulation Card
NCI driver
Transport layer driver
HIF1-I2C
Device Host
NFCC
Transport Layer FW
NCI firmware
CT FW
I/O AUX
RF
TDA 8035 1
TDA 8035 2
TDA 8035 3
Antenna
TAG or
Card
Figure 3.Reader/Writer hosted by the Main DH
Reader/Writer
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
8 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
4.1.2 Reader/Writer hosted by the Target 2 DH
The Reader/Writer application running on the Target DH is accessing a remote
contactless Tag/Card, through the PN722X NFCC.
MAIN DH-NFCEE
Reader Card Contact / Writer Emulation Card
NCI driver
Transport layer driver
HIF2-I2C
Main Device
Host
TARGET DH-NFCEE
Reader / Writer
NCI driver
Target
Transport layer Device
driver
Host
HIF1-SPI
NFCC
Transport Layer FW
NCI
CT
firmware
FW
I/O AUX
TDA 8035 1
TDA 8035 2
RF
TDA 8035
3
Antenna
TAG or
Card
Figure 4.Reader/Writer hosted by the Target DH
Reader/Writer
2 The master/slave replacement into controller/target in this document follows the recommendation of the NXP – I2C standards organization.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
9 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
4.2 Card emulation operation in listen mode
4.2.1 Card emulated by the Main DH-NFCEE An external Reader/Writer accesses
the Main DH-NFCEE by emulating a contactless card through the PN722X NFCC.
PN7220 and PN7221 do not support Card emulation.
MAIN DH-NFCEE
Reader / Writer
Card Emulation
Contact Card
NCI driver
Transport layer driver
Main Device Host
HIF2-I2C
NFCC
Transport Layer FW
NCI firmware
TARGET DH-NFCEE
Reader / Writer
NCI driver
Transport layer driver
Target Device Host
HIF1-SPI
CT
I/O AUX
FW
TDA 8035 1
TDA 8035 2
RF
TDA 8035
3
Antenna
TAG or
Card
Figure 5.Card emulated by the Main DH-NFCEE
Reader/Writer
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
10 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
4.3 Combined modes of operation
The PN722X NFCC firmware combines the basic modes of operation described in
Section 4.1 and Section 4.2, using the RF Discovery as defined in [NCI]. Since
the PN722X NFCC offers more features than currently addressed in [NCI], NXP
has defined some proprietary extensions.
The principle used to combine the various modes of operation is to build a
cyclic activity, which sequentially activates various modes of operation:
1. Start a Polling sequence, to look for a remote Tag/Card. If several
technologies are enabled by the DH, PN722X NFCC polls sequentially for all the
enabled technologies.
2. If nothing was detected, enter a Listening sequence, to potentially be
activated as a Card emulator by an external Reader/Writer.
3. If nothing happens after a programmable timeout, switch back to Poll Mode
in step 1.
Figure 6 illustrates the cyclic activity specified in [ACTIVITY], where
technologies NFC-A, NFC-B, NFC-F and NFC-V have been activated in Poll Mode.
Listening phase
NFC-A NFC-B NFC-F NFC-V
Polling phase
Figure 6.RF discovery NFC Forum profile
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
11 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Note: When the PN722X NFCC is polling in Reader/Writer operation, it can consume a significant amount of current (depending on the antenna characteristics: >100mA). This applies for the four polling phases shown in Figure 6, and is because the PN722X NFCC has to generate the RF carrier (13.56 MHz). But during the Listen phase, the PN722X NFCC current consumption is reduced to few 10’s of µA, since PN722X is waiting for the detection of an externally generated RF carrier (standby power mode). Figure 7 illustrates the cyclic RF Discovery where polling is enabled only for NFC-A and NFC-B, for simplicity.
Listen / Pause Phase
RF Field > 100 mA
Poll Phase
One complete RF Discovery Loop Listen / Pause Phase
Poll A Poll B
Current consumption
< 100 µA
~20ms
~350ms
Poll Phase
Listen / Pause Phase
Poll A Poll B
Figure 7.Power consumption during RF discovery
In a typical set-up, the polling phase is approximately 50 ms long while the
listening phase is approximately 350 ms long (this set-up is configured thanks
to the NCI parameter called TOTAL_DURATION).
This average consumption can be further optimized, using PN722X NFCC Low-Power
Card Detector (LPCD) feature. Note: [NCI] defines the TOTAL_DURATION of the
discovery period independently of the reader phases applied. To simplify the
implementation for the PN722X NFCC, a timer is applied only during the
Listen/pause phase. So, depending on the polling phase configuration (one
technology or more), the total duration varies.
For further details on the RF discovery activity, refer to Section 12.
4.4 DH access to CT Card over TDA
CT support with PN722X uses NFCEE interface defined by NCI Specification.
NXP commonly names this mode of communication the “CT mode”, since the
communication is to interact with Contact Cards (for example SAM, Contact
Payment Card). FIGURE illustrates the data exchange flow between the DH and
the CT Card over NFCC via TDA. This mode is useful for two different use
cases:
· The application running on the DH wants to interact with a SAM connected
over TDA to perform Secure Key Store or Crypto Operations. A typical example
is a DH application that encrypts the Data using Crypto engine on SAM and then
communicates the data when a contactless payment takes place.
· The application running on the DH wants to accept any Contact Payment Card
that can be inserted dynamically and perform Payment transaction.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
12 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
MAIN DH-NFCEE
Reader Card Contact / Writer Emulation Card
NCI driver
Transport layer driver
HIF2-I2C
Main Device
Host
TARGET DH-NFCEE
Reader / Writer
NCI driver
Target
Transport layer Device
driver
Host
HIF1-SPI
NFCC
Transport Layer FW
NCI
CT
firmware
FW
I/O AUX
RF
Antenna
TDA 8035 1
TDA 8035 2
TDA 8035 3
TAG or
Card
Reader/Writer
Figure 8.Exchanges between the DH and the CT Card over TDA
To start CT activation for the two use cases, the DH should send
NFCEE_DISCOVER_CMD to check the presence of any CT Card, and notify NFCC with
NFCEE_DISCOVER_NTF. The NFCC does not check any activity related to card
presence and/or card removal without NFCEE_DISCOVER_NTF from the DH.
The first use case works when SAM is connected before DH boot process and
during boot. SAM cards are initialized and the information is conveyed as
notifications to DH upon receiving NFCEE_DISCOVER_CMD.
In the second use case, the contact payment card can be inserted dynamically.
After the activation and identification of payment card, the PN722X sends an
event to the DH only upon receiving NFCEE_DISCOVER_CMD.
For both use cases, the general mechanism used to communicate with the CT
Cards over TDA from the DH is an ISO7816-4 APDU wrapped using a proprietary
layer running on the DH on top of NCI Transport layer. DH needs to generate
ISO7816-4 APDU packets, which are then encapsulated in NCI data packets and
forwarded to the NFCC. The NFCC forwards the ISO7816-4 APDU packets to the
appropriate CT Card over TDA. A similar mechanism is used for the
communication from a CT Card to the DH.
For further details on the CT Card Management, refer to Section 8.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
13 / 141
NXP Semiconductors
5 NCI overview
The section gives an overview of the key points of the [NCI] specification.
5.1 NCI components
NCI modules (…)
UM11810
PN722X NFC controller
R F Discovery
R F Interfaces
NFCEE Discovery
NFCEE Interfaces
Figure 9.NCI components
Transport Mapping
Transport
NCI Core
Transport
Mapping
(…)
Transport
Transport Mapping
Transport
5.1.1 NCI modules
NCI modules are built on top of the functionality provided by the NCI Core.
Each module provides a welldefined functionality to the DH. NCI modules
provide the functionality to configure the NFCC and to discover and
communicate with Remote NFC Endpoints or with local NFCEEs.
Some NCI modules are mandatory parts of an NCI implementation, others are
optional. There can also be dependencies between NCI modules in the sense that
a module may only be useful if there are other modules implemented as well.
For example all modules that deal with communication with a Remote NFC
Endpoint (the RF Interface modules) depend on the RF Discovery to be present.
5.1.2 NCI core
The NCI core defines the basic functionality of the communication between a
Device Host (DH) and an NFC controller (NFCC). This enables Control Message
(Command, Response, and Notification) and Data Message exchange between an
NFCC and a DH.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
14 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.1.3 Transport mappings Transport mappings define how the NCI messaging is
mapped to an underlying NCI transport, which is a physical connection (and
optional associated protocol) between the DH and the NFCC. Each transport
mapping is associated with a specific NCI transport.
5.2 NCI concepts
NFC Forum Device
DH
Control Messages RF Interface
Data Messages Control Messages NFCEE Interface
Data Messages Control Messages
NCI
NFCC
NFCEE Protocol
NFCEE
RF Protocol
Figure 10.NCI concepts
Remote NFC Endpoint
5.2.1 Control messages
A DH uses NCI Control messages to control and configure an NFCC. Control
Messages consist of Commands, Responses, and Notifications. Commands are only
allowed to be sent in the direction from DH to NFCC, Responses and
Notifications are only allowed in the other direction. Control Messages are
transmitted in NCI Control Packets, NCI supports segmentation of Control
Messages into multiple Packets.
The NCI Core defines a basic set of Control Messages, for example to set and
retrieve NFCC configuration parameters. NCI Modules can define additional
Control Messages.
DH
NFCC
Command Response
Figure 11.Control Message Exchange
Notification
Control Message Exchange
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
15 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.2.2 Data messages
Data messages are used to transport data to either a Remote NFC Endpoint
(named RF Communication in NCI) or to an NFCEE (named NFCEE Communication).
NCI defines Data Packets enabling the segmentation of Data Messages into
multiple Packets.
Data Messages can only be exchanged in the context of a Logical Connection. As
a result, a Logical Connection must be established before any Data Message is
sent. One Logical Connection, the Static RF Connection, is always established
during initialization of NCI. The Static RF Connection is dedicated for RF
Communication. Additional Logical Connections can be created for RF and/or
NFCEE Communication.
Since [NCI2.2], another logical connection, the Static HCI Connection, is
always established during initialization of NCI. But PN722X does not create
this Static HCI Connection for NFCEE communicating to CT device.
Logical Connections provide the flow control for Data Messages from DH to NFCC
(Figure 12).
DH
NFCC
Data
DH
NFCC
Figure 12.Data message exchange
Data
Data Message Exchange
5.2.3 Interfaces
An NCI module might contain a single Interface. Each Interface defines how a
DH can communicate via NCI with a Remote NFC Endpoint or NFCEE. Each Interface
is defined to support specific protocols and can only be used for those
protocols (most Interfaces support exactly one protocol). NCI defines two
types of Interfaces: RF Interfaces and NFCEE Interfaces.
Protocols that are used to communicate with a Remote NFC Endpoint are called
RF Protocols. Protocols that are used to communicate with an NFCEE are called
NFCEE Protocols.
An NFCEE Interface has a one-to-one relationship to an NFCEE Protocol.
However, there might be multiple RF Interfaces for one RF Protocol. The
multiple RF Interfaces allow NCI to support different splits of the protocol
implementation between the NFCC and DH. An NCI implementation on an NFCC
includes the RF Interfaces that match the functionality implemented on the
NFCC.
Interfaces need to be activated before they can be used and deactivated when
they are no longer used.
An Interface can define its own configuration parameters and Control Messages.
But, most important, it defines both the mapping of the Data Message to the
payload of the respective RF or NFCEE Protocol and, in the case of RF
Communication, whether the Static RF Connection and/or Dynamic Logical
Connections are used to exchange those Data Messages between the DH and the
NFCC.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
16 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.2.4 RF interface extensions
An RF Interface Extension adds a specific, clearly defined set of functions to
one or more RF Interfaces. Each RF Interface Extension defines which RF
Interfaces it can extend.
The availability of an RF Interface Extension is bound to the time at which
one of these RF Interfaces is activated. The availability can additionally
depend on other conditions, e.g. the protocol being currently used in the NFC
RF Communication. If an RF Interface is active, available RF Interface
Extensions can be started and stopped by the DH. RF Interface Extensions are
never started automatically but are stopped automatically when the RF
Interface is deactivated. Each RF Interface Extension defines the Control
Messages for starting and stopping its functionality.
While started, an RF Interface Extension can overrule definitions of the
active RF Interface to provide its own functionality. RF Interface Extensions
can define the interface’s own configuration parameters and Control Messages.
They can also provide a format for Data Messages that is different from the
one defined by the RF Interface. However, RF Interface Extensions cannot
overrule the deactivation behavior of the active Interface.
For a given RF Interface there can be multiple RF Interface Extensions. It is
possible to start multiple RF Interface Extensions at the same time, as long
as they are not mutually exclusive. Each RF Interface Extension defines which
other RF Interface Extension it can be used with.
However, the extension process cannot be compounded: RF Interface Extensions
are not intended to extend the functionality of other RF Interface Extensions.
5.2.5 RF communication
RF Communication is started by configuring and running the RF Discovery
process. The RF Discovery is an NCI module that discovers and enumerates
Remote NFC Endpoints.
For each Remote NFC Endpoint, the RF Discovery Process provides the DH with
the Remote NFC Endpoint information that was gathered during the RF Discovery
Process. This information includes the RF Protocol that is used to communicate
with the Remote NFC Endpoint. During RF discovery configuration the DH sets up
a mapping that associates an RF Interface for each RF Protocol. If only a
single Remote NFC Endpoint is detected during a discovery cycle, the RF
Interface for this Endpoint is automatically activated. If there are multiple
Remote NFC Endpoints detected in Poll Mode, the DH can select the Endpoint it
wants to communicate with. This selection also triggers activation of the
mapped Interface.
After an RF Interface has been activated, the DH can communicate with the
Remote NFC Endpoint using the activated RF Interface. An activated RF
Interface can be deactivated by either the DH or the NFCC (e.g., on behalf of
the Remote NFC Endpoint). However, each RF Interface can define which of those
methods are allowed. The deactivation options vary, depending on which part of
the protocol stack is executed on the DH. For example, if a protocol command
to tear down the communication is handled on the DH, the DH will deactivate
the RF Interface. If such a command is handled on the NFCC, the NFCC will
deactivate the Interface.
This specification describes the possible Control Message sequences for RF
Communication in the form of a state machine.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
17 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.2.6 NFCEE communication
The DH can learn about the NFCEEs connected to the NFCC by employing the NFCEE
Discovery module. During NFCEE Discovery, the NFCC assigns an identifier for
each NFCEE. When the DH wants to communicate with an NFCEE, it opens a Logical
Connection to the NFCEE that includes the corresponding identifier and
specifies the NFCEE Protocol to be used.
Opening a Logical Connection to an NFCEE automatically activates the NFCEE
Interface associated with the protocol specified. As there is always a one-to-
one relationship between an NFCEE Protocol and Interface, there is no mapping
step required (unlike RF Interface activation).
After the Interface has been activated, the DH can communicate with the NFCEE
using the activated Interface.
Closing the connection to an NFCEE Interface deactivates the NFCEE Interface.
NCI also includes functionality to allow the DH to enable or disable the
communication between an NFCEE and the NFCC.
5.2.7 Identifiers
NCI uses different identifiers for Remote NFC Endpoints and NFCEEs. These
identifiers are dynamically assigned by the NFCC. The DH learns them in the
contexts of RF Discovery and NFCEE Discovery. The identifiers for Remote NFC
Endpoints are called RF Discovery IDs. They usually have a short lifetime as
they are only valid for the time the DH wants to be able to communicate with
the Remote NFC Endpoint. In contrast, the identifiers for NFCEEs have a longer
lifetime, since NFCEEs usually are not frequently added to or removed from an
NFC Forum Device. The identifiers for NFCEEs are called “NFCEE IDs”. There is
one reserved and static NFCEE ID, value 0, which represents the DH-NFCEE.
Logical Connections take a third type of identifier, Destination Type, as a
first parameter to identify the destination for the data. Depending on the
Destination Type, there can be a second parameter for identifying the data
destination. For example, if the Destination Type is `Remote NFC Endpoint’,
the second parameter will be an RF Discovery ID.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
18 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.3 NCI packet format 5.3.1 Common packet header
All packets have a common header, consisting of an MT field and a Packet
Boundary Flag (PBF) field:
3 ( bits )
MT
1
P B F Octet 0
Information Octet 1 – N
Figure 13.NCI core packet format
· Message Type (MT)
The MT field indicates the contents of the Packet and SHALL be a 3-bit field
containing one of the values listed in Table 1, below. The content of the
Information field is dependent on the value of the MT field. The receiver of
an MT designated as RFU SHALL silently discard the packet.
Table 2.MT values
MT
Description
000b
Data Packet
001b
Control Packet – Command Message as a payload
010b
Control Packet – Response Message as a payload
011b
Control Packet Notification Message as a payload
100b-111b RFU
· Packet Boundary Flag (PBF)
The Packet Boundary Flag (PBF) is used for Segmentation and Reassembly and
SHALL be a 1-bit field containing one of the values listed in [NCI]
specification.
Table 3.PBF Value
PBF
Description
0b
The Packet contains a complete Message, or the Packet contains the last segment of a segmented Message
1b
The Packet contains a segment of a Message which is not the last segment.
The following rules apply to the PBF flag in Packets:
· If the Packet contains a complete Message, the PBF SHALL be set to 0b. · If
the Packet contains the last segment of a segmented Message, the PBF SHALL be
set to 0b. · If the packet does not contain the last segment of a segmented
Message, the PBF SHALL be set to 1b.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
19 / 141
NXP Semiconductors
5.3.2 Control packets Figure 14 shows the control packet structure.
UM11810
PN722X NFC controller
Figure 14.Control packet format
Each Control Packet SHALL have a 3 octet Packet Header and MAY have additional
payload for carrying a Control Message or a segment of Control Message. Note:
In the case of an `empty’ Control Message, only the Packet Header is sent.
· Message Type (MT)
Refer to Section 5.3.1 for details of the MT field.
· Packet Boundary Flag (PBF)
Refer to Section 5.3.1 for details of the PBF field.
· Group Identifier (GID)
NCI supports Commands, Responses, and Notifications which are categorized
according to their individual groups. The Group Identifier (GID) indicates the
categorization of the message and SHALL be a 4-bit field containing one of the
values listed in [NCI] specification.
All GID values not defined in [NCI] specification are RFU.
· Opcode Identifier (OID)
The opcode Identifier (OID) indicates the identification of the Control
Message and SHALL be a 6-bit field which is a unique identification of a set
of Command, Response, or Notification Messages within the group (GID). OID
values are defined along with the definition of the respective Control
Messages described in [NCI] specification.
· Payload Length (L)
The Payload Length SHALL indicate the number of octets present in the payload.
The Payload Length field SHALL be an 8-bit field containing a value from 0 to
255.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
20 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.3.3 Data packets Figure 15 shows the data packet structure.
Packet header
3
1
4
P MT B Conn ID
F
Octet 0
8 RFU Octet 1
8 Payload Length ( L )
Octet 2
L bytes Payload Octet 3 … Octet (2+L)
Figure 15.Data packet structure
Each Data Packet has a 3 octet Packet Header and may have an additional
Payload to carry a Data Message or a segment of a Data Message. Note: If a
Data Message is empty, only the Packet Header is sent.
· Message Type (MT)
Refer to Section 5.3.1 for details of the MT field.
· Packet Boundary Flag (PBF)
Refer to section Section 5.3.1 for details of the PBF field.
· Connection Identifier (Conn ID)
The Connection Identifier (Conn ID) is used to indicate the previously setup
Logical Connection to which this data belongs. The Conn ID is a 4-bit field
containing a value from 0 to 15.
· Payload Length (L)
The Payload Length field indicates the number of Payload octets present. The
Payload Length field is an 8-bit field containing a value from 0 to 255.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
21 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
5.3.4 Segmentation and reassembly
The Segmentation and Reassembly functionality SHALL be supported by both the
DH and the NFCC.
Segmentation and Reassembly of Messages SHALL be performed independently for
Control Packets and Data Packets of each Logical Connection.
Any NCI Transport Mapping is allowed to define a fixed Maximum Transmission
Unit (MTU) size in octets. If such a Mapping is defined and used, then if
either DH or NFCC must transmit a Message (either Control or Data Message)
that would generate a Packet (including Packet Header) larger than the MTU,
the Segmentation and Reassembly (SAR) feature SHALL be used on the Message.
The following rules apply to segmenting Control Messages:
· For each segment of a Control Message, the header of the Control Packet
SHALL contain the same MT, GID, and OID values.
· From DH to NFCC: The Segmentation and Reassembly feature SHALL be used when
sending a Command Message from the DH to the NFCC that would generate a
Control Packet with a payload larger than the “Max Control Packet Payload
Size” reported by the NFCC at initialization. Each segment of a Command
Message except for the last SHALL contain a payload with the length of “Max
Control Packet Payload Size”.
· From NFCC to DH: When an NFCC sends a Control Message to the DH, regardless
of the length, it MAY segment the Control Message into smaller Control Packets
if needed for internal optimization purposes.
The following rules apply to segmenting Data Messages:
· For each segment of a Data Message, the header of the Data Packet SHALL
contain the same MT and Conn ID.
· From DH to NFCC: if a Data Message payload size exceeds the max. Data Packet
Payload Size, of the connection then the Segmentation and Reassembly feature
SHALL be used on the Data Message.
· From NFCC to DH: when an NFCC sends a Data Message to the DH, regardless of
the payload length it MAY segment the Data Message into smaller Data Packets
for any internal reason, for example for transmission buffer optimization.
Note: PN722X uses modified NFCEE Discovery and Interface mechanism to
communicate with CT Card using TDA. Thereby reducing the impact on Command,
Response, and Notification changes required to be handled by DH.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
22 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6 DH interface
6.1 Overview
The PN722X supports HIF1-I2C as physical interface to connect to the Main DH
in Single Host Device Configuration and will support HIF2-I2C as physical
interface to connect to the Main DH and HIF1-SPI as physical interface to
connect to the Target DH (typically a security MCU) in Dual Host Device
Configuration.
Independent of the physical interface, the PN722X has two main modes of
operation to communicate with the DH:
1. NCI-based communications 2. HDLL-Based communications, only used when the
PN722X is triggered to enter the “download mode”, to
update its firmware.
The description of the transport layer in the next chapters is limited to NCI-
based communications. For further information on the HDLL-based
communications, please refer to chapter on PN722X NFCC encrypted secured
firmware upload mode.
6.2 HIF1 interface 6.2.1 I2C interface
6.2.1.1 Introduction
The HIF1-I2C interface of the PN722X is compliant with the [I2C] Bus
Specification, including device ID and Soft Reset. It is target-only, i.e. the
SCL signal is an input driven by the host. PN722X does not use SCL clock
stretching (i.e. maintain SCL low to pause the transmission).
iNmoptlee:mNenCtIinpgacthkeetIs2Clednrgivtherc.an be up to 258 bytes in both
directions. The DH must consider this constraint when
The PN722X HIF1-I2C interface supports standard (up to 100 kbit/s), fast-Speed
mode (up to 400 kbit/s), fastPlus mode (1 Mbit/s) and High-Speed mode (up to
3.4 Mbit/s).
The PN722X HIF1-I2C supports the 7-bit addressing mode, first 5-bits are fixed
and is decimal 40, last two bits are configurable using ADDR0 and ADDR1 pins
as per below table:
ADDR1 Pin 0 0 1 1
ADDR0 Pin 0 1 0 1
I2C Address 40 (0x28) 41 (0x29) 42 (0x2A) 43 (0x2B)
The following names are used in the document:
Table 4.HIF1-I2C pins correspondence
Bus signal name
Correspondence in PN722X
I2C1_SDA
Equivalent to pin Host Interface 1 (I2C / SPI) : I2C1_SDA in PN722X Datasheet
I2C1_SCL
Equivalent to pin Host Interface 1 (I2C / SPI) : I2C1_SCL in PN722X Datasheet
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
23 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.1.2 NCI transport mapping In the PN722X, there is no additional framing
added for I2C: an NCI packet (either data or control message, as defined in
[NCI]) is transmitted over I2C “as is”, i.e. without any additional byte (no
header, no CRC etc.).
6.2.1.3 Write sequence from the DH As the HIF1-I2C clock is controlled by the
DH, only the DH can initiate an I2C exchange. A DH write sequence always
starts with the sending of the PN722X HIF1-I2C target address followed by the
write bit (logical `0′: 0b). Then the PN722X HIF1-I2C interface sends an I2C
ACK back to the DH for each data byte written by the DH. It may send an I2C
NACK (negative acknowledge) when none of the reception buffers used by the NCI
core in the PN722X is free and also when PN722X is in standby state. If one
single byte of a complete NCI frame is NACKed by the PN722X, the DH has to
resend the complete NCI frame and not only this single byte.
SCL
I²C Start I²C Stop
SDA
I²C Slave Address NCI Header
+ R/W bit = 0b
Byte 0
NCI Header NCI Payload NCI Payload
Byte 1
Length
Byte 0
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
IRQ
Figure 16.I2C write sequence Note: If PN722X has an NCI Message ready to be
sent to the DH while it is receiving another NCI Message from the DH, the
NFC_IRQ pin is raised during the Write Sequence. This is not an error and has
to be accepted by the DH. Once the Write Sequence is completed, the DH has to
start a Read Sequence (see Section “Read sequence from the DH”).
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
24 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.1.4 Read sequence from the DH
The DH shall never initiate a spontaneous I2C read request. The DH shall wait
until it is triggered by the PN722X. To trigger the DH, the PN722X generates a
logical transition from Low to High on its IRQ pin. So after writing any NCI
command, the DH shall wait until the PN722X raises its IRQ pin. The DH can
then transmit a Read request to fetch the NCI answer from the PN722X . When
the PN722X needs to send a spontaneous notification to the DH (for instance an
RF Interface activation notification), the PN722X raises the IRQ pin and the
DH performs a normal read as described above.
A DH Read Sequence always starts by sending the PN722X HIF1-I2C Target Address
followed by the read bit (logical `1′). Then the DH I2C interface sends an ACK
back to the PN722X for each data byte received.
Figure 17 is an example where the IRQ is raised so the DH can proceed a read.
SCL
DH knows how often to Apply the clock
If the DH sends more clocks, zeros will be sent
I²C Start I²C Stop
SDA
I²C Slave Address NCI Header NCI Header NCI Payload NCI Payload
+ R/W bit = 1b
Byte 0
Byte 1
Length
Byte 0
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
IRQ
NFCC requests a transfer
Figure 17.>I2C read sequence
If NFCC requests a transfer, but DH sets R/W bit to 0b, All data has been
IRQ will remain high.
read, IRQ is reset
As indicated on the figure above, in case the PN722X requests a data transfer
by raising the NFC_IRQ1 pin and the DH tries to initiate a write sequence by
positioning the write bit to 0b, the PN722X keeps the NFC_IRQ1 active until
the DH starts a read sequence. The DH is not allowed to proceed with a write
sequence once the PN722X has set the NFC_IRQ1 pin to its active value (logical
1′ in the figure above). If PN722X has another message ready to be sent to the DH before the end of the on-going Read Sequence, the NFC_IRQ1 pin will be first deactivated at the end of the on-going Read Sequence and then reactivated to notify to the DH that a new message has to be read. If PN722X has no more data to be sent but still the controller keeps SCL line active, PN722X keeps sending dummy bytes0xFF’.
Note: IRQ in Figure 17 refers to NFC_IRQ1.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
25 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.1.5 Split mode
The PN722X supports the interruption of a frame transfer, as defined in [I2C].
This feature is only available in Read Mode; it is forbidden to use it in
Write Mode.
This can be useful in a system where the I2C bus is shared between several
peripherals: It allows the host to stop an on-going exchange, to switch to
another peripheral (with a different target address) and then to resume the
communication with the PN722X.
Another typical use case for the split mode is to have the DH reading first
the NCI packet header, to know what the Payload length is. The DH can then
allocate a buffer with an appropriate size and read the payload data to fill
this buffer. Figure 18 represents this use case.
SCL
DH can split the I²C Read transfer
I²C Start I²C Stop I²C Start I²C Stop
SDA
I²C Slave Address NCI Header NCI Header NCI Payload
+ R/W bit = 1b
Byte 0
Byte 1
Length
I²C Slave Address NCI Payload
+ R/W bit = 1b
Byte 0
NCI Payload Byte n
IRQ
Figure 18.I2C read sequence with split mode
Note: After a hardware reset (power-on reset or RSTN pin reset), NFCC is ready
to receive a frame after Tboot (see value in [PN722X _DS]). If no frame is
received during 5 seconds, NFCC boots in NCI applicative mode followed by an
entry in Active mode.
6.2.2 SPI interface
6.2.2.1 Introduction
The PN722X target-only SPI interface is compliant with the Freescale standard
(see [SPI]).
· SPI speed up to 15 Mbit/s · 8-bit data format only · Supports all 4 modes of
SPI (CPOL and CPHA) · If no data is available, the CITO line is kept idle high
(sends 0xFF bytes) · Toggling the NSS line indicates a new frame
It is restricted to half-duplex communications.
Table 5.SPI pins correspondence [1]
NSS (HIF1)
Equivalent to pin I2CADR0_SPINSS of the PN722X when using SPI
COTI (HIF2)
Equivalent to pin I2CADR1_SPIMOSI of the PN722X when using SPI.
CITO (HIF3)
Equivalent to pin I2CSDA_SPIMISO of the PN722X when using SPI
SCK (HIF4)
Equivalent to pin I2CSCL_SPISCK of the PN722X when using SPI
[1] The “MOSI/MISO” replacement to “COTI/CITO” in this document follows the recommendation of the NXP – I2C standards organization.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
26 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.2.2 NCI transport mapping
A header byte is added to the NCI packets (either data or control message, as
defined in Section 5.3).
Each data transfer over SPI starts with a header byte called “transfer
direction detector”. The meaning of the header byte, depends on its value (
Table 6).
Table 6.PN722X transfer direction detector
Byte value
Meaning
0XXXXXXXb
DH write-access
11111111b (0xFF)
DH read-access
The “transfer direction detector” header byte restricts the full-duplex capabilities of SPI to half-duplex. Note: PN722X use a different scheme of SPI Data transfer as compared SPI Data transfer scheme mentioned in NCI Specification. Write and Read sequence is as defined in this section.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
27 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.2.3 Write sequence from the DH As the SPI clock is mastered by the DH,
only the DH can initiate an SPI exchange. A DH write sequence always starts
with the sending of the Transfer Direction Detector Byte = 0XXXXXXXb. The
PN722X considers all the following Bytes as part of an NCI packet.
NSS
SCK
MOSI
MISO IRQ
Transfer Direction NCI Header Det. = 0XXXXXXXb Byte 0
NCI Header NCI Payload NCI Payload
Byte 1
Length
Byte 0
0xFF
0xFF
0xFF
0xFF
0xFF
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
0xFF
0xFF
0xFF
Figure 19.Example of a SPI write-access
Note: If PN722X has an NCI Message ready to be sent to the DH while it is receiving another NCI Message from the DH, the IRQ pin is raised somewhere during the Write Sequence. This is not an error and has to be accepted by the DH. Once the Write Sequence is completed, the DH has to start a Read Sequence.
Issues may happen, in case PN722X is in Standby mode when the DH is writing a new frame: in such a condition, PN722X is not be able to catch the received frame.
In order to detect that PN722X is not ready to receive a frame, the DH has to monitor the CITO 3 line, to check the value of the first byte received on CITO while it is writing data on the COTI line. When the Write sequence starts:
· If the first Byte received on CITO is 0xFF, PN722X is ready, and the Write
sequence proceeds with no issue.
· If the first Byte received on CITO is any other value than 0xFF, PN722X is
not ready to receive a new frame. The DH has to resend the whole NCI frame,
after a typical timeout of 5 ms.
NSS
SPI NACK detection
DH waits 5ms and then sends command again
SCK COTI
1st Byte = 0b0XXXXXXX (SPI Write)
CITO IRQ
Not(0xFF)
0xFF
DH detects that NFCC is not ready thx to 1st Byte on MISO which is anything else than 0xFF
Figure 20.SPI write access in case PN722X is in standby
1st Byte = 0b0XXXXXXX (SPI Write) 1st Byte = 0xFF (SPI read)
This time, NFCC is ready
NFCC sends a response
3 The “MOSI/MISO” replacement to “COTI/CITO” in this document follows the recommendation of the NXP – I2C standards organization.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
28 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.2.4 Read sequence from the DH
The DH shall never initiate a spontaneous SPI read request. The DH shall wait
until it is triggered by the PN722X. To trigger the DH, the PN722X generates a
logical transition from Low to High on its IRQ pin. So after writing any NCI
command, the DH shall wait until the PN722X raises its IRQ pin. The DH can
then transmit a Read request to fetch the NCI answer from the PN722X. A DH
Read Sequence always starts by the sending of the Transfer Direction Detector
Byte = 0xFF.
NSS
SCK
COTI CITO IRQ
Transfer Direction dummy Det. = 0xFF
dummy
dummy
dummy
0xFF
NCI Header NCI Header NCI Payload NCI Payload
Byte 0
Byte 1
Length
Byte 0
dummy
dummy
dummy
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
NFCC requests a transfer
Figure 21.Example of a SPI read access
All data has been read, IRQ is reset
In Figure 21, PN722X requests a data transfer by raising the NFC_IRQ1 pin. The
DH tries to initiate a write sequence by positioning the Transfer Direction
Byte to 0b0XXXXXXX. PN722X keeps the NFC_IRQ1 to logical 1′ until the DH starts a read sequence. The DH is not allowed to proceed with a write sequence once the PN722X has set the NFC_IRQ1 pin to its active value (logical1′ in
Figure 21).
If PN722X has another message ready to be sent to the DH before the end of the
on-going Read Sequence, the IRQ pin is first deactivated at the end of the on-
going Read Sequence and then reactivated to notify to the DH that a new
message has to be read.
Note: IRQ in Figure 21 refers to NFC_IRQ1.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
29 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.2.2.5 Split mode
The PN722X supports the interruption of a frame transfer over SPI. This
feature is only available in Read Mode; it is forbidden to use it in Write
Mode. A typical use case for the split mode is to have the DH reading first
the NCI packet header, to know what the Payload length is. The DH can then
allocate a buffer with an appropriate size and read the payload data to fill
this buffer. Figure 22 represents this use case.
NSS
SCK
COTI CITO IRQ
Transfer Direction dummy Det. = 0xFF
dummy
dummy
0xFF
NCI Header NCI Header NCI Payload
Byte 0
Byte 1
Length
Figure 22.SPI read sequence with split mode
dummy
NCI Payload Byte 0
dummy
NCI Payload Byte n
6.2.2.6 Invalid sequence from the DH
Any SPI data transfer starting by a Transfer Direction Detector Byte different
from either 0XXXXXXXb or 11111111b is discarded by PN722X, as this is an
invalid frame (Figure 23).
NSS
SCK
COTI
Transfer Direction Det. = 10XXXXXXb
COTI IRQ
0xFF
Figure 23.Example of an invalid SPI access
Byte 0 0xFF
Byte 1 0xFF
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
30 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.3 HIF2 interface
6.3.1 I2C interface HIF2-I2C interface of the PN722X is compliant with the
[I2C] Bus specification, including device ID and Soft Reset. It is target-
only, i.e. the SCL signal is an input driven by the host. PN722X does not use
SCL clock stretching (i.e. maintain SCL low to pause the transmission).
iNmoptlee:mNenCtIinpgacthkeetIs2Clednrgivtherc.an be up to 258 Bytes in both
directions. The DH must consider this constraint when The PN722X HIF2-I2C
interface supports standard (up to 100 kbit/s), fast-Speed mode (up to 400
kbit/s), fastPlus mode (1 Mbit/s).
The PN722X supports the 7-bit addressing mode, which is FIXED at production.
Note: The PN722X I2C 7-bit address is fixed to 0x38.
6.3.2 NCI transport mapping In the PN722X, there is no additional framing
added for I2C: An NCI packet (either data or control message, as defined in
[NCI]) is transmitted over I2C “as is”, i.e. without any additional byte (no
header, no CRC etc.).
6.3.3 Write sequence from the DH As the HIF2-I2C clock is controlled by the
DH, only the DH can initiate an I2C exchange. A DH write sequence always
starts with sending of the PN722X HIF2-I2C target address followed by the
write bit (logical `0′: 0b). Then the PN722X HIF2-I2C interface sends an I2C
ACK back to the DH for each data byte written by the DH. It may send an I2C
NACK (negative acknowledge) when none of the reception buffers used by the NCI
core in the PN722X is free and also when PN722X is in standby state. If one
single byte of a complete NCI frame is NACKed by the PN722X, the DH has to
resend the complete NCI frame and not only this single byte. When standby
feature of PN722X is supported and HIF2-I2C interface, GPIO3 needs to be used
as wake-up source to PN722X to exit from standby and the I2C NACK shall be
sent.
SCL
I²C Start I²C Stop
SDA
I²C Slave Address NCI Header
+ R/W bit = 0b
Byte 0
NCI Header NCI Payload NCI Payload
Byte 1
Length
Byte 0
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
IRQ
Figure 24.I2C write sequence Note: With HIF2-I2C it may happen that PN722X
raised IRQ and an NCI Message is ready to be read by DH. If DH tries to send
an NCI Message, then it might be NACKed by PN722X. In such a condition, the DH
shall complete the Read Sequence and shall retry to perform the Write
Sequence. This is not an error and has to be accepted by the DH.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
31 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.3.4 Read sequence from the DH
The DH shall never initiate a spontaneous HIF2-I2C read request. The DH shall
wait until the PN722X triggers the read request. To trigger the DH, the PN722X
generates a logical transition from Low to High on its IRQ pin. After writing
any NCI command, the DH shall wait until the PN722X raises its IRQ pin. The DH
can then transmit a Read request to fetch the NCI answer from the PN722X .
When the PN722X needs to send a spontaneous notification to the DH (for
instance an RF Interface activation notification), the PN722X raises the IRQ
pin and the DH performs a normal read as described above.
A DH Read Sequence always starts by sending the PN722X HIF2-I2C Target Address
followed by the read bit (logical `1′). Then the DH I2C interface sends an ACK
back to the PN722X for each data byte received.
Figure 25 shows the example where the IRQ is raised so the DH can proceed a
read.
SCL
DH knows how often to Apply the clock
If the DH sends more clocks, zeros will be sent
I²C Start I²C Stop
SDA
I²C Slave Address NCI Header NCI Header NCI Payload NCI Payload
+ R/W bit = 1b
Byte 0
Byte 1
Length
Byte 0
NCI Payload NCI Payload NCI Payload
Byte n-2
Byte n-1
Byte n
IRQ
NFCC requests a transfer
Figure 25.I2C read sequence
If NFCC requests a transfer, but DH sets R/W bit to 0b, All data has been
IRQ will remain high.
read, IRQ is reset
In Figure 25, PN722X requests a data transfer by raising the NFC_IRQ2 pin. The
DH tries to initiate a write sequence by positioning the write bit to 0b.
PN722X keeps the NFC_IRQ2 active until the DH starts a read sequence. The DH
is not allowed to proceed with a write sequence once the PN722X has set the
NFC_IRQ2 pin to its active value (logical 1′ in Figure 25). If PN722X has another message ready to be sent to the DH before the end of the on-going Read Sequence, first the NFC_IRQ2 pin is deactivated at the end of the on-going Read Sequence. Second, NFC_IRQ2 pin is reactivated to notify to the DH that a new message has to be read. If PN722X has no more data to be sent but the controller keeps SCL line active, PN722X keeps sending dummy bytes0xFF’.
Note: IRQ in Figure 25 refers to NFC_IRQ2.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
32 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.3.5 Split mode
The PN722X supports the interruption of a frame transfer, as defined in [I2C].
This feature is only available in Read Mode and is forbidden in Write Mode.
This can be useful in a system where the I2C bus is shared between several
peripherals: It allows the host to stop an on-going exchange, to switch to
another peripheral (with a different target address) and then to resume the
communication with the PN722X.
Another typical use case for the split mode is to have the DH reading first
the NCI packet header, to know what the Payload length is. The DH can then
allocate a buffer with an appropriate size and read the payload data to fill
this buffer. Figure 26 illustrates this use case.
I²C Start I²C Stop I²C Start I²C Stop
SCL
DH can split the I²C Read transfer
SDA
I²C Slave Address NCI Header NCI Header NCI Payload
+ R/W bit = 1b
Byte 0
Byte 1
Length
IRQ
Figure 26.I2C Read sequence with split mode
I²C Slave Address NCI Payload
+ R/W bit = 1b
Byte 0
NCI Payload Byte n
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
33 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
6.4 GPIO and GPI interface
The PN722X supports multiple GPIOs and one GPI interface, each one having a specific functionality as described below:
Table 7.PN722X GPIO usage
GPIO name
Description
TDA_CS0, TDA_CS1 and TDA_CS2
Used to connect to chip-select of TDA’s
Table 8.PN722X GPI usage
GPI name
Description
Mode_Switch_GPI
Used to switch between NFC Forum and EMVCo mode in Single Main DH
Configuration for all PN722X variants using HIF1-I2C Interface.
Used to switch between NFC Forum execution with Main DH using HIF2-I2C
Interface and EMVCo mode execution with Target DH using HIF1-SPI Interface .
0′ NFC Forum Mode 1′ EMVCo Mode Note: When DH toggles the Mode_Switch_GPI, the DH must wait
for CORE_RESET_NTF and validate the state.
Note: A spike on Mode_Switch_GPI may lead PN722X to enter into NFC Forum or EMVCo Mode based on the first GPI state transition that PN722X observed. DH must ensure that PN722X is in correct state by reading the Proprietary reason code in CORE_RESET_NTF indicating boot due to Switch Mode reset. Note: Dual Host Device Configuration: Main Host device should make sure both PN722X and Target Host are in the correct state to avoid deadlocks in the system. Once Main host toggles Mode_Switch_GPI of PN722X to high to enter into EMVCo mode, Main Host device shall also indicate Target Host to take over the communication with NFCC and also check if the connection establishment is successful.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
34 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7 Compliance to [NCI] and PN722X NFCC extensions
The PN722X NFCC is a complex contactless System on Chip with numerous
features. Yet, [NCI] as defined by the NFC Forum does not give full access to
all these features. Therefore, NXP had to extend [NCI] with proprietary
extensions. The PN722X NFCC DH interface which includes [NCI] plus the PN722X
NFCC extensions is referenced in the present document as [PN722X NFCC-NCI].
Note: NXP uses [NCI] as much as possible and tries to limit the use of
proprietary extensions.
7.1 Feature-based comparison of [NCI] and [PN722X NFCC-NCI]
The table below represents the features overview of the PN722X NFCC. It highlights the main differences between the NCI standard ([NCI]) and [PN722X NFCC-NCI]. The chapter column contains shortcuts to the section in the document where the feature is described in detail.
Table 9.Features overview Features
RF Discovery activity based on NFC Forum RF Discovery activity based on EMVCo
Reader/Writer ISO-DEP for NFC-A and NFC-B, T2T, T3T, T4T, T5T Reader/Writer
MIFARE Classic, MIFARE Plus Card Emulation ISO-DEP for NFC-A Card Emulation
for other technologies Testing: PRBS test Configuration: Power and clock
management, RF Settings, APC Others: Encrypted Secured FW upload
[NCI 2.2] [PN722X NFCCNCI]
… covered … not covered
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
35 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.2 [NCI] Implementation in the PN722X NFCC
[NCI] defines several features which are optional or configurable. For
instance, data exchange can use an optional flow control, for which the number
of credits is defined by the NFCC. The maximum number of simultaneous Dynamic
logical connections is also up to the NFCC. This section describes [NCI]
features which are optional or configured by the NFCC, to highlight how they
are implemented in the PN722X NFCC.
7.2.1 Logical connections and credits Figure 27 shows a simplified overview of
an NFC device as defined in the NFC Forum.
NFC Forum Device
DH
Control Messages RF Interface
Logical Connection Control Messages NFCEE Interface Logical Connection Control
Messages
NCI
NFCC
NFCEE Protocol
NFCEE
RF Protocol
Remote NFC Endpoint
Figure 27.NFC Forum device architecture
Logical connections are used to transport data between the DH and the NFCC.
Although optional in [NCI], [PN722X NFCC-NCI] implements data flow control
based on credits management. To minimize the required buffer/memory size, the
number of credits is limited to 1 on each logical connection.
In addition to the mandatory static RF logical connection, [PN722X NFCC-NCI]
allows to create only 1 additional Dynamic logical connection. So, the “Max
Logical Connections” parameter reported in CORE_INIT_RSP equals 0x01 for
[PN722X NFCC-NCI] and the number of credits of the NFCEE Connection equals to
0x01. That means that when the DH must create a new logical connection, it has
to first close the currently opened one, if any.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
36 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Table 10 gives an overview of the logical connection and credits available in the [PN722X NFCC-NCI].
Table 10.Logical Connections/Credits configuration
Logical connection
Number of connections
Static connection Dynamic connection
– 1 for RF End Point – 1 for NFCEE Connection
– 1 for NCI loopback testing
Number of credits
1 1
1
Max. Data Packet payload Size
[255] [255] [255]
To optimize the number of [PN722X NFCC-NCI] internal buffers, all the logical connections shall not be used at the same time. Therefore, only the following scenarios are possible at the same time depending on the RF State Machine:
Table 11.Logical Connections supported depending on RF State Machine
NCI RF States
NCI CMD
Static RF EndPoint
RFST_IDLE
Others RF States
Loopback
CT NFCEE
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
37 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.2.2 Compliance to [NCI] control messages
Table 12.Status on the compliance to [NCI] control messages
Group
Control messages
CORE_RESET_CMD / RSP / NTF
CORE_INIT_CMD / RSP
CORE_SET_CONFIG_CMD / RSP
CORE_GET_CONFIG_CMD / RSP
CORE
CORE_CONN_CREATE_CMD / RSP CORE_CONN_CLOSE_CMD / RSP
CORE_CONN_CREDITS_NTF
CORE_GENERIC_ERROR_NTF
CORE_INTERFACE_ERROR_NTF
CORE_SET_POWER_SUB_STATE_CMD/RSP
RF_DISCOVER_MAP_CMD / RSP
RF_SET_LISTEN_MODE_ROUTING_CMD / RSP
RF_GET_LISTEN_MODE_ROUTING_CMD / RSP / NTF
RF_DISCOVER_CMD / RSP / NTF
RF_DISCOVER_SELECT_CMD / RSP
RF_INTF_ACTIVATED_NTF
RF_DEACTIVATE_CMD / RSP / NTF
RF_FIELD_INFO_NTF
RF_T3T_POLLING_CMD / RSP / NTF RF
RF_NFCEE_ACTION_NTF
RF_NFCEE_DISCOVERY_REQ_NTF
RF_PARAMETER_UPDATE_CMD / RSP
RF_INTF_EXT_START_CMD / RSP
RF_INTF_EXT_STOP_CMD / RSP
RF_EXT_AGG_ABORT_CMD / RSP
RF_NDEF_ABORT_CMD / RSP
RF_ISO_DEP_NAK_PRESENCE_CMD / RSP / NTF
RF_SET_FORCE_NFCEE_ROUTING_CMD / RSP
NFCEE_DISCOVER_CMD / RSP / NTF
NFCEE
NFCEE_MODE_SET_CMD / RSP / NTF NFCEE_STATUS_NTF
NFCEE_POWER_AND_LINK_CNTRL_CMD / RSP
Status Full support[1] Full support Full support Full support Full support Full support Full support[2] Full support Full support No support Full support Full support Full support Full support Full support Full support Full support Full support Full support No support No support Partial support[3] No support No support No support No support Full support No support Full support Full support No support No support
[1] CORE_RESET_NTF has sometimes an additional field, not compliant to [NCI].
See Section 9 [2] PN722X may send a CORE_CONN_CREDIT_NTF with 0 credit
indicating that NFCC received a data packet but could not release the data
immediately,
due to a flow control on the NFCEE/RF interface preventing NFCC to release the
credit. In such situation (for example during extended APDU in wired mode), a
subsequent CORE_CONN_CREDIT_NTF with 1 credit is sent once NFCC sends the
packet. [3] RF_PARAMETER_UPDATE_CMD is not fully supported as corresponding
scenarios can automatically be fulfilled when using ISO-DEP RF interface.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
38 / 141
NXP Semiconductors
7.2.3 Compliance to [NCI] RF interfaces Figure 28 shows the RF interfaces
available in [NCI].
UM11810
PN722X NFC controller
Figure 28.[NCI] RF interface architecture
Table 13 shows which RF interfaces PN722X NFCC supports and reports into CORE_INIT_RSP.
Table 13.NCI interface limitations RF Interface present in [NCI] Poll side Frame RF interface Listen side Frame RF interface (3A/3B) Poll side ISO-DEP interface Listen side ISO-DEP interface Poll side and Listen side NFC-DEP interface Poll side Frame RF interface with frame Aggregated extension
Status Full support No Support Full support Full support No Support No Support
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
39 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.2.4 Compliance to [NCI] RF Discovery
Table 14 lists the phases that PN722X NFCC supports.
Table 14.Supported NCI Discovery phases RF Interface present in [NCI] NFC_A_PASSIVE_POLL_MODE NFC_B_PASSIVE_POLL_MODE NFC_F_PASSIVE_POLL_MODE NFC_ACTIVE_POLL_MODE NFC_V_PASSIVE_POLL_MODE NFC_A_PASSIVE_LISTEN_MODE NFC_B_PASSIVE_LISTEN_MODE NFC_F_PASSIVE_LISTEN_MODE NFC_ACTIVE_LISTEN_MODE
Value 0x00 0x01 0x02 0x03 0x06 0x80 0x81 0x82 0x83
Status Full support Full support Full support No Support Full support Full support No Support No Support No Support
7.2.5 Compliance to [NCI] configuration parameters
[NCI] defines a set of configuration parameters in NCI Spec [Configuration
Parameter Tags]. PN722X NFCC supports most of the parameters, apart from one
subset. PN722X supports device resolution of two devices in each technology
and activation of the first two device IDs using RF_DISCOVER_SELECT_CMD.
Table 15 lists [NCI] configuration parameters, with the default value in
PN722X.
Table 15.Compliance to [NCI] configuration parameters
Configuration parameter
Status on PN722X
Coming from Default value Behavior if partial/no support
TOTAL DURATION
Full support [NCI]
0x03E8 (1 s)
Minimum Value: 350 ms
Maximum Value: 65 seconds (without LPCD)
Maximum Value: 2.6 seconds (with LPCD) NOTE: Step size is 10 milli seconds.
CONDISCOVERY
No support [ACTIVITY] —
—
PARAM
PA_BAIL_OUT
Full support [ACTIVITY] 0x01
Bail Out is enabled by default in Poll/NFC-A
PA_DEVICES_LIMIT
Full support [ACTIVITY] 0x02
Value supported from 0x01 to 0x02
PB_AFI
Full support [DIGITAL]
0x00
—
PB_BAIL_OUT
Full support [ACTIVITY] 0x01
Bail Out is enabled by default in Poll/NFC-B
PB_ATTRIB_PARAM1 Full support [DIGITAL]
0x00
—
PB_SENSBREQ
Full support [DIGITAL]
0x00
—
PARAM
PB_DEVICES_LIMIT Full support [ACTIVITY] 0x02
Value supported from 0x01 to 0x02
PF_BIT_RATE
Full support [DIGITAL]
0x01 (212 kB/ — s)
PF_BAIL_OUT
Full support [ACTIVITY] 0x01
Bail Out is enabled by default in Poll/NFC-F
PF_DEVICES_LIMIT
Full support [ACTIVITY] 0x02
Value supported from 0x01 to 0x02
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
40 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Table 15.Compliance to [NCI] configuration parameters…continued
Configuration parameter
Status on PN722X
Coming from Default value Behavior if partial/no support
PI_B_H_INFO
Full support [DIGITAL]
empty
—
PI_BIT_RATE
Full support [DIGITAL]
0x00
106 kB/s by default but can be up to 848 kB/s
PN_NFC_DEP_PSL
No Support [DIGITAL]
—
—
PN_ATR_REQGEN No Support [DIGITAL]
—
—
BYTES
PN_ATRREQ
No Support [DIGITAL]
—
—
CONFIG
PV_DEVICES_LIMIT Full support [ACTIVITY] 0x02
Value supported from 0x01 to 0x02
LA_BITFRAME SDD[1]
No support [DIGITAL]
—
Use Proprietary 0xA2 configuration to update these parameters in EEPROM.
LAPLATFORM CONFIG[1] LA_SEL_INFO[1]
No support [DIGITAL]
—
No support [DIGITAL]
—
LA_NFCID1
No support [DIGITAL]
—
—
LB_SENSB_INFO
No Support [DIGITAL]
—
—
LB_NFCID0
No Support [DIGITAL]
—
—
LBAPPLICATION
No Support [DIGITAL]
—
—
DATA
LB_SFGI
No Support [DIGITAL]
—
—
LB_FWI_ADC_FO
No Support [DIGITAL]
—
—
LB_BIT_RATE
No Support [NCI]
—
—
LFT3T
No Support [DIGITAL]
—
—
IDENTIFIERS_1..4
LFT3T
No Support [DIGITAL]
—
—
IDENTIFIERS_5..16
LFPROTOCOL
No Support [DIGITAL]
—
—
TYPE
LF_T3T_MAX
No Support [NCI]
—
—
LF_T3T_FLAGS
No Support [NCI]
—
—
LF_T3TRD
No Support [NCI]
—
—
ALLOWED
LFPROTOCOL
No Support [NCI]
—
—
TYPE
LI_A_RATS_TB1
Full support [DIGITAL]
0x04
—
LI_A_HIST_BY
Full support [DIGITAL]
empty
—
LB_H_INFO_RESP
No Support [DIGITAL]
—
—
LI_A_BIT_RATE
Full support [DIGITAL]
0x00 (106 kB/ 106 kB/s by default but can be up to 848 kB/s s)
LI_A_RATS_TC1
Full support [NCI]
0x00
—
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
41 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Table 15.Compliance to [NCI] configuration parameters…continued
Configuration parameter
Status on PN722X
Coming from Default value Behavior if partial/no support
LN_WT
No Support [DIGITAL]
0x08
—
LN_ATR_RESGEN No Support [DIGITAL]
Empty
—
BYTES
LN_ATRRES
No Support [DIGITAL]
0x30
—
CONFIG
PACM_BIT_RATE
No Support [NCI]
0x01
—
RF_FIELD_INFO
Full support [NCI]
0x00
—
RF_NFCEE_ACTION No Support [NCI]
0x01
—
NFCDEP_OP
No Support [NCI]
0x0E
—
LLCP_VERSION
No Support [LLCP]
0x11
—
NFCCCONFIG
No support [NCI]
—
—
CONTROL
[1] Using Extended TLV with 0xA2XX, you can configure this parameter which is stored in EEPROM.
7.2.6 Compliance to [NCI] data messages PN722X is fully compliant to the [NCI] data messages.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
42 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3 Extensions added to [NCI] to allow full control of the PN722X NFCC
The [PN722X NFCC-NCI] extensions section gives a quick overview of the
numerous extensions required to [NCI] to give full access to all the features
available in the PN722X NFCC.
7.3.1 [PN722X NFCC-NCI] extensions to [NCI] RF protocols
PN722X NFCC supports an additional protocol than handled today by [NCI].
It is required to extend the RF Interfaces defined in NCI Spec [Table : RF
Protocols] such that this protocol can be configured in various
commands/notifications:
Table 16.Proprietary RF protocols
Chapter
Value
Section 10.1.1 0x80
Others
Description PROTOCOL_MIFARE_CLASSIC Reserved for Proprietary protocols
7.3.2 [PN722X NFCC-NCI] extensions to [NCI] bit rates in NFC-F
PN722X NFCC offers the possibility to poll for NFC-F @ 212 kB/s and NFC-F @
424 kB/s. Unfortunately, [NCI] only allows configuring one of these 2-bit
rates, but not both in the same discovery sequence. The [NCI] parameter used
to configure the bit rate in NFC-F is PF_BIT_RATE; the values which can be
applied to this parameter are defined in the NCI Spec [Table : Discovery
Configuration Parameters for Poll F].
It is therefore required to extend this table such that the PN722X NFCC is
configured to poll during one discovery sequence for NFC-F @ 212 kB/s and
NFC-F @ 424 kB/s. The proprietary value 0x80 is used for that purpose, and has
to be restricted to technology NFC-F in NFC Forum Mode.
Table 17.Proprietary bit rates
Chapter
Value
Section 10.1.2 0x80
Description NFC_BIT_RATE_212 and NFC_BIT_RATE_424
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
43 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3.3 [PN722X NFCC-NCI] extensions to [NCI] RF interfaces
PN722X NFCC offers some features which are not accessible using the currently defined RF interfaces in NCI Spec. So, the NCI Spec [Table : RF Interfaces] must be extended with some proprietary RF interfaces, as described in the table below:
Table 18.RF interfaces extension
Chapter
New RF interface
Section 10.1.1.2 TAG-CMD
Value 0x80
Others
Brief description
This new interface adds a header to the data payload, in order to encode
commands such as: – T2T/MFUL sector select command – MIFARE Classic
Authenticate command Reserved for proprietary RF interfaces
7.3.4 [PN722X NFCC-NCI] extensions to [NCI] control messages and [NCI] notifications
This section contains all the additional commands/notifications in [PN722X NFCC-NCI].
Table 19.PN722X NFCC-NCI additional commands/notifications
Chapter
PN722X NFCC-NCI control Brief description message
Support on PN722X
Section 9.2.1
NCIPROPRIETARY ACT_ Command used by the DH to activate
CMD/RSP
proprietary extension of NFCC
Full Support
Section 12.4.1
CORE_SETPOWER MODE_CMD/RSP
Command allowing the DH to configure the power mode (standby or no standby state).
Full Support
Section 10.1.3.3
WTX_NTF
Notification indicating that RF communication is Full Support in phase of
WTX(RTOX) REQ/RESP exchange
for longer period
Section 7.3.10
PLL_UNLOCKED_NTF
Notification indicating that RF PLL fails to lock Full Support after it is started
Section 7.3.11
TXLDO_ERROR_NTF
Notification sent to indicate that TxLDO cannot Full Support be started successfully
Section 7.3.12
FLUSH_SRAM_AOTO FLASH
Command sent by the DH to save the content Full Support of the RAM always on area to FLASH.
[NCI] defines some rules which constraint the use of the control messages.
That means that depending on the state the NCI RF State Machine is in,
depending on the RF Interface used, depending on some parameters, the control
messages are valid or incorrect, and sometimes they trigger state transitions.
NXP has extended these rules for the [PN722X NFCC-NCI] extensions.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
44 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Figure 29 and Figure 30 illustrate the rules for most of the notification and commands:
Figure 29.Command/response versus the current state of the NCI RF state machine Figure 30.NTFs versus the current state of the NCI RF state machine
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
45 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
To secure the implementation of the “atomic behavior” of CORE_RESET_CMD and CORE_INIT_CMD, and to handle the mapping of RF protocol to RF interface with RF_DISCOVER_MAP_CMD, PN722X NFCC defines additional states to the RF state machine defined in [NCI]. Figure 31 illustrates the additional states linked to the [NCI]-defined RFST_IDLE.
HW Reset
BOOT_IDLE
CORE_RESET_CMD/RSP/NTF
BOOT_RESET
TOGGLE ON MODE_SWITCH_GPI
CORE_INIT_CMD/RSP
CORE_RESET_CMD/RSP/NTF
RFST_IDLE
Figure 31.States added to the [NCI] state machine
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
46 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3.5 [PN722X NFCC-NCI] extensions to [NCI] configuration parameters
[NCI] lists the parameters required to set up the RF discovery. PN722X NFCC
requires additional parameters, for instance to configure some RF protocols
which are not supported by [NCI], or to configure the power and clock
management.
Table 20 lists the sets of additional parameters.
Table 20.Overview of additional configuration parameters
Section
Feature to configure
Comment
Section 13.1
System
Parameters allowing the DH to configure the System: Clock management, MIFARE Classic Keys handling…
Section 13.2
RF Discovery
Parameters allowing the DH to configure the Discovery activity (Discovery profile between NFC Forum and EMVCo,….)
Section 13.3
Contactless Interface
Parameters allowing the DH to configure all internal HW settings in the contactless interface (CLIF) as well as specific RF platform settings (LPCD, DPC)
7.3.6 [PN722X NFCC-NCI] extensions to [NCI] proprietary parameters space
[NCI] defines a parameter space with a size of 255 parameters, in which around 96 tags are allocated for proprietary parameters:
Table 21.Parameter space Parameters space subsections Assigned and reserved in [NCI] Reserved for Proprietary Use RFU (Reserved for Extension)
Tag 0x00-0x9F 0xA0-0xFE 0xFF
Regarding the PN722X NFCC needs, this reserved area is not sufficient. To
extend this space, the solution chosen is to define a space of tags coded on
16 bits, instead of 8 bits. These extended tags always start with the value
0xA0, 0xA1, or 0xA2, which is the first value available in the Proprietary
range. This allows adding 256 new parameters.
Note: If this is not sufficient, 16-bit tag values starting by 0xA3 may be
used.
Table 22.Extended TLV for proprietary parameters
Payload
Field
Length
m+3 Octets
Tag = 0xA0XX,
2 Octets
0xA1XX or 0xA2XX
Len
1 Octet
Val
m Octets
Description Extended tag identifier.
The length of Val (m). Value of the configuration parameter.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
47 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Figure 32 illustrates the comparison between regular and extended TLVs.
1 octet
1 octet
x octets
2 octets
1 octet
y octets
1 octet
1 octet
z octets
Taga
Lena
Vala
Tagb= 0xA0XX
Lenb
Valb
Taga
Lena
Vala
Regular TLV
Extended TLV
Figure 32.Comparison between regular and extended TLVs
Regular TLV
7.3.7 [PN722X NFCC-NCI] extensions to [NCI] status codes
[NCI] defines a set of standard Status Codes in [NCI_Table1] (see Section 3). NXP has extended this set of status codes with the following values:
Table 23.Proprietary Status Codes
Status Description code
0xE3 STATUS_PMUTXLDO OVERCURRENT
0xE4 0xE7
STATUS_EMVCOPCD COLLISION
STATUS_GPADC_ERROR
0xEE 0xF0
STATUS_NCI_USERAREA CRC_ERROR
STATUS_NCI_USERAREA RECOVERY_ERROR
0xF1 EXTERNAL RF ERROR
0xF2 TX LDO ERROR
0xF3 0xF4
INVALID LOAD RF CONFIGURA TION
SECURE_EE_CRC_ERROR
Used in
Error recovery
COREGENERIC ERROR_NTF
Check VDDPA connection.
Restart the NFC service. If issue still present, Contact NXP support
COREGENERIC ERROR_NTF
Polling sequence will be restarted in EMVCo Mode
COREGENERIC ERROR_NTF
Restart the NFC service
COREGENERIC ERROR_NTF
No action as automatically recovered by NFCC.
COREGENERIC ERROR_NTF
Restart the load of customer-specific parameters. As default config values will be applied.
COREGENERIC ERROR_NTF
Returned during Field ON when external RF is present
COREGENERIC ERROR_NTF
Field ON is not successful due to LX LDO Error
SWITCH_RF_FIELD_RSP Load RF Configuration CMD is not executed with a valid TX and RX Configuration
COREGENERIC ERROR_NTF
Customer to perform Secure FW update procedure with FW containing User EE area. Update the customer settings in User EE area once again using Prop Setconfig extension using 0xA2.
Except error code related to EMVCo PCD collision that may happen in EMVCo mode. The other error codes can only occur in rare error cases and should be reported to customer support.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
48 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3.8 [PN722X NFCC-NCI] extensions to [NCI] reason code in CORE_RESET_NTF
[NCI] defines a set of standard reason codes in the CORE_RESET_NTF. Refer to [NCI_Table9] (see Section 3). NXP has extended the set of reason codes with the following values shown in Table 24.
Table 24.Proprietary reason codes in CORE_RESET_NTF
Reason code
Description
0xA0
An assert has triggered PN722X NFCC reset/reboot
0xA1
An over temperature has triggered the reset of PN722X NFCC
0xA2
RFU
0xA3
The watchdog has triggered PN722X NFCC reset/reboot
0xA4
RFU
0xA5
RFU
0xA6
RFU
0xA7
HIF1_I2C, HIF_SPI – After POR, any NCI packet other than CORE_RESET_CMD, OR
any invalid HDLL packet (i.e CRC NOK) is received by PN722X.
HIF2_I2C – Any Packet other than CORE_RESET_CMD is received by PN722X. Note:
PN722X can receive HDLL CMDs before 5sec after POR in HIF1_I2C and HIF_SPI
Interface.
0xA8
Boot due to Switch Mode reset to switch to NFC Forum Mode
0xA9
Boot due to Switch Mode reset to switch to EMVCo Mode
Note: When the 0xA0 reason code is used, the CORE_RESET_NTF is out of [NCI]
compliance.
Indeed, PN722X appends one parameter at the end of the CORE_RESET_NTF, to
provide some information for debug purposes. The CORE_RESET_NTF format is
then:
Table 25.CORE_RESET_NTF when reason code = 0xA0 is used
Payload field(s)
Length
Description
Reason Code
1 Octet
0xA0: NXP proprietary
Config. Status
1 Octet
See [NCI]
Default 0xA0
PN722X follows the sequence below when an over temperature is detected (Reason
Code = 0xA1):
· PN722X turns off the RF Field and waits until any RSP/NTF pending to be read
from PN722X by DH and next enters into Standby.
· PN722X waits until the chip temperature comes down to an internal threshold.
· When the internal temperature is low enough, PN722X reboots and sends a
CORE_RESET_NTF (0xA1) to
inform the DH that an over temperature event occurred. · DH may continue with
usual NFC Service initialization.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
49 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3.9 [PN722X NFCC-NCI] extensions to [NCI] reason code in NFCEE_STATUS_NTF
[NCI] defines a set of standard reason codes in the NFCEE_STATUS_NTF supported
by PN722X. Refer to [NCI].
NXP has extended this set of reason codes with the values listed in Table 26.
Table 26.Proprietary Reason Codes in NFCEE_STATUS_NTF
Reason code
Description
0x92 0x93
NFCC got a timeout during CT activation request
0x98
NFCC has detected an issue during CT activation
0x99
NFCC has detected an issue during CT deactivation
Note: When any NFCEE_STATUS_NTF with a proprietary reason code is used, DH considers CT as unresponsive and applies the same recovery procedure as UNRECOVERABLE_ERROR: NFCEE_DISCOVER_CMD followed by the corresponding NFCEE_MODE_SET_CMD.
7.3.10 [PN722X NFCC-NCI] extensions to [NCI] PLL unlocked notification
NXP has created a new notification which is sent in case the PLL cannot lock on the incoming system clock; here is the description of this notification:
Table 27.PLL_UNLOCKED_NTF
GID
OID
Parameter number Description
0001b
0x21
0
Notification sent in case PLL does not lock to system clock
7.3.11 [PN722X NFCC-NCI] extensions to [NCI] TxLDO ERROR Notification
NXP has created a new notification which is sent to notify the DH when TxLDO driver cannot be started successfully.
Table 28.TxLDO_ERROR_NTF GID OID Parameter number
0001b 0x23 0
Description TxLDO driver cannot be started
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
50 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
7.3.12 [PN722X NFCC-NCI] extension to [NCI] FLUSH_SRAM_AO_TO_FLASH
The PN722X NFCC contains a RAM area which remains powered on even in standby state. This area is used to store temporarily some parameters which can be dynamically updated by the DH. At boot time, the RAM always is initialized with the content of its mirrored FLASH area. This concerns the following parameters: NCI `official’ registers, routing table. Synchronization is done thanks to NCI proprietary command that can be used by the DH to force a copy of the RAM always on area to it’s mirrored FLASH area. DH shall only use this command when in RFST_IDLE. NFCC expects that this command is sent by the DH · at the end of NFCC initialization before sending NCI_DISCOVER_CMD · before entering into a low-power state
Table 29.FLUSH_SRAM_AO_TO_FLASH_CMD
GID
OID
Parameter number Description
1111b
0x21
0
Command to save the content of the SRAM Always ON to FLASH.
Table 30.FLUSH_SRAM_AO_TO_FLASH_RSP
GID
OID
Parameter number Description
1111b
0x21
1
The NFCC writes the SRAM Always On content into flash if content of both
areas is different. Then it returns STATUS_OK.
Table 31.FLUSH_SRAM_AO_TO_FLASH_RSP parameters
Payload Field(s)
Length Value/Description
STATUS
1 Octet
0x00
STATUS_OK
0x09
PH_NCI_STATUS_INVALID_PARAM
0x06
STATUS_SEMANTIC_ERROR
Others
RFU
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
51 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8 NFCEEs management
8.1 Overview
In addition to the NFCEE hosted by the DH (DH-NFCEE), the PN722X NFCC can be
connected to 3 different Contact devices via TDAs:
1. Two SAMs can be connected over 2 TDAs. 2. One CT Payment card using one
TDA.
Here are the features offered by the PN722X NFCC over the different NFCEE:
Table 32.Features overview Mode
Card Emulation
Reader/Writer
Features ISO-DEP NFC-A ISO-DEP NFC-B FeliCa NFC-F MIFARE Classic NFC-A MIFARE DESFire NFC-A T2T, MIFARE Classic NFC-A ISO-DEP NFC-A MIFARE DESFire NFC-A ISO-DEP NFC-B FeliCa, T3T
DH-NFCEE
NFCEE over TDA
… covered
… not covered
The enabling/disabling of the NFCEEs is controlled by the DH thanks to the
standard [NCI] command NFCEE_MODE_SET_CMD. CT support using TDA is not used
for any RF Interface use case, but instead will only be used to communicate
with SAM or CT Payment card.
8.2 NFCEE power supply concept
PN722X will not control power supply to any TDA device.
8.3 NFCEE reset concept
As described in Section 8.3, PN722X does not control the power supply to any
TDAs. Therefore, it is not possible to reset any TDA device.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
52 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8.4 NFCEE discovery
PN722X supports the connection to three TDA through IOAUX and CLKAUX
interfaces. PN722X can also receive ISO7816 APDUs from the DH.
PN722X sends one NFCEE_DISCOVER_NTF notifications for each CT device connected
using TDA which is outside the HCI network. The notifications inform the DH
about the NFCEE ID assigned by PN722X. The NFCEE ID is used later on to
communicate with ISO7816 APDUs and to Enable/Disable the NFCEE with the
NFCEE_MODE_SET_CMD.
[NCI] defines a new way of managing NFCEE that impacts both the NCI API and
how it is used.
The NFCEE management is composed of five functions:
· NFCEE discovery: How the DH detects some NFCEEs and gets information about
their state, power mode and capabilities.
· NFCEE activation: How the DH can enable or disable a specific NFCEE.
· NFCEE identity mapping and communication: [NCI] supports NFCEE from
various networks and is able to map an NFCEE network-specific number with an
NCI number.
· NFCEE state management: [NCI] defines an NFCEE state transition list to
manage the state of an NFCEE. Some NFCEE require a non-predictable time for
boot-up operation and initialization. With this NCI interface, the DH knows
the status of all NFCEE in real time.
· NFCEE power management: PN722X does not support NFCEE power management.
The DH oversees the NFCEE discovery process. The NFCC provides in the response
the number of NFCEE physically or theoretically present whether the NFCEEs
belong to the HCI network or not. For each NFCEE present, an NFCEE discover
notification is sent with the current state of the NFCEE, the supported
protocol, and the type of NFCEE. PN722X does not support any HCI NFCEE.
For NFCEE CT, the logical channel connection must be created dynamically.
The NFCEE mode set procedure is used to activate the link interface of a
particular NFCEE. This triggers the activation procedure of the NFCEE. If the
NFCEE was already enabled, the status message will go as success and a
notification will also be sent as success. NFCEE CT Payment card insertion is
highly dynamic in nature, once inserted a discovery notification is sent to
the DH with the new NFCEE presence. Then DH should send the Mode Set Enable
command to activate the NFCEE. After the activation a logical connection can
be established to exchange the APDUs.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
53 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8.4.1 NFCEE discovery command
NFCEE Discovery module which is no longer supported by the NFCC but by the DH.
As such, the DH oversees discovering the presence of the NFCEEs attached to
the NFCC. After the NFCEE discovery command, the NFCC reacts by providing the
list of visible NFCEEs already enabled or not. Apart from NFCEE Payment card,
if some NFCEE (for example SAM) are attached after the NFCEE discovery
request, the NFCC no longer sends notifications. Apart from NFCEE Payment
card, if an NFCEE (for example SAM) is removed after an NFCEE discovery
request, NFCC sends a removal notification. Then the DH can initiate a new
NFCEE discovery or wait for the discovery notification about a card insertion.
Upon receiving an NFCEE discover request, the NFCC sends an NFCEE discovery
response indicating the number of NFCEE among the following: CT1, CT2 and CT3.
After the NFCEE discover response has been sent, the NFCC sends as many NFCEE
discovery notification as the number of NFCEE interfaces available. For each
NFCEE, the NFCC indicates if the NFCEE is enabled, disabled, or unresponsive
(if the NFCEE is not present in the slot), the number of protocol information
supported, NFCEE specific information, and NFCEE power supply mode.
8.4.2 NFCEE identity mapping and communication
The DH cannot use the static logical channel to access the NFCEEs outside HCI network. Instead, a dynamic logical channel must be created. Table 33 shows how NFCEE CT identifiers are mapped with an NCI number.
Table 33.NFCEE Identifiers mapping between NCI
NFCEE Interface
Conn ID
NCI ID
DH_ NFCEE
CT1
CT2
CT3
Host IF
IOAUX IOAUX IOAUX
NA
0x0A 0x0B 0x0C
0x00
0x20 0x21 0x22
Chip Select
GPIO0
GPIO1
NA
NA
1
0
0
1
0
0
DWL_REQ NA
0 0 1
The PN7220 GPIO used to connect the TDA chip-select defines the CT slot
numbering. PN7220 configures the number of active CT slots connected to
PN7220. Based on this configuration, PN7220 uses TDA to check the CT card
presence.
NFCEE CT is out of the HCI network. It supports [7816-4] protocol and requires
a dynamic logical connection.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
54 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8.4.3 NFCEE state management
After having received all NFCEE discover notifications, the DH can initiate
NFCEE_MODE_SET_CMD enable command in order to enable a specific NFCEE. At the
start of the discovery, the NFCEE is in disabled state or unresponsive state
(if no card is present in the slots). If the NFCEE is in unresponsive state,
it goes to disabled state only when a card is inserted and a discover
notification is sent to the DH.
If the NFCEE was declared as disabled, the successful completion of the NFCEE
mode set procedure switches the NFCEE state into enable state. Otherwise, the
DH can disable an NFCEE by sending the NFCEE_MODE_SET_CMD disable command.
When NFCEE mode is set to enable, the NFCEE starts activating the card. The
NFCEE_MODE_SET_NTF is sent after the NFCEE has been enabled or disabled. Once
the card activation is complete, a discover notification is also sent with the
ATR information and enabled state.
When NFCEE is being used, some transmission errors might occur, or the NFCEE
might be removed. Then the NFCEE status unrecoverable error notification is
sent to the DH. In such scenario, the NFCEE is set in unresponsive state and
can only be retrieved and used after an NFCEE discover request from the DH.
Deactivation of the NFCEE is carried out when the DH sends a MODE SET command
with disable option. The CT payment card removal deactivates the card
automatically and the NFCEE state becomes unresponsive until the next
insertion of the card. A discover notification is also sent to the DH with the
state as unresponsive.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
55 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8.4.4 NFCEE power management
The NFCEE_DISCOVER_NTF has been extended in [NCI] to indicate for each NFCEE
whether the NFCC is able to control the power supply of this NFCEE or not.
The DH uses this information to exchange data with the NFCEE. If NFCC controls
the NFCEE power supply, the DH can force NFCC to always maintain the power
supply or the communication link with this NFCEE, using NCI command
NFCEE_POWER AND_LINK_CTRL. This API has no persistent effect. Note: PN722X
does not control the power supply to TDAs.
In case NFCC does not control the NFCEE power supply (this is the case for
CT), the DH must use other means to ensure that the NFCEE is always power
supplied.
8.4.5 NFCEE discovery for one NFCEE CT using TDA
Figure 33 describes the NFCEE CT discovery sequence when the NFCEE has not yet
performed its CT initialization. The assumption is that the NFCEE CT card is
inserted dynamically in payment card insertion use case.
DH Host
NCI
NFCC
Full initialization NCI previously done
Contact Card is considered as a Secure Element (NFCEE in NCI terminology)
RF Contactless Card ISO7816
Contact Card
Contact Card
Detected
If Contactless Card Not present
APDU exchange directly transported into NCI data
channel
Activate Contact Interface
NFCEE_DISCOVER_NTF NFCEEId=0x12, ATR
EVT_ATR
NFCEE_MODE_SET_CMD (Enable NFCEEId=0x11)
NFCEE_MODE_SET_RSP
NFCEE_MODE_SET_NTF
CORE_CONN_CREATE_CMD(NFCEEId=0x11)
CORE_CONN_CREATE_RSP(ConnID)
NCI_DATA_MSG C-APDU
Data exchange (Application Level): C-APDU
NCI_DATA_MSG R-APDU
R-APDU
NCI Credit Ntf
CORE_CONN_CLOSE_CMD(NFCEEId=0x11)
CORE_CONN_CLOSE_RSP
NFCEE_MODE_SET_CMD (Disable NFCEEId=0x11) NFCEE_MODE_SET_RSP
Deactivate Contact Interface
NFCEE_MODE_SET_NTF
ISO7816
Contact Card Removed
Figure 33.NFCEE discovery sequence when the NFCEE CT card is inserted
dynamically
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
56 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
8.4.6 Format of the NFCEE_DISCOVER_NTF for the CT device
Table 34 shows the parameters of NFCEE discovery sequences when NFCEE_DISCOVER_NTF is sent to inform the DH about the NFCEEs connected outside the HCI network.
Table 34.NFCEE_DISCOVER_NTF for each CT NFCEE outside the HCI network
Payload Field(s)
Length
Value/Description
NFCEE ID
1 Octet
NFCEE ID · 0x20 for CT1 · 0x21 for CT2 · 0x22 for CT3
NFCEE Status
1 Octet
· 0x00 if NFCEE connected and enabled · 0x01 if NFCEE connected and disabled · 0x02 if NFCEE is unresponsive or card not inserted
Number of Protocol Information Entries
1 Octet
1 => for CT NFCEE
Supported NFCEE Protocols [0..n]
n Octet
0x00 => APDU mode for CT NFCEE
Number of NFCEE
1 Octet
1
Information TLVs
NFCEE Information
Length of Type 0x01 (ATR Bytes)
ATR Bytes + Length: n Bytes
2 Octets
Value: ATR Bytes of length n bytes.
NFCEE Power Supply 1 Octet
NFCC has no control of power supply for CT devices · 0x00 for any CT device
8.4.7 RF_NFCEE_ACTION_NTF and RF_NFCEE_DISCOVERY_REQ_NTF PN722X does not support RF use case with NFCEE CT interface.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
57 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
9 Initialization and operation configuration
9.1 Reset/initialization
[NCI] defines Reset/Init sequence based on two commands:
· CORE_RESET_CMD · CORE_INIT_CMD
The DH calls the two commands in an “atomic” way: there cannot be any other
command in-between and the PN722X NFCC operation cannot start any operation
(Reader/Writer, Card Emulation, Combined modes etc.) if it does not first
receive these two commands.
[NCI] defines two modes for the reset command: Keep Configuration and Reset
Configuration. shows the differences between the two reset modes.
Table 35.Comparison of the two reset modes Features
CPU reboot Listen Mode Routing table[1] NCI Configuration parameters
Proprietary Configuration parameters Interface Mapping Table Discovery
activity Dynamic connections
Reset configuration Yes Lost Back to default Lost[2] Lost Lost Lost
Keep configuration
Yes Kept Kept Kept Kept Lost Lost
[1] Listen Mode Routing table is updated in FLASH DATA using
RF_SET_LISTEN_MODE_ROUTING_CMD. DO not use this configuration frequently. [2]
RF Discovery configuration is not updated to either FLASH DATA or RAM-AO.
If the DH sends a CORE_RESET_CMD while PN722X NFCC has already indicated that
it has some data available to be read by the DH (IRQ pin activated), the DH
has to first read the data available from PN722X NFCC before it can get the
CORE_RESET_RSP. The reason is that the NCI output buffer in PN722X NFCC needs
to be flushed before PN722X NFCC can apply a Reset and then send the
CORE_RESET_RSP.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
58 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
9.2 Manufacturer-specific information in [NCI2.2] CORE_RESET_NTF
The NCI notification CORE_RESET_NTF for [NCI2.2] includes a 5-byte field for Manufacturer Specific Information. Table 36 shows the meaning of the 5 Bytes and the conditions increment or update the value.
Table 36.Manufacturer-specific information in CORE_RESET_NTF
Byte
Meaning
Condition to increment
Value for PN722X
0
Model ID
Specific Model ID (variant of the hardware platform)
0x2X
1
Hardware Version number
Silicon identifier
0x53
2
ROM Code Version number
ROM Code identifier
0x03
3
FLASH Major version
Firmware major branch
0xYY
4
FLASH Minor version
New firmware, solving bugs on existing 0xZZ features.
9.2.1 Proprietary command to enable proprietary extensions
It is visible on the previous flowchart that NXP has introduced a proprietary
command sent by the DH to enable the proprietary extensions to [NCI], which
are available in the PN722X NFCC. So, when the PN722X NFCC receives this
command NCI_PROPRIETARY_ACT_CMD, it knows that the DH is aware of the
proprietary extensions and may therefore send proprietary notifications (see
the list in Table 17).
Here is the description of this command:
Table 37.NCI_PROPRIETARY_ACT_CMD
GID
OID
Numbers of parameter(s)
1111b
0x02
0
Description DH informs the PN722X NFCC that it knows the proprietary extensions.
Table 38.NCI_PROPRIETARY_ACT_RSP
GID
OID
Numbers of parameter(s)
1111b
0x02
2
Description See table below for details
Table 39.NCI_PROPRIETARY_ACT_RSP parameters
Payload Field(s)
Length Value/description
STATUS
1 Octet One of the following Status codes, as defined in [NCI_Table1]
0x00 0x03 Others
STATUS_OK STATUS_FAILED Forbidden
FW_Build_Number
4 Octets NXP internal firmware build number
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
59 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
9.3 PLL input clock management
The PN722X NFCC clock source can be:
· One 27.12 MHz quartz, or · One clock signal available on the platform to
which PN722X NFCC is connected. A PLL inside PN722X NFCC
converts the input clock signal into an internal 27.12 MHz signal that
generates the RF carrier. The input clock frequency has to be one of the
predefined set of external input frequencies: 19.2 MHz, 24 MHz, 32 MHz and 48
MHz.
The DH configures the EEPROM parameter RF_CLOCK_CFG to set the clock source
used in the current application. For EEPROM_CFG CMD used to update the PLL
configuration defined in the data sheet, refer to Section 13.1.
Table 40.Clock sources supported
Name
Description
Xtal
To be selected when a 27.12 MHz quartz is used as a clock source
PLL
To be selected when an input clock is provided to PN722X NFCC, with a frequency equal to either
24 MHz, 32 MHz and 48 MHz.
To optimize the system power consumption, it may be required to switch OFF the
PLL input clock when the PN722X NFCC does not have to generate the 13.56 MHz
RF carrier, or to answer to a reader using ALM.
PN722X NFCC assumes that the PLL input clock is on and stable after a
programmable time-out. A specific parameter of PN722X is used to configure the
time-out. For EEPROM_CFG CMD used to update the PLL configuration defined in
the data sheet, refer to Section 13.1.
9.4 Protection mechanism against corrupted memory area (anti-tearing)
The PN722X NFCC tearing proof memory areas are:
· The User Area: standard Flash data memory area with CRC and with a secondary
area to duplicate its content.
· The Mirrored User Area: Subset of the mirrored Flash Data area with CRC and
with a secondary area to duplicate its content.
The mirrored Flash Data area is loaded in RAM always ON memory after power-on
reset and only the RAM always ON content is changed dynamically by the NFCC
during runtime.
The RAM always ON content is written back to Flash Data area only when the
host sends a specific NCI command FLUSH_SRAM_AO_TO_FLASH_CMD (see Table 29).
Each time the NFCC processes NCI CORE_INIT command, it checks if the CRC of
each protect area is valid. If the CRC is invalid, it gets overwritten by the
content of the secondary area. In this case, a generic error notification is
sent to inform the host: STATUS_NCI_USER_AREA_CRC_ERROR or
STATUS_NCI_USER_AREA_RECOVERY_ERROR (see Table 23).
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
60 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10 Poll side: reader/writer mode
10.1 Reader/Writer hosted by the DH
10.1.1 T2T, MIFARE Ultralight, MIFARE Classic and MIFARE Plus tags Note: All the Tags/Cards in this category are based on NFC-A technology, but they do not support the ISODEP Protocol. MIFARE Plus cards support the ISO-DEP protocol, but only when they are configured in Security Level3.
10.1.1.1 Access through the [NCI] Frame RF interface
[NCI] allows the data exchange with tags T2T using the Frame RF Interface.
Most of the commands of the MIFARE Classic and MIFARE Plus can also be mapped
on the Frame RF Interface. But NXP decided to use a separate RF interface
(TAG-CMD, see Section 10.1.1.2) because the MIFARE Classic Authenticate
command is split in two steps and has a tight response timeout (1 ms) which
can hardly be monitored by the DH through the NFCC.
Table 41 lists the tags/card based on technology NFC-A which can be accessed
through the Frame RF interface.
Table 41.Tag/cards accessible over the [NCI] Frame RF Interface Tag/card
T2T MIFARE Ultralight, Ultralight C MIFARE Classic MIFARE Plus for Security
levels 1 and 2
Access through the Frame RF Interface
… covered … not covered
Table 42 lists the commands and configuration parameters to prepare the Reader/Writer Mode for T2T through the Frame RF Interface.
Table 42.Configuration sequence for Reader/Writer of T2T through the Frame RF Interface
Command
Main Parameters
Values
RF_DISCOVER_MAP_CMD[1]
RF Protocol Mode
PROTOCOL_T2T Poll
RF Interface
Frame RF Interface
CORE_SET_CONFIG_CMD
PA_BAIL_OUT
RF_DISCOVER_CMD
RF Technology and Mode
NFC_A_PASSIVE_POLL_MODE
[1] RF_DISCOVER_MAP_CMD is optional since the mapping to Frame RF interface is done by default.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
61 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.2 [PN722X NFCC-NCI] extension: TAG-CMD interface
When the Sector Select command is required, the TAG-CMD implemented in PN722X
NFCC is limited to: · MIFARE Classic operation in Reader/Writer · T2T
operation in Reader/Writer Figure 34 represents the location of the TAG-CMD RF
interface.
Figure 34.TAG-CMD RF interface
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
62 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.3 [PN722X NFCC-NCI] extension: Payload structure of the TAG-CMD RF
interface
The TAG-CMD RF Interface uses the same data mapping as the one defined for the
[NCI] Frame RF Interface (see section 8.2.1 in [NCI]). For the TAG-CMD RF
Interface, the Payload is defined differently.
Two different structures are defined:
1. REQ (requests): commands from the DH to the NFCC. 2. RSP (responses):
responses from the NFCC to the DH.
Figure 35 details how the Payload is modified to insert the header with the
REQ ID or the RSP ID and some parameters, if required.
NCI data packet structure
Byte 0
Msg Type
Conn ID
Byte 0
REQs Frame structure
Msg Type
Conn ID
Byte 0
RSPs Frame structure
Msg Type
Conn ID
Byte 1 RFU Byte 1 RFU Byte 1 RFU
Byte 2
Payload Length
Byte 2
Payload Length
Byte 2
Payload Length
PAYLOAD
Byte 3 REQ ID
Byte 3 RSP ID
Byte 4
Byte 5
Parameter 1 Parameter 2
(optional)
(optional)
DATA (if any)
DATA (if any) Byte n
RF Status
Figure 35.Data message payload for the TAG-CMD interface
Note: REQs and RSPs do not share exactly the same structure:
REQs: Figure 35 shows two parameters, bur REQs may have no parameters or only
one. Some REQuests might also need parameters longer than 1 Byte. Parsing The
REQ ID is the way to know how many parameters follow and their length.
RSPs: there are no parameters in ReSPonses. A Byte is added at the end of the
payload (after the DATA field) to inform the DH on the RF status (to report RF
errors if they were some). TABLE lists the status codes.
Table 43.TAG-CMD RF status codes
Value
Description
0x00
STATUS_OK
0x03
STATUS_FAILED
0xB0
RF_TRANSMISSION_ERROR
0xB1
RF_PROTOCOL_ERROR
0xB2
RF_TIMEOUT_ERROR
Others
Forbidden
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
63 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.4 [PN722X NFCC-NCI] extension: REQs and RSPs rules A REQ command always goes from DH to RF, through the NFCC. An RSP response always goes from the RF to the DH, through the NFCC. The DH SHALL wait until it has received an RSP associated to a REQ before it can send a new REQ.
10.1.1.5 [PN722X NFCC-NCI] extension: List of REQs and RSPs
In this section, the following acronyms are used:
Table 44.Acronyms definition Acronym Description
MF
MIFARE family, not ISO-DEP compliant, including T2T, MIFARE Ultralight (std or C), MIFARE Classic, and
MIFARE Plus for Security Level 1 and 2.
MFC
MIFARE Classic and MIFARE Plus for Security Level 1 and 2.
The added REQuests/ReSPonses pairs are listed in the following table:
Table 45.List of REQuests and RESPonses
REQ/RSP Name
ID Param 1 Param 2 Param 3 Data Description
XCHG_DATA_REQ
0x10
None
None
None
Yes MFC: DH sends Raw data to the NFCC, which encrypts them before sending
them to MFC.
T2T: DH sends Raw data to the NFCC, which forwards them in plain to the Tag.
XCHG_DATA_RSP
N/A
N/A
0x10
N/A
Yes MFC: DH gets Raw data once RF data from
MFC are decrypted by the NFCC, if successful.
T2T: DH gets Raw plain data once the NFCC receives RF data from the Tag, if successful.
MF_SectorSel_REQ
0x32
Sector Address
None
None
No T2T and MFU only: DH sends the address of the Block to select.
MF_SectorSel_RSP
0x32 N/A
N/A
N/A
No T2T and MFU only: DH gets the “Sector Select”
response status
MFC_Authenticate_REQ 0x40 Sector Key
Key
No DH asks NFCC to perform MFC Authenticate
Address Selector (optional)
command.
MFC_Authenticate_RSP 0x40 N/A
N/A
No DH gets the MFC Authenticate command status
All these REQs and RSPs are detailed in the next sections.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
64 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.6 [PN722X NFCC-NCI] extension: raw data exchange REQs and RSPs
Table 46.XCHG_DATA_REQ
REQ_ID
REQ Name
0x10
XCHG_DATA_REQ
Number of parameter(s)
0
Presence of data
Description
MFC: DH sends Raw data to the NFCC, which
Yes
encrypts them before sending them to MFC. T2T: DH sends Raw data to the NFCC, which forwards
them in plain to the Tag.
Table 47.XCHG_DATA_RSP
RSP_ID
RSP Name
0x10 XCHG_DATA_RSP
Presence of Data
Description
MFC: DH gets Raw data once RF data from MFC are decrypted by the NFCC, if successful.
T2T: DH gets Raw plain data once the NFCC receives RF data from the
Yes
Tag, if successful. If the response from the MF tag in the field is an ACK or a NACK, the ACK/NACK is also sent back to the DH inside the Data field.
Since ACK and NACK are 4-bit commands, they are transported on the 4
LSBs of the data byte; the 4MSBs of that Byte are forced to the logical `0′
value.
10.1.1.7 [PN722X NFCC-NCI] extension: T2T and MFU REQs and RSPs
All the REQs and RSPs described in this section can be used whatever the tag
between:
· T2T · MIFARE Ultralight (Standard or C)
Table 48.MF_SectorSel_REQ
REQ_ID
REQ Name
0x32
MF_SectorSel_REQ
Number of parameter(s)
1
Presence of data
Description
No DH Sends the address of the Sector to select.
Table 49.MF_SectorSel_REQ parameter
Parameter
Length (Byte)
1 Sector Address
1
Value ?
Description
Defines the address of the sector which has to be selected. The address can be
any block address in this sector.
Table 50.MF_SectorSel_RSP
RSP_ID
RSP Name
0x32 MF_SectorSel_RSP
Presence of Data
Description
No DH gets sector select status
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
65 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.8 [PN722X NFCC-NCI] extension: MIFARE Classic REQs and RSPs
Table 51.MFC_Authenticate_REQ
REQ_ID
REQ Name
0x40 MFC_Authenticate_REQ
Number of parameter(s)
3
Presence of data
Description
No DH asks NFCC to perform MFC authenticate.
Table 52.MFC_Authenticate_REQ parameters
Parameter
Length (Byte)
Value
1 Sector Address
1
2 Key Selector
1
N/A
Description Address of the sector to authenticate
Bit Mask
Description
b7 b6 b5 b4 b3 b2 b1 b0
X
Key A (0′) or Key B (1′)
X
0 => use pre-loaded key
1 => use Key embedded
in the REQ (param Nbr 3)
X X X X Pre-loaded key number (0 to 15)
00
RFU
3 Embedded Key (optional)
6
N/A
This parameter is present in the MFC_Authenticate_CMD
only if bit b4 is set to logical `1′ in Key Selector parameter. If
present, this parameter defines the value of the Key used for
the authentication.
Table 53.MFC_Authenticate_RSP
RSP_ID
RSP Name
Presence of Data
Description
0x40 MFC_Authenticate_RSP
No
DH gets the “authenticate” cmd status
Table 54.TAG-CMD RF Status code, in the special case of MFC_Authenticate_CMD
Value
Description
Reason
0x00
STATUS_OK
Authentication was successful
0x03
STATUS_FAILED
Authentication failed (wrong key, time-out triggered during authentication etc.)
0xB0
RF_TRANSMISSION_ERROR
Not used
0xB1
RF_PROTOCOL_ERROR
Not used
0xB2
RF_TIMEOUT_ERROR
Not used
Others
Forbidden
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
66 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
Once a sector is authenticated, PN722X NFCC automatically encrypts any data
sent by the DH to be transferred over RF, using to the XCHG_DATA_REQ command.
The key used is the one used for the sector currently authenticated.
In a symmetrical way, PN722X NFCC automatically decrypts the data received
from RF before it forwards to the DH thanks to the XCHG_DATA_RSP response,
again using the key of the sector currently authenticated.
Figure 36 illustrates the use of the MFC_Authenticate_REQ and XCHG_DATA_REQ in
MIFARE Classic reader sequence.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
67 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
DH
NCI
NFCC
RF Endpoint
RF_DISCOVER_MAP_CMD (RF Prot. = MF_CLASSIC,Mode = Poll, RF Intf. = TAG-CMD, …)
RF_DISCOVER_MAP_RSP
RF_DISCOVER_CMD(NFC_A_PASSIVE_POLL_MODE, …) RF_DISCOVER_RSP
Map MIFARE Classic prot. to TAG-CMD Intf Start Discovery
(move to RFST_DISCOVERY)
RF Field On
NFCC activates the TAG-CMD intf: move to RFST_POLL_ACTIVE
RF_INTF_ACTIVATED_NTF (Prot = MF_CLASSIC, Intf = TAG-CMD.)
Activation sequence: driven by the NFCC
REQA/ATQA AntiColl CL1 SELECT/SAK
SAK shows MIFARE Classic with bit b4=1b (see AN10833).
Authentication to sector 0: triggered by DH, executed by NFCC
NCI_DATA_MSG
(MFC_Authenticate_REQ(Sect. Addr = 0, Key))
[MIFARE Authent.]_Plain
Token RB
CORE_CONN_CREDITS_NTF NCI_DATA_MSG(MFC_Authenticate_RSP)
Token AB_encrypted_Sect0 Token BA_encrypted_Sect0
NFCC encrypts/decrypts data using the key for sector 0
Commands sent by DH on Authenticated Sector 0
NCI_DATA_MSG(XCHG_DATA_REQ(MF_CMD1))
[MF_CMD1]_encrypted_Sect0
CORE_CONN_CREDITS_NTF
[MF_RSP1]_encrypted_Sect0
NCI_DATA_MSG(XCHG_DATA_RSP(MF_RSP1))
NCI_DATA_MSG(XCHG_DATA_REQ(MF_CMDn))
[MF_CMDn]_encrypted_Sect0
CORE_CONN_CREDITS_NTF
[MF_RSPn]_encrypted_Sect0
NCI_DATA_MSG(XCHG_DATA_RSP(MF_RSPn))
NFCC still encrypts/decrypts
Authentication to sector S: triggered by DH, executed by NFCC data using the key for sector 0
NCI_DATA_MSG
(MFC_Authenticate_REQ(Sect. Addr = S, Key))
[MIFARE Authent. Step1]_
encrypted_Sect0
CORE_CONN_CREDITS_NTF NCI_DATA_MSG(MFC_Authenticate_RSP)
[MIFARE Authent. Step2]_ encrypted_SectS
NFCC encrypts/decrypts data
Commands sent by DH on Authenticated Sector S
using the key for sector S
SEND DATA (XCHG_DATA_REQ(MF_CMD1))
[MF_CMD1]_encrypted_SectS
CORE_CONN_CREDITS_NTF SEND DATA (XCHG_DATA_RSP(MF_RSP1))
[MF_RSP1]_encrypted_SectS DH sends a HLTA cmd to close the MFC transaction
SEND DATA (XCHG_DATA_REQ(HLTA))
[HLTA]_encrypted_SectS
CORE_CONN_CREDITS_NTF SEND DATA (XCHG_DATA_RSP())
[NACK]_encrypted_SectS
RF_DEACTIVATE_CMD(Discovery) RF_DEACTIVATE_RSP
RF_DEACTIVATE_NTF
DH stops the communication by deactivating the TAG-CMD RF intf
RF Field OFF
Figure 36.MIFARE Classic Reader Sequence
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
68 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.1.9 Access through the TAG-CMD RF interface
The TAG-CMD RF interface allows full access to all the Tags based on NFC-A technology and not supporting the ISO-DEP protocol, leaving up to the PN722X NFCC to manage the low-level TAG-CMD.
Table 55.Tag/Cards accessible over the TAG-CMD interface Tag/Card
T2T MIFARE Ultralight, Ultralight C MIFARE Classic MIFARE Plus for Security
levels 1 and 2
Access through the TAG-CMD Interface
… covered
… not covered
Table 56 lists the commands and configuration parameters to prepare the
Reader/Writer Mode for T2T, and MIFARE Classic through the TAG-CMD interface.
Table 56.Configuration sequence for R/W of T2T and MFC through the TAG-CMD Interface
Command
Main Parameters
Values
RF_DISCOVER_MAP_CMD
RF Protocol (choose between the 2 PROTOCOL_T2T
possible protocols)
PROTOCOL_MIFARE_CLASSIC
Mode
Poll
CORE_SET_CONFIG_CMD
RF Interface PA_BAIL_OUT [1]
TAG-CMD —
RF_DISCOVER_CMD
RF Technology and Mode
NFC_A_PASSIVE_POLL_MODE
[1] This parameter is not active in PN722X: it can be read/written, but PN722X always behaves with Bail Out in NFC-A, whatever the value written by the DH to that parameter.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
69 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.2 T3T tag
[NCI] allows the data exchange with a tag T3T by using the Frame RF Interface.
A proprietary RF interface is not needed.
10.1.2.1 Access through the Frame RF interface
Table 57 lists the commands and configuration parameters to prepare the Reader/Writer Mode for T3T Tags/ Cards through the Frame RF Interface.
Table 57.Configuration sequence for Reader/Writer of T3T through the Frame RF Interface
Command
Main Parameters
Values
RF Protocol
PROTOCOL_T3T
RF_DISCOVER_MAP_CMD
Mode
Poll
RF Interface
Frame
PF_BIT_RATE
—
CORE_SET_CONFIG_CMD
PF_RC_CODE
—
RF_DISCOVER_CMD
RF Technology and Mode
NFC_F_PASSIVE_POLL_MODE
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
70 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.3 T4T and ISO-DEP tags/cards
[NCI] allows the data exchange with a T4T tag or an ISO-DEP tag by using the
Frame RF interface or the ISODEP RF interface. A proprietary RF interface is
not needed.
10.1.3.1 Access through the Frame RF interface
The Frame RF interface allows full access to all the tags based on NFC-A and NFC-B technology and supporting the ISO-DEP protocol, assuming that the ISO- DEP protocol is fully handled by the DH (Table 58).
Table 58.Tag/Cards accessible over the Frame RF Interface Tag/Card
T4T MIFARE DESFire MIFARE Plus for Security levels 3 JCOP-based smart cards
Access through the Frame RF Interface
Table 59 lists the commands and configuration parameters to prepare the Reader/Writer Mode for ISO-DEP Tags/Cards through the Frame RF Interface for technology NFC-A.
Table 59.Configuration sequence for R/W of NFC-A / ISO-DEP through the Frame RF interface
Command
Main Parameters
Values
RF_DISCOVER_MAP_CMD[1]
RF Protocol Mode
PROTOCOL_ISO-DEP Poll
RF Interface
Frame
CORE_SET_CONFIG_CMD
PA_BAIL_OUT
—
RF_DISCOVER_CMD
RF Technology and Mode
NFC_A_PASSIVE_POLL_MODE
[1] RF_DISCOVER_MAP_CMD is optional as the mapping to Frame RF Interface is done by default.
Table 60 lists the commands and configuration parameters to prepare the Reader/Writer Mode for ISO-DEP Tags/Cards through the Frame RF Interface for technology NFC-B.
Table 60.Configuration sequence for R/W of NFC-B / ISO-DEP through the Frame RF interface
Command
Main Parameters
Values
RF_DISCOVER_MAP_CMD[1]
RF Protocol Mode
PROTOCOL_ISO-DEP Poll
RF Interface
Frame
PB_AFI
—
CORE_SET_CONFIG_CMD
PB_BAIL_OUT
—
PB_SENSB_REQ_PARAM
—
RF_DISCOVER_CMD
RF Technology and Mode
NFC_B_PASSIVE_POLL_MODE
[1] RF_DISCOVER_MAP_CMD is optional as the mapping to Frame RF Interface is done by default.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
71 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.3.2 Access through the ISO-DEP RF interface
The ISO-DEP RF interface allows full access to all the Tags based on NFC-A and NFC-B technology and supporting the ISO-DEP protocol, leaving up to the PN722X NFCC to manage the ISO-DEP protocol (Table 61).
Table 61.Tag/Cards accessible over the ISO-DEP RF interface Tag/Card
T4T MIFARE DESFire MIFARE Plus for Security levels 3 JCOP-based smart cards
Access through the ISO-DEP RF Interface
Table 62 lists the commands and configuration parameters to prepare the Reader/Writer Mode for ISO-DEP through the ISO-DEP Interface for NFC-A technology.
Table 62.Configuration sequence for R/W of NFC-A / ISO-DEP through the ISO-DEP interface
Command
Main Parameters
Values
RF Protocol
PROTOCOL_ISO-DEP
RF_DISCOVER_MAP_CMD
Mode
Poll
RF Interface
ISO-DEP
PA_BAIL_OUT
—
CORE_SET_CONFIG_CMD
PI_BIT_RATE
—
RF_DISCOVER_CMD
RF Technology and Mode
NFC_A_PASSIVE_POLL_MODE
Table 63 lists the commands and configuration parameters to prepare the Reader/Writer Mode for ISO-DEP through the ISO-DEP Interface for NFC-B technology.
Table 63.Configuration sequence for R/W of NFC-B/ISO-DEP through the ISO-DEP interface
Command
Main Parameters
Values
RF Protocol
PROTOCOL_ISO-DEP
RF_DISCOVER_MAP_CMD
Mode
Poll
RF Interface
ISO-DEP
PB_AFI
—
PB_BAIL_OUT
—
CORE_SET_CONFIG_CMD
PB_H_INFO
—
PI_BIT_RATE
—
PB_SENSB_REQ_PARAM
—
RF_DISCOVER_CMD
RF Technology and Mode
NFC_B_PASSIVE_POLL_MODE
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
72 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
10.1.3.3 [PN722X NFCC-NCI] extension: WTX notification
After data is sent to the card/tag, an additional processing time may be required before the data response is sent. The wait time extension (WTX) request is used for the additional processing time. If WTX REQ/RESP exchange phase follows an NCI system notification, WTX is sent with a period of ~1.3 s.
Table 64.WTX_NTF
GID
OID
1111b
0x17
Numbers of parameter(s)
0
Description
Notification indicating that RF communication is in phase of WTX(RTOX)
REQ/RESP exchange for longer period
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
73 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
11 Listen side: Card emulation mode
11.1 Card Emulation hosted by the DH
11.1.1 ISO-DEP based on NFC-A
For Card Emulation hosted by the DH based on technology NFC-A, the PN722X NFCC
only supports the ISODEP protocol.
[NCI] defines all the mechanisms necessary to implement this feature. Two
options are possible:
1. The DH wants to manage by itself the ISO-DEP protocol, it SHALL then map
the ISO-DEP protocol on the Frame RF Interface. This is not supported by
PN722X device.
2. The DH leaves the ISO-DEP protocol management to the NFCC: it SHALL then
map the ISO-DEP protocol on the ISO-DEP interface.
11.1.1.1 Access through the ISO-DEP RF interface
Table 65 lists the commands and configuration parameters to prepare the ISO- DEP Card Emulation for technology NFC-A, in the DH, through the ISO-DEP RF Interface.
Table 65.Configuration sequence for ISO-DEP/NFC-A Card Emulation in the DH over ISO-DEP RF Interface
Command
Main Parameters
Values
RF Protocol
PROTOCOL_ISO-DEP
RF_DISCOVER_MAP_CMD
Mode
Listen
RF Interface
ISO-DEP
LI_A_RATS_TC1
—
CORE_SET_CONFIG_CMD
LA_HIST_BY
—
LI_BIT_RATE
—
RF_SET_LISTENMODE ROUTING_CMD
Technology-based routing Protocol-based routing
NFC_RF_TECHNOLOGY_A routed to DHNFCEE
PROTOCOL_ISO-DEP routed to DH-NFCEE
RF_DISCOVER_CMD
RF Technology and Mode
NFC_A_PASSIVE_LISTEN_MODE
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
74 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
12 RF Discovery (Polling Loop) management
Note: the RF Discovery is the name given by the NFC Forum to what was called
the Polling Loop on previous products.
12.1 RF Discovery functions
This section covers RF Discovery concepts applied for PN722X NFCC. [NCI]
defines the general RF state machine used for the NFC controller to discover
either cards or readers. The RF state machine includes RFST_DISCOVERY state
where the RF Discovery profile is applied.
In compliance with the standard, the PN722X NFCC supports the NFC Forum
polling activity, limited to the current technologies defined in the
standardization body (NFC-A, NFC-B, NFC-F, NFC-V).
In addition to these RF profiles, the PN722X NFCC offers a way to limit the
power consumption by applying an LPCD concept. The LPCD can be seen as a
precondition to enable a dedicated profile. It means that if the LPCD is
triggered, the default profile is automatically started. Note: [NCI] defines
the TOTAL_DURATION of the discovery period independently of the reader phases
applied. To simplify the implementation for PN722X NFCC, a timer is applied
only during the Listen/pause phase. Therefore, depending on the polling phase
configuration (one technology or more), the total duration can vary.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
75 / 141
NXP Semiconductors
12.1.1 RF Discovery state machine Figure 37 shows the [NCI] RF state machine
fully supported by PN722X.
UM11810
PN722X NFC controller
Figure 37.NXP RF state machine
Since the [NCI] RF State Machine is quite complex, it is presented slightly
differently in Annex A of the present document: The State Machine is drawn
depending on the RF interface to be used. See Section “Annex A: Details on RF
state machine” for further details. Note: As PN722X does not support Listen
Mode using the Frame RF Interface, it does not accept the RF_DEACTIVATE_CMD
(Sleep mode) or RF_DEACTIVATE_CMD(Discovery) in RFST_LISTEN_ACTIVE or
RFST_LISTEN_SLEEP.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
76 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
12.2 NFC Forum profile as defined in [NCI] The NFC Forum profile is the
implementation of the RF discovery activity as defined in the NFC Forum (see
[ACTIVITY] specification).
[NCI] implementation of PN722X only covers technologies NFC-A, NFC-B, NFC-F,
and NFC-V. So, the basic NFC Forum profile polls for these technologies only.
Furthermore, for NFC-F, only one bit rate is used during the polling phase.
This is configured thanks to the “Poll F parameter” PF_BIT_RATE as defined in
[NCI], section 6.1.3. So, the DH configures if NFC-F is polled at 212 kB/s or
at 424 kB/s, before it activates the discovery by sending the RF_DISCOVER_CMD
command.
Figure 38 represents the profile defined by the NFC Forum. The assumption is
that the DH has enabled the four technologies currently supported by the
product (NFC-A, NFC-B, NFC-F, and NFC-V) in Poll mode and Listen mode.
Listening phase
NFC-A NFC-B NFC-F NFC-V
Polling phase
Figure 38.RF Discovery NFC Forum profile (when there is no card/tag in the field)
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
77 / 141
NXP Semiconductors
UM11810
PN722X NFC controller
12.3 [PN722X NFCC-NCI] extension: Low-power card detector (LPCD) Mode
12.3.1 Description
The Low-Power Card Detector is an NXP proprietary extension, which is applied
in case the DH wants to reduce the power consumption.
The concept is to avoid using the Technology Detection Activity as defined in
[ACTIVITY], which implies to generate an RF Field for several tens of
milliseconds and to send technology-specific request commands to see if there
is a Card/Tag in the field to respond. The more technologies the PN722X NFCC
is configured to detect, the longer the RF Field is generated and the higher
the current consumption.
The LPCD is based on another concept, which only relies on the antenna
characteristics, not on valid responses from a Card/Tag. The antenna impedance
is influenced by the Card/tag which may enter into its proximity, due to the
magnetic coupling between the two antennas. The LPCD monitors the antenna
impedance to see if there is a significant variation. The variation is
interpreted as being caused by a Card/Tag being in proximity.
To achieve that, the LPCD periodically generates very short pulses of RF
Field, without any modulation, and measures some antenna characteristics
during this pulse. The time between these RF pulses is defined by the
Total_duration parameter, as specified in the NCI Configuration table.
When a Card/Tag enters the field, there is an antenna impedance variation. If
this variation is higher than a predefined threshold, the default Technology
Detection profile (NFC Forum) is automatically started. Next, the PN722X NFCC
sends technology-specific request commands, expecting a response since the
LPCD detected a change on the antenna impedance.
Note: The LPCD may also be triggered by a metal object, which can influence
the Antenna impedance in a similar way as a Card/Tag. The PN722X NFCC anyhow
detects that this object is not a contactless device since it immediately
starts sending contactless commands to check if a Card/Tag can respond.
The Low-Power Card Detector is configured and enabled/disabled with a specific
configuration parameter in EEPROM and can be configured by DH. Refer to
EEPROM_CFG CMD in Section 13.1. The command is used to update LPCD
configuration defined in the data sheet.
UM11810
User manual
All information provided in this document is subject to legal disclaimers.
Rev. 1 — 2 February 2024
© 2024 NXP B.V. All rights reserved.
78 / 141
NXP Semiconductors
Figure 39