Question

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

问题是，在我的标签发送NDEF作为Smarphone的READ-BINARY的答案后，它正在请求更多，同样奇怪的是，当Broadcom设备从0x02开始读取时，它正在从0x00开始读取EF，这对我来说更有意义，因为地址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

Answer 1

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

关于您看到的命令：根据标准回答。如果binary-read命令失败，则返回正确的错误代码。

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

Answer 2

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

NFC PN544 NDEF读取命令流程

2 个答案: