NXP Semiconductors PN722X Controller Development Kit User Manual

June 17, 2024
NXP Semiconductors

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

References

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>

NXP Semiconductors User Manuals

Related Manuals