1. Erick Macias & Josh Wyatt 02/19/2013
Initiator Peer to Peer (P2P) SNEP Operations using TRF7970A + MSP430 Training
Erick Macias & Josh Wyatt
02/19/2013
TI Confidential - Internal Only

2. Peer to Peer (P2P) SNEP Operation Overview
P2P SNEP example outline covered here includes:
NFC-F Protocol
NFC-DEP
SNEP
NDEF Message Format
Logical Disconnection Process
DP = NFCForum-TS-DigitalProtocol-1.0
LLP = NFCForum-TS-Logical_LinkProtocol
SNEP = NFCForum-TS-SNEP_1.0
This overview covers placing the TRF7970A in active initiator 424kbps and interacting with another NFC P2P device (in this case NFC Enabled Android OS based handset)
The SENSx_REQ (first command) determines the protocol to be followed. (NFCF or NFCA) and just like this command, the rest of the flow illustrated above and in presentation is following the NFC Forum Specifications (as listed beside each command). Once connection is established, data can flow in either direction, which is important as this is the power of the connectionless transport which Peer to Peer operation offers. This is a simplified flow illustrated above and one thing to know about here is that the SYMM PDUs can, and for the most part are, exchanged multiple times in between their respective command steps. This topic is covered in greater detail later in the presentation.

3. TRF7970A Configuration for P2P Active Initiator
In the TRF7970A controlling MCU code, create NFC_Initiator_InitLoop() in Initiator_p2p.c to initialize the TRF7970A as active 424kbps.
0x83 (Soft Init Direct Command), 0x80 (Idle Direct Command)
0x00 (Chip Status Control)  0x21 (RF output active, +5 V operation)
0x01 (ISO Control)  0x1B (Active 424 kbps)
0x09 (Modulator Control)  0x21
SYS_CLK (in this case 13.56MHz) out optional, based on system requirements
0x0B (Regulator Control)  0x87
0x14 (FIFO IRQ Level)  0x0F (RX high 96, TX low 32 bytes)
0x96 , 0x8F, 0x97 (Disable Decoder, Clear FIFO, Enable Decoder Direct commands)
The TRF7970A is a multi-protocol, multi-mode NFC/RFID transceiver IC. It must be configured for the desired mode of operation, so above we are configuring as Active P2P initiator, set to operate over the 424kbps.
See TRF7970A data sheet tables 5-5 and 5-7,

4. Interaction with an NFC enabled device
The typical NFC enabled device (i.e. an Android phone) is polling through different protocols in a “round robin” cycle (illustrated below):
In this case, we are the initiator, so we will send SENSF_REQ command to the handset or other NFC P2P device capable of NFC-F in the field.
We then follow the data and payload format outlined in the NFC Forum Digital protocol spec (Section 6.4, page 74, Figure 23)
Card Emulation
NFC Active
Type A
Type B
Type 424kpbs
Type 212kpbs
ISO 15693

5. 1. Send SENSF_REQ
SENSF_REQ (See Section 6.6, NFC Digital Protocol v1.0, Table 40) Byte # Description Value (hex)
0 Length 06
1 Command (DP, SENSF_REQ)
2:3 System Code (SC) FF FF (DP, Section , default)
4 Request Code (RC) 00 (DP, no system code information requested)
5 Time Slot Number (TSN) 03 (DP, Table 42, 4 time slots)
SENS_F is transmitted out, then EOTX IRQ is received and handled. FIFO is cleared, etc. (just like any other command being transmitted with the TRF7970A.)
SC - The System Code (SC) contains information regarding the NFC Forum Device to be polled for (e.g., the Technology Subset). (see Requirements 80 table in DP for more information)
RC - The Request Code (RC) is used to retrieve additional information in the SENSF_RES Response and Table 41 (page 76 in DP) specifies the RC code(s).
TSN - The Time Slot Number (TSN) is used for collision resolution and to reduce the probability of collisions.
The anticollision scheme is based on the definition of time slots in which NFC Forum Devices in Listen Mode are invited to respond with minimum identification data.
The NFC Forum Device in Poll Mode sends a SENSF_REQ Command with a TSN value indicating the number of time slots available.
Each NFC Forum Device in Listen Mode presents within the range of the Operating Field, and then randomly selects a time slot in which it responds.
The TSN byte set to 00h forces all NFC Forum Devices in Listen Mode to respond in the first time slot, and therefore, this TSN value is used if collision resolution is not used.

