Leading Byte in NFC NDEF APDUs

[Mik]

Hi, We are testing with the experimental_writable_ndef_msg example from SDK12.2.0 and we have issues reading the nordic NRF52 Hardware using the PC-Card Reader identive uTrust3700F with the PCSC card interface under windows 8. We have added NRF_LOG_HEXDUMP_INFO in the hal_nfc_4t4.c file to see the received and send data. In this hexdump we would like to see the NFC APDUs e.g. "NDEF Application select" or "Ndef read". Reading the Tag works with an android phone and the PCSC card reader ACR122. The only difference to the identive reader is an additional leading byte, which alternates between 0x02 and 0x03. In the hal_nfc_4t4.c file i can see the leadung byte m_nfc_rx_buffer[0] in the NFCT_IRQHandler() with a special role.

My question are: 1.) is this byte received over NFC? 2.) If this byte is not received via NFC, where does it come from and what does it mean?

thanks

[Michal]

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:

1. This byte is received over NFC.
2. 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

[Mik]

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

[Mik]

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

[Michal]

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ł

[Mik]

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