Leading Byte in NFC NDEF APDUs

RE: Leading Byte in NFC NDEF APDUs

Mik — Fri, 01 Dec 2017 10:57:34 GMT

Hi Michal, I've tested with SDK 14.2.0 and it works fine with CID enabled in the reader. I will migrate to this SDK or just use the Lib from this SDK. This will work for us. Thanks for the answers and the great nordic support!

Kind reagrds Michael

RE: Leading Byte in NFC NDEF APDUs

Michal — Fri, 01 Dec 2017 10:13:01 GMT

Hi Michael, ok I can see the point, our ATS response declares CID support which is true for all CID value execpt 0. The reason is, that in most readers when the CID equals 0 it is omitted from the APDUs so our library didn't handle it. We fixed this behavior in SDK 14.0.0, so either you can migrate to this version (actually you should be able to just take the nfc_t4t_lib_xxx.lib and hal_nfc_t4t.c from SDK 14.0.0), or maybe you could force the reader to use a non-zero CID value, which our library should just handle correctly.

Unfortunately there is no way to change the ATS response in our library.

Best regards, Michał

RE: Leading Byte in NFC NDEF APDUs

Mik — Fri, 01 Dec 2017 09:04:12 GMT

Hi Michal, i got a feedback from the reader manufacturer and it seems it's a problem of the ATS command. The Nordic chip responds to ATS (APDU: FF CC 00 00 01 93) with 05 78 80 42 02 90 00 indicating to support CID, which is then used by the reader. When CID in the reader is disabled, the reader works fine. Is there a way to change the ATS response of the Nordic chip?

kind regards Michael

RE: Leading Byte in NFC NDEF APDUs

Mik — Wed, 29 Nov 2017 13:17:29 GMT

Hi Michal, thanks for your response, Yes the used reader doesn't have the leading byte and we will now check with the manufacturer where this behavior comes from.

kind regards Michael

RE: Leading Byte in NFC NDEF APDUs

Michal — Wed, 29 Nov 2017 12:43:02 GMT

Hi, the alternating byte with values 0x02 and 0x03 is correct and expected, it is an "SoD" field of a Block defined by the ISO-DEP transmission protocol (NFC Forum Digital specification v. 2.0, section 16).

So answering your questions directly:

This byte is received over NFC.
This is part of the ISO-DEP protocol as described above

Regarding your problem description, I confirm, you should be able to see the NFC APDUs using nrf_log as you described. They are encapsulated in the mentioned ISO-DEP protocol so to analyze the APDUs you can disregard the "leading bytes". When you say:

The only difference to the identive reader is an additional leading byte

Do you mean: the reader which fails to read the nRF52 tag doesn't send the mentioned leading byte? Then this is probably the answer why the read operation is failing. Reading a Type 4 Tag requires using the ISO-DEP protocol. The nRF5 SDK Type 4 Tag examples won't work if the reader doesn't use ISO-DEP.

Best regards, Michal