6. 2. Receive SENSF_RES
SENSF_RES (See Section 6.6.2, NFC Digital Protocol v1.0, Table 43) Byte # Description Value (hex)
0 Length (or 14, see note below on RD)
1 Command (SENSF_RES)
2:9 NFCID FE 6F 5D A 0F (for example)
10:11 PAD0 C0 C1
12:14 PAD1 C2 C3 C4
15 MRTICHECK C5
16 MRTIUPDATE C6
17 PAD2 C7
18:19 Request Data (RD) (only present when RC ≠ 00,sent in SENSF_REQ)
EORX ITRQ is received, and FIFO status register is read out for the SENSF_RES (response) (in this case this is 18 bytes…Register 0x1C = 0x12 = DEC 18)
Then the FIFO is reset, just like any other TRF7970A RX operation.
NFCID2 shown is for example, each device/session will have a different number returned here.
The NFC Forum Device MAY set PAD0 to a different value if configured for Type 3 Tag platform in a specific configuration. (the spec says this value must be set to FF FF otherwise)
The PAD1 format depends on the NFC-F Technology Subset for which the NFC Forum Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not use PAD1.
Coding of MRTICHECK depends on the NFC-F Technology Subset for which the NFC Forum Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not use MRTICHECK.
The MRTIUPDATE format depends on the NFC-F Technology Subset for which the NFC Forum Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not use MRTIUPDATE.
The PAD2 format depends on the NFC-F Technology Subset for which the NFC Forum Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not use PAD2.
Request Data (RD) is included in the SENSF_RES Response if requested in the RC field of the SENSF_REQ Command. The Request Data (RD) format depends on the NFC-F Technology Subset for which the NFC Forum Device in Listen Mode is configured.

7. 3. Send Attribute Request (ATR_REQ)
ATR_REQ (See NFC Digital Protocol, Section 14.6, Table 87) Byte # Description Value (hex)
NFC-DEP portion
0 Length (37 bytes)
1:2 Command D4 00 (ATR_REQ)
3:12 NFCID3I NFCID3I = 01 FE 6F 5D A 0F 00 00
13 DIDI 00
14 BSI 00
15 BRI 00
16 PPI 32 (max payload 254 bytes)
LLCP portion
17:19 LLCP Magic # D
20:22 TLV: Version # (v1.1)
23:26 TLV: MIUX (128 + MIU (1792) = 1920 bytes)
27:30 TLV: Services (WKS LLC Link Management)
31:33 TLV: LTO (500mSec timeout, Figure 22, LLP)
34:36 TLV: Option Param (Class 3) (Table 7, LLP)
Following the initialization and anti-collision procedure defined in [DIGITAL], the Initiator device sends the Attribute Request ATR_REQ command.
The format of the ATR_REQ SHALL be as shown in Figure 28 of the LLP Specification.
The Initiator SHALL include the NFC Forum LLCP magic number in the first three octets of the ATR_REQ General Bytes field.
All LLC parameters defined in Section 4.5 Table 6 for use in PAX PDUs that are to be exchanged SHALL be included as TLVs beginning at the fourth octet of the ATR_REQ General Bytes field.
The PAX PDU exchange described in the LLC link activation procedure (cf. Section 5.2) SHALL NOT be used. The ATR_REQ General Bytes field SHALL NOT contain any additional information.
NFCID3I is the NFC Forum Device identifier of the Initiator for the NFC-DEP Protocol.
The Initiator Device Identification Number (DIDI) is used to identify different Targets that are activated at one time. If multiple target activation is not used, the DIDI field is set to zero.
BSI and BRI indicate the bit rates in Active Communication mode supported by the Initiator in both transmission directions.
The coding of BSI and BRI is specified in Table 88 and Table 89 of the Digital Protocol Specification.
The PPI field indicates the Length Reduction field (LRI) and the presence of optional parameters. The format of the PPI byte is specified in Table 90 of the Digital Protocol Specification.
The NFC-DEP MAC component SHALL use the three octet sequence “46h 66h 6Dh” as the NFC Forum LLCP magic number.
This magic number is encoded into the ATR_REQ / ATR_RES General Bytes fields, as described below.
The use of the magic number by the Initiator and Target SHALL indicate compatibility with the requirements of this specification.
The link activation phase SHALL be started when a peer device capable of executing the LLCP peer-to-peer protocol enters communication range, and the local device is instructed to perform peer-to-peer communication.
The link activation phase is different for the Initiator and the Target device and is described separately for each role.

8. 4. Receive Attribute Response (ATR_RES)
ATR_RES (See NFC Digital Protocol Table 92, LLP Spec Section ) Byte # Description Value (hex)
NFC-DEP portion
0 Length 1F (31 bytes)
1:2 Command D5 01 (ATR_RES, fixed values)
3:12 NFCID3T NFCID3T = F DF C3 28 BD 9D 94 E0
13 DIDT 00
14 BST 00
15 BRT 00
16 TO 0E
17 PPT 32 (max payload 254 bytes)
LLCP portion
18:20 LLCP Magic # D
21:23 TLV: Version # (ver1.1)
24:27 TLV: Services (WKS LLC Link Management)
28:30 TLV: LTO (1.5 sec)
We send the ATR_RES which is based on the NFC Digital Protocol and the LLCP documents.
Following the initialization and anti-collision procedure defined in [DIGITAL], the Target device waits until the receipt of the Attribute Request ATR_REQ command.
Upon receipt of ATR_REQ the Target SHALL verify that the first three octets of the General Bytes field are equal to the NFC Forum LLCP magic number defined in Section
If the octet sequence is equal to the NFC Forum LLCP magic number, the Target responds by sending the Attribute Response ATR_RES, as defined in [DIGITAL].
The format of the ATR_RES SHALL be as shown in Figure 29 of the LLP Spec (page 43)
The Target SHALL include the NFC Forum LLCP magic number in the first three octets of the ATR_RES General Bytes field.
All LLC parameters defined in Section 4.5 Table 6 for use in PAX PDUs that are to be exchanged SHALL be included as TLVs beginning at the fourth octet of the ATR_RES General Bytes field.
The PAX PDU exchange described in the LLC link activation procedure (cf. Section 5.2) SHALL NOT be used.
Upon receipt of the Attribute Response ATR_RES the Initiator SHALL verify that the first three octets of the General Bytes field are equal to the NFC Forum LLCP magic number defined in Section
If the octets are equal to the NFC Forum LLCP magic number, the Initiator SHALL notify the local LLC component about the MAC link activation completion and SHALL then enter normal operation described in chapter If the first three octets of the General Bytes field are not equal to the NFC Forum LLCP magic number, the link activation SHALL fail.
In this case, any further communication between the Initiator and the Target is out of scope of this specification and left to implementation.
After sending ATR_RES the Target SHALL notify the local LLC component about the MAC link activation completion and SHALL then enter normal operation described in Section If the magic number in the received ATR_REQ cannot be verified, the link activation SHALL fail. In this case, any further communication between the Target and the Initiator is out of scope of this specification and left to implementation.

