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]

thanks. The contents of the ATS seems to be important to have the specific card emulation recognised by readers.

While working on this aspect, I noted that the value of the SAK/SEL_RES returned during the initial connection phase is also important for card readers to identify card types (in particular when trying to emulate NXP MiFare cards of different generations, as per flowcharts in NXP AN10833).

I tried setting the SAK using the same function used to set the FWI, as there is a parameter for this (PARAM_SELRES!. I do this immediately after the nfc_t4t_setup() and nfc_t4t_emulation_start() calls:

if ((ret = nfc_t4t_parameter_set(NFC_T4T_PARAM_SELRES, &(ctx->sak_value), 1))!=0) {

                    log_cpwrn("nfc:t4tA selres set fails (%d)",ret);

                }

(ctx->sak_value is a uint8_t)

No error is returned, but if this call is done, then the NFC reader NEVER manages to connect to the nrf5340 : loops turning field on, then off immediately. If I remove just this call, it works fine (but with the SAK determined by the library). This appears to be the case for any value set here : eg I tried 0x00, 0x10, 0x19, 0x20 (which should be the default).

Can you also ask the library devs if this operation should work and under what conditions?

thanks

[Turbo J]

Type 2 uses a different command structure compared to type 4 tags, so you would have to write a completely new software stack IMHO.

Note that the NFC documentation is not public enough for me to check whether its possible to support Type 2 tag operations with nordic NFCT peripherial at all. Important docs are paywalled :-(

If you absolutely must support Type 2 tag operation its probably easier to use an external chip connected to a bus (like TWI).

[BrianW]

actually not that simple for nfc_t4t_parameter_set(NFC_T4T_PARAM_SELRES,..) : further testing shows it sometimes works, sometimes ignores, fails with -45 (if done before the setup call) or -22 if done after. I can't see the logic...

(note that my device enables/disables the NFC on command by calling stop or start as appropriate...)

And if it works and sets to 0x00, then my NFC reader is unable to talk to it... 

[BrianW]

Turbo J said:

ype 2 uses a different command structure compared to type 4 tags, so you would have to write a completely new software stack IMHO.

Ok, but my question is for type 4 emulation using the Nordic library.

Turbo J said:

Note that the NFC documentation is not public enough for me to check whether its possible to support Type 2 tag operations with nordic NFCT peripherial at all. Important docs are paywalled :-(

Well, they provide a type 2 emulation stack library in NCS; and you can create firmware that uses both (not at the same time obviously!). Haven't done much testing of type 2 myself.

Turbo J said:

If you absolutely must support Type 2 tag operation its probably easier to use an external chip connected to a bus (like T

Sure, but $$$ and my hw is already in production. I had previous hardware using the NXP PN7120 which was a good chip to be able to do both emulation and reader.... but its expensive and large...