0

Unable to get any response from CoreNFC when NDEF length is over 256 bytes and therefore requires the use of a 3-byte field versus a 1-byte field. I should note that tags can both be read on Android.

Can anyone else confirm this behavior or help me understand how to specify the file so CoreNFC will recognize and read the file?

So this works,

// TLV header
// Start of Type (T) field
0x03,         // This message contains an NDEF record
// End of Type (T) field

// Start of Length (L) field
// Length = payload length + length of value field
0xFE,         // Length field, adds 3 to account for length of value field when SR:1
// End of Length (L) field

// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:1,IL:0,TNF:101
0xD5,         // Short record false SR:1, 1-byte payload length, unknown type        
0x00,         // Type set to zero, as specified for unknown type
0xFB,         // Payload length
// End of Value (V) field
// End of TLV header

But this does not,

// TLV header
// Start of Type (T) field
0x03,         // This message contains an NDEF record
// End of Type (T) field

// Start of Length (L) field
// Length = payload length + length of value field
0xFF,         // Always 0xFF for SR:0, indicates length is between 256 and 65535
0x01,         // MSB of length field
0xF2,         // LSB of length field, adds 6 to account for length of value field when SR:0
// End of Length (L) field

// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:0,IL:0,TNF:101
0xC5,         // Short record false SR:0, 4-byte payload length, unknown type        
0x00,         // Type set to zero, as specified for unknown type
0x00,         // MSB of payload length, should be the exact size of the payload (data)
0x00,
0x01,
0xEC,         // LSB of payload length
// End of Value (V) field
// End of TLV header
navillus
  • 45
  • 6

1 Answers1

1

It turns out the issue was caused by a setting in the Compatibility Container. Apple can read both types of NDEF with CoreNFC, if you set the bit for "IC supports ReadMultipleBlocks Command" to false, it works without issue. We had it set to true. Here is an example of a CC that works with CoreNFC.

    // Start of Compatibility Container
0xE1,         // CC0, "Magic Number", NDEF message is present in memory
0x43,         // CC1, Version number 1.0, Read access enabled, Write access normally disabled
0x40,         // CC2, Memory size of data field and CC field in bytes divided by 8, 0x40 = 64, 64x8=512 Bytes
0x00,         // CC3, IC supports ReadMultipleBlocks Command
// End of Compatibility Container

Reading more from the IC documentation, although it does support ReadMultipleBlocks command, it does so in 128 Byte blocks. This may have been what caused the strange behavior we saw.

I still do not understand why Android handles it without issue, and Apple cannot read it. But changing the setting fixes the issue for CoreNFC.

navillus
  • 45
  • 6