9. 5. Send DEP_REQ SYMM PDU
SYMM PDU (See Logical Link Protocol Tech Spec, Fig 4)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 06
1:2 Command D4 06 (DEP_REQ, Table 103, DP doc)
3 PFB 00 (info PDU, PNI 0, Table 105, DP doc)
LLCP portion
4:5 DSAP,PTYPE,SSAP (SYMM PDU)
The symmetry procedure provides the appearance of asynchronous balanced mode (ABM) communication on top of MAC layers operating in normal response mode (NRM) and enables link loss detection.
By performing the symmetry procedure, the peers mutually pass permission to send back and forth.
The link timeout (LTO) parameter allows each peer to determine when communication over the LLCP Link has become impossible.
After receipt of an LLC PDU, the receiving LLC SHALL commence sending an LLC PDU to the remote LLC within the time interval determined by the link timeout (LTO) parameter of the local LLC.
In case no other PDU can be sent, the LLC SHALL send a SYMM PDU prior to the expiration of the LTO of the local LLC.
After sending an LLC PDU, if reception of a PDU from the remote LLC does not commence within the time interval determined by the remote LLC’s link timeout (LTO) parameter, the local LLC SHALL execute the LLC link deactivation procedure (cf. Section 5.4).
Compliance to the symmetry procedure SHALL be verified by observing the communication traffic between the peer devices.
The initiator and the target can exchange asynchronous commands back and forth, incrementing the PNI value to ensure the two devices are still in proximity of one another.
The Packet Number Information (PNI) bit counts the number of packets sent by the Initiator to the Target, and vice versa, starting with 0.
note: can go up to 3 and start over at 0
These bits are used for error detection during protocol handling.
These PDUs can be sent back and forth as long as the connection exists, and are sent until either side wants to connect and send data.
This is analogous to Bluetooth™ operations where devices can be paired, but not connected yet.

10. 6. Receive DEP_RES SYMM PDU
SYMM PDU (See Logical Link Protocol Tech Spec, Fig 4)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 06
1:2 Command D5 07 (DEP_RES, Table 104, DP doc)
3 PFB 00 (info PDU, PNI 0, Table 105, DP doc)
LLCP portion
4:5 DSAP,PTYPE,SSAP (SYMM PDU)
Here we are showing the response to the SYMM PDU – note the PNI is 0

11. 7. Send DEP_REQ SYMM PDU
SYMM PDU (See Logical Link Protocol Tech Spec, Fig 4)
Byte # Description Value (hex)
NFC-DEP portion
0 Len 06
1:2 Command D4 06 (DEP_REQ, Table 103, DP doc)
3 PFB 01 (info PDU, PNI 1)
LLCP portion
4:5 DSAP,PTYPE,SSAP (SYMM PDU)
Here we are showing the next request SYMM PDU – note the PNI is 1

12. 8. Receive DEP_RES SYMM PDU
SYMM PDU (See Logical Link Protocol Tech Spec, Fig 4)
Byte # Description Value (hex)
NFC-DEP portion
0 Len 06
1:2 Command D5 07 (DEP_RES)
3 PFB 01 (info PDU, PNI 1)
LLCP portion
4:5 DSAP,PTYPE,SSAP (SYMM PDU)
Here we are showing the response to the SYMM PDU – note the PNI is 1, matching the request…this can go up to PNI = 3 and start over again, as long as the devices are in proximity of each other.

