I'm using an AS3953 to emulate an NFC Tag, and was already able to read out a simple NDEF message using Samsung S4 or Fame with Broadcom chipsets, now I'm trying to make it work with a HTC One SV which is using NXP PN544 controller,
the problem is that after my Tag sends the NDEF as an answer to a READ-BINARY from the Smarphone, it is requesting even more, it's also strange, that it is reading the EF starting from 0x00 while the Broadcom devices start reading from 0x02, which makes more sense to me because address 0x00 and 0x01 contain the size information, which already has been read before,
is this the normal behaviour for PN544 ?
Thx for any ideas, Andreas
-- 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
It is not the chip that is deciding what commands get sent to your tag-emulation. That decission is made in the middle-ware NFC stack. These differ between Broadcom and NXP PN544 chips.
Regarding the command that you see: Just answer back according to the standard. If the binary-read command fails, then return a proper error-code.
The NFC middleware may send you this command just to see if an answer comes back. It sometimes does this to check if the tag is still in the field. You may also see strange commands that you don't expect because the NFC-stack is probing for rare or special tags that aren't 100% NDEF compatible and need special work-arounds (Old Mifare Desfire tags are one common example).