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

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 mode @ 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.

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 initiator @ 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 Initiator @ 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 air @ 424kbps. See TRF7970A data sheet tables 5-5 and 5-7, http://www.ti.com/lit/gpn/trf7970a

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 F @ 424kpbs Type F @ 212kpbs ISO 15693

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 00 (DP, SENSF_REQ) 2:3 System Code (SC) FF FF (DP, Section 6.6.1.1, 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.

2. Receive SENSF_RES SENSF_RES (See Section 6.6.2, NFC Digital Protocol v1.0, Table 43) Byte # Description Value (hex) 0 Length 12 (or 14, see note below on RD) 1 Command 01 (SENSF_RES) 2:9 NFCID2 01 FE 6F 5D 88 11 4A 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.

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 25 (37 bytes) 1:2 Command D4 00 (ATR_REQ) 3:12 NFCID3I NFCID3I = 01 FE 6F 5D 88 11 4A 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 # 46 66 6D 20:22 TLV: Version # 01 01 11 (v1.1) 23:26 TLV: MIUX 02 02 07 80 (128 + MIU (1792) = 1920 bytes) 27:30 TLV: Services 03 02 00 03 (WKS LLC Link Management) 31:33 TLV: LTO 04 01 32 (500mSec timeout, Figure 22, LLP) 34:36 TLV: Option Param 07 01 03 (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.

4. Receive Attribute Response (ATR_RES) ATR_RES (See NFC Digital Protocol Table 92, LLP Spec Section 6.2.3.2) 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 = F3 95 62 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 # 46 66 6D 21:23 TLV: Version # 01 01 11 (ver1.1) 24:27 TLV: Services 03 02 00 13 (WKS LLC Link Management) 28:30 TLV: LTO 04 01 96 (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 6.2.2. 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 6.2.2. 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 6.2.5. 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 6.2.5. 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.

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 00 00 (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.

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 00 00 (SYMM PDU) Here we are showing the response to the SYMM PDU – note the PNI is 0

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 00 00 (SYMM PDU) Here we are showing the next request SYMM PDU – note the PNI is 1

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 00 00 (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.

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 05 20 (CONNECT PDU) 6 Type 06 ( Service Name) 7 Length 0F 8:22 Service Name “urn:nfc:sn:snep” 23:26 TLV: MIUX 02 02 07 80 27:29 TLV: RWS 05 01 04 NOTE: (Section 5.6.2.2, 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.

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) 81 84 (DSAP = 20, PTYPE = 6, SSAP = 04) 6 Type 02 (Figure 20, LLP Spec) 7 Length 02 (Figure 20, LLP Spec) 8:9 MIUX 00 78 (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 = 128 + MIUX , so in the case above, the MIU = 248 bytes

11. Send I PDU (SNEP mode) I PDU (See Logical Link Protocol Spec, Section 4.3.10, 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) 13 20 (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 00 00 00 1F (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)

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 65 6E (“en” = English) 20:43 Payload “NFC powered by Stollmann” From RTD_Text v1.0, Appendix A

12. Receive RR PDU RR PDU (See Logical Link Protocol Spec Section 4.3.11, 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 83 44 (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 4.3.11, 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.

13. Receive I-PDU (SNEP mode) I PDU (See Logical Link Protocol Spec, Section 4.3.10, 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) 83 04 (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 00 00 00 00 (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 5.6.2.1. The information field of an I PDU MAY be empty.

14. Send RECEIVE READY (RR) PDU RR PDU (See Logical Link Protocol Spec Section 4.3.11, 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 13 60 (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 4.3.11, 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.

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 11 60 (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.

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.

Thank you

BACKUP SLIDES (these are older ones from NPP ops)

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)

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 F @ 424 kpbs Type F @ 212 kpbs ISO 15693

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

2. Transmit SENSF_RES SENSF_RES (See NFC Digital Protocol Table 43) Bit # Description Value (hex) 0 Len 12 / 14 ( See the Note below) 1 Command 01 (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)

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 # 46 66 6D 20:22 TLV: Version # 01 01 11 (ver 1.1) 23:26 TLV: Services 03 02 00 13 (WKS LLC Link Management) 27:29 TLF: LTO 04 01 96 (1.5s timeout)

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 # 46 66 6D 20:22 TLV: Version # 01 01 10 (ver 1.0) 23:26 TLV: Services 03 02 FF FF (all Services)

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 00 00 (SYMM PDU)

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.

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 05 21 (CONNECT PDU) 6 Type 06 ( Service Name) 7 Length 0F 8:22 Service Name “com.android.npp”

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 85 90 (DSAP 21, SYMM PDU, SSAP 10) 6 Type 02 (MIUX) 7 Length 02 8:9 MIUX 00 78

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 43 21 (DSAP 10, I PDU, SSAP 21) 6 Sequence 00 NPP Header 7 NPP Protocol Version 01 8:11 # of NDEF entries 00 00 00 01 NPP NDEF Entry 12 Action Code 01 (default) 13:16 NDEF Length 00 00 00 15

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)

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 87 50 (RR PDU) 6 Sequence 00 ( Sequence Number N(R) )

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)

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 41 31 (DISC PDU)