NFC PN544 NDEF 读取命令流程答案

【问题标题】：NFC PN544 NDEF read command flowNFC PN544 NDEF 读取命令流程
【发布时间】：2014-08-11 16:59:00
【问题描述】：

我正在使用 AS3953 来模拟 NFC 标签，并且已经能够使用带有 Broadcom 芯片组的三星 S4 或 Fame 读取简单的 NDEF 消息，现在我正在尝试让它与使用 NXP PN544 控制器的 HTC One SV 一起工作，

问题是，在我的标签将 NDEF 作为 Smarphone 的 READ-BINARY 的答案发送之后，它要求更多，也很奇怪，它从 0x00 开始读取 EF，而 Broadcom 设备从 0x02 开始读取，这对我来说更有意义，因为地址 0x00 和 0x01 包含之前已经读取过的大小信息，

这是 PN544 的正常行为吗？

感谢任何想法，安德烈亚斯

-- ADF_NAME SELECT
0x00: 0x02
0x01: 0x00
0x02: 0xA4
0x03: 0x04
0x04: 0x00
0x05: 0x07
0x06: 0xD2
0x07: 0x76
0x08: 0x00
0x09: 0x00
0x0A: 0x85
0x0B: 0x01
0x0C: 0x01
0x0D: 0x00
>>0x02,0x90,0x00

-- CC_SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x03
>>0x03,0x90,0x00

-- CC_READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00
0x05: 0x0F
>>      0x02,       // PCB
        0x00,0x0F,  // length of CC
        0x20,       // tag version 2.0
        0x00,0x3B,  // max length for read
        0x00,0x34,  // max length for write
        0x04,       // TLV  4:NDEF EF, 5:Propriety EF (more then one TLV block is allowed by NFC Forum)
        0x06,       //      length info
        0xE1,0x04,  //      NDEF file ID, values 0x0000,0xE102,0xE103,0x3F00,0x3FFF,0xFFFF are reserved
        0x10,0x00,  //      N-max,  max size of the file containing the NDEF message, valid range: 0005h to FFFEh
        0x00,0x00,  //      read/write permissions, 0x00: full access
        0x90,0x00); // OK 

NDEF-SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x04
>>0x03,0x90,0x00

NDEF-SIZE-READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00
0x05: 0x02
>> 0x02, 
   0x00,0x0D,   // length of NDEF message
   0x90,0x00);  // OK


NDEF-SELECT
0x00: 0x03
0x01: 0x00
0x02: 0xA4
0x03: 0x00
0x04: 0x0C
0x05: 0x02
0x06: 0xE1
0x07: 0x04
>>0x03,0x90,0x00

NDEF-READ
0x00: 0x02
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x00  <- why does it start from 0x00 ?
0x05: 0x0D
>>
    0x02,           // PCB header
    0xD1,           // NDEF header, sizeNDEF counts from here (not including the 2 trailing bytes) 
    0x01,           //      type length
    9,              //      payload length
    'T',            //      type, for example: 'T'=Text
    0x02,           //      payload: status bytes, UTF-8 ??
    'e','n',        //               language code, for example: "en"
    'h','e','l','l','o',0x0A,  //                text
    0x90,0x00 );    // OK

why does the Reader request more ??
0x00: 0x03
0x01: 0x00
0x02: 0xB0
0x03: 0x00
0x04: 0x0D
0x05: 0x3B

【问题讨论】：

标签： android nfc rfid apdu ndef

【解决方案1】：

决定将哪些命令发送到您的标签仿真的不是芯片。该决定是在中间件 NFC 堆栈中做出的。这些在 Broadcom 和 NXP PN544 芯片之间有所不同。

关于你看到的命令：按照标准回复即可。如果二进制读取命令失败，则返回正确的错误代码。

NFC 中间件可能会向您发送此命令，以查看是否有回复。它有时会这样做以检查标签是否仍在该字段中。您可能还会看到意想不到的奇怪命令，因为 NFC 堆栈正在探测非 100% NDEF 兼容且需要特殊解决方法的稀有或特殊标签（旧的 Mifare Desfire 标签是一个常见示例）。

【讨论】：

【解决方案2】：

我刚刚找到原因：带有 PN544（Android 4.1.2）的 HTC One SV 正在请求正确的 EF 长度，但请求以零偏移量开始，通常偏移量应为 0x02，因为前两个字节包含长度信息，这意味着来自标签的 apdu 答案不完整，消息的最后两个字节丢失。软件知道它并发送另一个读取请求以获取最后 2 个字节。我的 apdu 答案被硬编码为从偏移量 2 开始

【讨论】：