Using nfc on nrf5340 to do type 4 card emulation, how can I set the ATS bytes for the RATS request from a reader?

[BrianW]

Hi

I have custom nrf5340 based product, with an NFC interface for card emulation. I have managed to get this to work in raw APDU mode in NCS 2.9.0 (with selected cherry picked patches from NCS 3.0.x to get the message exchanges to work)

Now I find that my card emulation fails to be recognised for some PC/SC applications, apparently because the ATS value returned to the reader after a RATS message is not what it expects (as this is used by the reader to make up the ATR for the PC/SC application it seems).

I had hoped to have a parameter to set in the nfct4tlib using nfc_t4t_parameter_set()  eg like this:

        // No access to set ATS in T4T lib?

        int ret = nfc_t4t_parameter_set(NFC_T4T_PARAM_ATS???, ats, atslen);

        if (ret==0) {

            return true;

        }

But there is no NFC_T4T_PARAM for ATS setting defined in nfc_t4t_lib.h

Am I missing something, or is there another way to respond to the RATS message myself? I handle the subsequent APDUs received via the callback with NFC_T4T_EVENT_DATA_IND : but I don't think I get the RATS message to handle here?

 thanks

Brian

[Benjamin]

Hi Brian,
There doesn't seem to be a way to set this, as the ATS response is handled internally by the precompiled library and is not exposed through the API. I will check internally to see if there is a workaround and get back to you.

Best regards,
Benjamin

[BrianW]

hi benjamin, no response from the dev team?

thanks

[Benjamin]

Hi Brian,

Yes, I have talked to the developers now and they have looked at your issue.

The library handles the full activation sequence internally - anti-collision, SELECT, RATS/ATS, and ISO-DEP bring-up - before any application data appears. In raw APDU mode, NFC_T4T_EVENT_DATA_IND delivers ISO-DEP I-block APDUs only, the RATS is not passed to any callback.

The ATS response is generated inside the library stack and is not configurable through the public API.

Why do PC/SC applications care? Contactless cards do not present a classic contact-style ATR. PC/SC readers synthesize a virtual ATR for ISO14443-4 Type A cards, and the ATS bytes become the ATR historical bytes (PC/SC interface for smart cards). If an application expects a specific card profile, it may reject the reader connection based on that ATR - even when raw APDU exchange works on other interfaces. That aligns with what you see.

Also two mistakes are made:

1. The SELRES should be set after setup  nfc_t4t_setup() but before emulation start nfc_t4t_emulation_start().
2. The SELRES correct value is 0x01 for T4T (nrf_nfct.h#L358).

Also, the SELRES should not be changed in run-time, only NFC_T4T_PARAM_NFCID1 can be changed after emulation starts.

Best regards,
Benjamin