Low level driver for NFCT using HAL NFC library only.

[eGate2022]

Dear All,

We need to develop a custom low-level driver for NFC communication using the Hardware Abstraction Layer (HAL) library exclusively. We are currently unable to use the recommended NFC library because we only have access to its binary distribution, which prevents us from implementing a necessary customization (e.g., configuring the WQTX repetition count beyond 5).

Our initial setup, utilizing only the NFC HAL library (<hal/nrf_nfct.h>), is functional regarding field detection (present/lost) and anti-collision.

The primary issue occurs immediately upon **frame reception**. The **reported EasyDMA data length is consistently 8190 bits** (a known corruption value). This length is clearly incorrect and indicates a fundamental configuration or synchronization issue at the driver level. Crucially, data reception works correctly when using the recommended, full-stack NFC library, which confirms the integrity of the underlying hardware platform (nRF5340). Moreover, no consistent data are received.

We suspect the solution involves an **undocumented hardware/software detail** or a **specific synchronization sequence** required to properly clean or restart the EasyDMA register or any other issue related to NFCT peripheral.

We are therefore requesting a **sample code implementation, utilizing the NFC HAL library exclusively**, that successfully **receives and correctly reports the data length of the first frame (RATS/ISO-DEP block) after the anti-collision phase**.

Best regards,
Alain

[Einar Thorsrud]

eI see. I do believe you, but I do not see how you can get 8190 in the RXD.AMOUNT. Can you share the exact raw value you read form RXD.AMOUNT a debugger in form of a screenshot or something similar? The reason is that this consists of two parts, adding up bytes and bits, and I do not see how you get get this value.

[eGate2022]

Hi,

I got an explanation about this meaningless value (8190). After the ISO 14443 selection, the PCD is supposed to send RATS, but we received 7 bits. In the HAL handler, there is the computation of the received length using the following function:

NRF_STATIC_INLINE uint16_t nrf_nfct_rx_bits_get(NRF_NFCT_Type const * p_reg, bool crc_excluded) { uint16_t rx_bits = p_reg->RXD.AMOUNT & (NFCT_RXD_AMOUNT_RXDATABITS_Msk | NFCT_RXD_AMOUNT_RXDATABYTES_Msk); return (uint16_t)(rx_bits - (crc_excluded ? (8u * NRF_NFCT_CRC_SIZE) : 0)); }

The RATS is supposed to have a CRC, so the content of the NFCT register should be 0x18 (3 bytes = 24 bits).

Nevertheless, the HAL code is not protected: if the bit count is 7, then the number of bytes is 0. 0 - 2 (CRC size) = -2, which becomes 0x1FFE (8190) due to uint16_t underflow.

The problem is still open, why I cannot receive the RATS?

Best regards, Alain

[eGate2022]

Hi,

I found the issue: it was related to the protocol selection parameter. I needed to use NRF_NFCT_SELRES_PROTOCOL_NFCDEP_T4AT instead of NRF_NFCT_SELRES_PROTOCOL_NFCDEP.

Now I receive frames correctly, and the problem is resolved.

Thank you for your help!

Regards,
Alain

nrfx_nfct_param_t sel_res_param = {

.id = NRFX_NFCT_PARAM_ID_SEL_RES,

.data.sel_res_protocol = NRF_NFCT_SELRES_PROTOCOL_NFCDEP_T4AT

};

nrfx_nfct_parameter_set(&sel_res_param);

[Einar Thorsrud]

Hi Alain,

I am glad to hear. Thank you for letting us know!

Best regards,

Einar