This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Leading Byte in NFC NDEF APDUs

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

Parents
  • 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

  • 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

Reply
  • 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

Children
No Data
Related