13. 9. Send CONNECT PDU
CONNECT PDU (See Logical Link Protocol Spec, Section 4.3.5, Fig 9)
Byte # Description Value (hex)
NFC-DEP portion
0 Len 1E
1:2 Command D4 06 (DEP_REQ)
3 PFB 01 ( info PDU, PNI 1) note: PNI value varies based on where process is
LLCP portion
4:5 DSAP,PTYPE,SSAP (CONNECT PDU)
6 Type 06 ( Service Name)
7 Length 0F
8:22 Service Name “urn:nfc:sn:snep”
23:26 TLV: MIUX
27:29 TLV: RWS
NOTE: (Section , LLP doc, this # can go up to 0F, which can increase throughput to the initiator)
The CONNECT PDU is an unnumbered PDU which is used to request a data link connection between a source and a destination service access point.
The information field of the CONNECT PDU MAY contain connection specific parameters.
These parameters SHALL be encoded as a contiguous sequence of TLV elements and each TLV element SHALL be encoded as defined in Section 4.4 of the LLP Spec.
The LLC parameters that are allowed in the information field of a CONNECT PDU are defined in Section 4.5 of the LLP Spec.
The receiver of a CONNECT PDU SHALL ignore any TLV elements that are not defined in Section 4.5 of the LLP Spec.

14. 10. Receive Connection Complete (CC) PDU
CC PDU (See Logical Link Protocol Spec, Section 4.3.7, Fig 11)
Byte # Description Value (hex)
NFC-DEP portion
0 Len 0A
1:2 Command D5 07 (DEP_RES)
3 PFB 02( info PDU, PNI 2)
LLCP portion
4:5 CC PDU (DSAP,PTYPE,SSAP) (DSAP = 20, PTYPE = 6, SSAP = 04)
6 Type 02 (Figure 20, LLP Spec)
7 Length 02 (Figure 20, LLP Spec)
8:9 MIUX (Maximum Information Unit Extension)
Important: This (the reception of the RECEIVE CC PDU) could be preceded by one or symmetry command/response pairs. This is to keep connection active until response is sent from target.
The CC PDU is an unnumbered PDU which is used by an LLC to acknowledge the receipt and acceptance of the CONNECT.
The information field of the CC PDU MAY contain connection specific parameters.
These parameters SHALL be encoded as a contiguous sequence of TLV elements and each TLV element SHALL be encoded as defined in Section 4.4. of the LLP Specification
The parameters that are allowed in the information field of a CC PDU are defined in Section 4.5 of the LLP Specification.
The receiver of a CC PDU SHALL ignore any TLV elements that are not defined in Section 4.5 of the LLP Specification.
The maximum information unit (MIU) is the maximum number of octets in the information field of an LLC PDU that the local LLC is able to receive. The default MIU is 128.
The maximum information unit extension (MIUX) parameter MAY be used by an LLC to announce the ability to receive LLC PDUs with information fields larger than the default.
The MIUX parameter MAY be transmitted during link activation to announce the local LLC’s larger Link MIU.
The MIUX parameter MAY be transmitted in the information field of a CONNECT or CC PDU to announce the local LLC’s larger MIU for that data link connection endpoint.
The MIUX parameter specifies the number of octets by which an information field MAY exceed the default maximum size. It SHALL be encoded as an 11-bit unsigned integer value according to the following formula: MIUX = MIU – 128
When the MIUX parameter is encoded as a TLV, the TLV Type field SHALL be 02h and the TLV Length field SHALL be 02h. The MIUX parameter SHALL be encoded into the least- significant 11 bits of the TLV Value field. The unused bits in the TLV Value field SHALL be set to zero by the sender and SHALL be ignored by the receiver.
The receiver of an MIUX parameter SHALL calculate the MIU value as follows: MIU = MIUX , so in the case above, the MIU = 248 bytes

15. 11. Send I PDU (SNEP mode)
I PDU (See Logical Link Protocol Spec, Section , Fig 14)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 2C (44 bytes)
1:2 Command D4 06 (DEP_REQ)
3 PFB 00 (info PDU, PNI 0)
LLCP portion
4:5 I_PDU (DSAP,PTYPE,SSAP) (DSAP 04, PTYPE = C, SSAP = 20)
6 Sequence 00
SNEP Request Message
7 SNEP Protocol Version 10 (SNEP v1.0)
8 Request Field 02 (Put – Section 3.1.2, SNEP)
9:12 Length F (31 bytes of payload)
See next slide for payload (NDEF Message)
The I PDU is a numbered PDU which is used to transfer service data units across a data link connection.
The format of the I PDU SHALL be as shown in Figure 14, where n is the length of the I PDU.
The Request field (Byte 8) indicates the action to be performed by the SNEP server. In this case we are sending 31 bytes to the Peer Target. (next slide)

16. 11. Send I PDU (SNEP mode, cont.)
NDEF Text Record Type
Byte # Description Value (hex)
13 Message Info D1 (Short record, NFC well-known RTD)
14 Length of Record Name 01
15 Payload Length 1B (27 bytes)
16 Payload Type 54 (‘T’ = Text)
17 Status byte 02 (UTF-8, 2 byte lang. code)
18:19 Language E (“en” = English)
20:43 Payload “NFC powered by Stollmann”
From RTD_Text v1.0, Appendix A

17. 12. Receive RR PDU
RR PDU (See Logical Link Protocol Spec Section , Fig 15)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 07
1:2 Command D5 07 (DEP_RES)
3 PFB 00 ( info PDU, PNI 0)
LLCP portion
4:5 PP PDU (DSAP=20,PTYPE=D,SSAP=04)
6 Sequence 01 (Sequence Number N(R))
The RR PDU is a numbered PDU which is used by an LLC to acknowledge one or more received I PDUs and indicate that the LLC is able to receive subsequent I PDUs.
The RR PDU SHALL have the format shown in Section , Figure 15 (page 23 of the LLP spec).
The RR PDU sequence field SHALL contain the receive sequence number N(R).
The receive sequence number N(R) SHALL indicate that I PDUs numbered up through N(R) - 1 have been received correctly by the sender of this I PDU and successfully passed to the senders SAP identified in the SSAP field.
These I PDUs SHALL be considered as acknowledged.
The higher nibble of the sequence field SHALL be set to zero by the sender and SHALL be ignored by the receiver.

18. 13. Receive I-PDU (SNEP mode)
I PDU (See Logical Link Protocol Spec, Section , Fig. 14)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 0D (13 bytes)
1:2 Command D5 07 (DEP_RES)
3 PFB 01 (info PDU, PNI 1)
LLCP portion
4:5 I_PDU (DSAP,PTYPE,SSAP) (DSAP 20, PTYPE = C, SSAP = 04)
6 Sequence 01
SNEP Response Message
7 SNEP Protocol Version 10 (SNEP v1.0)
8 Response 81 (Success, Table 3, SNEP)
9:12 Length (no information)
Most likely preceded by at least one SYMM command from Initiator, for larger payloads, the success I-PDU (0x81) would be replaced with a continue I-PDU (0x80) after the first packet.
The other packets just get acknowledged with an RR PDU, then the last one gets both RR and Success I-PDU.
The I PDU is a numbered PDU which is used to transfer service data units across a data link connection. The format of the I PDU SHALL be as shown in Figure 14, where n is the length of the I PDU.
The I PDU sequence field SHALL contain two sequence numbers: The send sequence number N(S) and the receive sequence number N(R).
The send sequence number N(S) SHALL indicate the sequence number associated with this I PDU.
The receive sequence number N(R) value SHALL indicate that I PDUs numbered up through N(R) - 1 have been received correctly by the sender of this I PDU and successfully passed to the senders SAP identified in the SSAP field. These I PDUs SHALL be considered as acknowledged.
The information field of an I PDU SHALL contain a single service data unit. The maximum number of octets in the information field SHALL be determined by the MIU for the data link connection as described in Section The information field of an I PDU MAY be empty.

19. 14. Send RECEIVE READY (RR) PDU
RR PDU (See Logical Link Protocol Spec Section , Fig 15)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 07
1:2 Command D4 06 (DEP_REQ)
3 PFB 02 ( info PDU, PNI 2)
LLCP portion
4:5 RR I-PDU (DSAP = 04,PTYPE = D,SSAP=20)
6 Sequence N(R) 01
To acknowledge the success I-PDU, replied to with a symmetry.
The RR PDU is a numbered PDU which is used by an LLC to acknowledge one or more received I PDUs and indicate that the LLC is able to receive subsequent I PDUs.
The RR PDU SHALL have the format shown in Section , Figure 15 (page 23 of the LLP spec).
The RR PDU sequence field SHALL contain the receive sequence number N(R).
The receive sequence number N(R) SHALL indicate that I PDUs numbered up through N(R) - 1 have been received correctly by the sender of this I PDU and successfully passed to the senders SAP identified in the SSAP field.
These I PDUs SHALL be considered as acknowledged.
The higher nibble of the sequence field SHALL be set to zero by the sender and SHALL be ignored by the receiver.

20. 15. Send DISCONNECT (DISC) PDU
DISC PDU (See Logical Link Protocol Spec, Section 4.3.6, Fig 10)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 06
1:2 Command D4 06 (DEP_REQ)
3 PFB 03 ( info PDU, PNI 3)
LLCP portion
4:5 DISC PDU (DSAP = 04,PTYPE = 5,SSAP = 20)
The DISC PDU is an unnumbered PDU which is used to terminate a data link connection or is used to deactivate the LLCP L
The DISC PDU SHALL have the format shown in Section 4.3.6, Figure 10 (page 19) in the LLP spec.

21. 16. Receive DISCONNECTED MODE (DM) PDU
DM PDU (See Logical Link Protocol Tech Spec Fig 12 and Table 3, Pages 15-16)
Byte # Description Value (hex)
NFC-DEP portion
0 Length 07
1:2 Command D5 07 (DEP_RES)
3 PFB 03 ( info PDU, PNI 3)
LLCP portion
4:5 DISC PDU 81 C4 (DSAP = 20,PTYPE = 7,SSAP = 04)
6 Reason 00
Note: Table 4, LLP, the Reason Byte indicates that the LLC has received a DISC PDU and is now logically disconnected from the data link connection.
The DM PDU is an unnumbered PDU which is used to report status indicating that the LLC is logically disconnected from the data link connection identified by the DSAP and SSAP address pair.
The DM PDU SHALL have the format shown in Section 4.3.8, Figure 12 (page 20) in the LLP spec.

22. Thank you

23. BACKUP SLIDES (these are older ones from NPP ops)

24. TRF7970A Configuration for P2P Target
See NFC_Target_InitLoop() in android_p2p.c
0x83 (Soft Init cmd)
0x80 (Idle cmd)
0x00 (Chip Status Control) – 0x21 (RF output active, 5 V operation)
0x01 (ISO Control) – 0x23 (Passive Target – 424 kbps)
0x09 (Modulator Control) – 0x21 (13.56 MHz)
0x0A (RX Special Settings) – 0x1C
0x0B (Regulator Control) – 0x01
0x14 (FIFO IRQ Level) – 0x0F ( RX high 96, TX low 32 bytes)
0x16 (NFC Low Detection) – 0x01
0x37 (NFCID) – 0x01, 0xFE, etc. (01 FE needed as first 2 bytes to indicated support of NFC-DEP protocol in the NFC-F SENSF_RES)
0x18 (NFC Target Level) – 0x86 (NFCID length of 10 bytes)
0x96 , 0x97 (Disable Decoder, Enable Decoder cmds)

25. Interaction with Android Handset
The Android phone polls through different protocols:
We will receive an IRQ for RX start (Register 0x1C – 0x40) and check the target protocol for Felica/NFC-F (0x59 – 0xD3). Else reset the TRF.
Card Emulation
NFC Active
Type A
Type B
Type 424 kpbs
Type 212 kpbs
ISO 15693

26. 1. Receive SENSF_REQ
SENSF_REQ (See NFC Digital Protocol Table 40) Bit # Description Value (hex)
0 Len 06
1 Command (SENSF_REQ)
2:3 SC FF FF (default)
4 RC 01 (System Code request)
5 TSN 01 (2 time slots)

27. 2. Transmit SENSF_RES
SENSF_RES (See NFC Digital Protocol Table 43) Bit # Description Value (hex)
0 Len / 14 ( See the Note below)
1 Command (SENSF_RES)
2:11 NFCIDt 01 FE etc. (NFC-DEP support)
12:13 PAD0 FF FF (don’t care)
14:15 PAD1 C2 C3 C4(don’t care)
17 MRTIcheck C5 (don’t care)
18 MRTIupdate C6 (don’t care)
19 PAD2 C7 (don’t care)

28. 3. Receive ATR_REQ
ATR_REQ (See NFC Digital Protocol Table 87) Bit # Description Value (hex)
NFC-DEP portion
0 Len 1E
1:2 Command D4 00 (ATR_REQ)
3:12 NFCIDi NFCID random #
13 DIDi 0
14 BSi 0
15 BRi 0
16 PPi 32
LLCP portion
17:19 LLCP Magic # D
20:22 TLV: Version # (ver 1.1)
23:26 TLV: Services (WKS LLC Link Management)
27:29 TLF: LTO (1.5s timeout)

29. 4. Transmit ATR_RES
ATR_RES (See NFC Digital Protocol Table 92) Bit # Description Value (hex)
NFC-DEP portion
0 Len 1C
1:2 Command D5 01 (ATR_RES)
3:12 NFCIDt NFCID of target
13 DIDi 0
14 BSi 0
15 BRi 0
16 TO 0E
17 PPi 32
LLCP portion
17:19 LLCP Magic # D
20:22 TLV: Version # (ver 1.0)
23:26 TLV: Services FF FF (all Services)

30. 5. Receive SYMM PDU
SYMM PDU (See Logical Link Protocol Tech Spec Fig 4)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 06
1:2 Command D4 06 (DEP_REQ)
3 PFB 00 ( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (SYMM PDU)

31. Communication flow once the NFC-DEP connection is established
To send message from MSP430 to phone:
(Phone in tag discovery/reader mode)
Receive SYMM.
Reply CONNECT.
Receive CC.
Reply I PDU with message.
Receive RR.
Send DISC.
Receive DM.
To receive message from phone on MSP430
(Phone in NDEF Push mode)
Receive CONNECT (once the screen is tapped).
Reply CC.
Receive I with message.
Reply SYMM.
Receive DISC.
Send DM.

32. 6. Transmit CONNECT PDU
CONNECT PDU (See Logical Link Protocol Tech Spec Fig 9)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 17
1:2 Command D4 07 (DEP_RES)
3 PFB 00 ( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (CONNECT PDU)
6 Type 06 ( Service Name)
7 Length 0F
8:22 Service Name “com.android.npp”

33. 7. Receive CC PDU CC PDU (See Logical Link Protocol Tech Spec Fig 11)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 06
1:2 Command D4 06 (DEP_REQ)
3 PFB 02( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (DSAP 21, SYMM PDU, SSAP 10)
6 Type 02 (MIUX)
7 Length 02
8:9 MIUX

34. 8. Transmit I PDU I PDU (See Logical Link Protocol Tech Spec Fig 14)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 26
1:2 Command D4 07 (DEP_RES)
3 PFB 02( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (DSAP 10, I PDU, SSAP 21)
6 Sequence 00
NPP Header
7 NPP Protocol Version 01
8:11 # of NDEF entries
NPP NDEF Entry
12 Action Code 01 (default)
13:16 NDEF Length

35. 8. Transmit I PDU (cont.) Bit # Description Value (hex) NDEF
17 Message Info D1 (Short record, NFC RTD)
18 Type Length 01
19 Payload Length 11
20 Payload Type 54 (‘T’ = Text)
21 Status byte 02 (UTF-8, 2 byte lang. code)
22:23 Language 65 6E (“en” = English)
24:37 Payload “Hello Android” (Text Message)

36. 9. Receive RR PDU RR PDU (See Logical Link Protocol Tech Spec Fig 15)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 07
1:2 Command D4 06 (DEP_REQ)
3 PFB 03 ( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (RR PDU)
6 Sequence 00 ( Sequence Number N(R) )

37. 8. Transmit PDU (cont.) Bit # Description Value (hex) NDEF
17 Message Info D1 (Short record, NFC RTD)
18 Type Length 01
19 Payload Length 11
20 Payload Type 54 (‘T’ = Text)
21 Status byte 02 (UTF-8, 2 byte lang. code)
22:23 Language 65 6E (“en” = English)
24:37 Payload “Hello Android” (Text Message)

38. 9. Transmit DISC PDU
DISC PDU (See Logical Link Protocol Tech Spec Fig 10)
Bit # Description Value (hex)
NFC-DEP portion
0 Len 06
1:2 Command D4 07 (DEP_RES)
3 PFB 03 ( info PDU, PNI 0)
LLCP portion
4:5 DSAP,PTYPE,SSAP (DISC PDU)