nRF54L15: NFC T4T raw ISO-DEP peripheral stalls/deadlocks after invalid length check or mid-transaction error

[Antonysachin]

Environment

• SoC / Target: nRF54L15 (nrf54l15dk/nrf54l15/cpuapp)
• NCS Version: v3.4.0
• Library Configuration: CONFIG_NFC_T4T_NRFXLIB=y, CONFIG_NFC_T4T_ISODEP=y (Raw ISO-DEP mode)
• Thread Model: CONFIG_NFC_THREAD_CALLBACK=y, CONFIG_NFC_OWN_THREAD=y
• Poller / Reader: Tested with Android smartphones

Description

I am implementing a custom NFC Type 4 Tag application running in raw ISO-DEP mode on the nRF54L15. The tag is configured using nfc_t4t_setup() (without setting an NDEF payload) and started via nfc_t4t_emulation_start().

The application enables the dedicated NFC platform thread (CONFIG_NFC_OWN_THREAD=y) to deliver events. The registered callback validates the incoming frame length and posts valid APDU payloads to a separate processing worker thread using a message queue.

The Problem

During testing with an NFC reader (for example, during fast polling, transaction bursts, or when the reader pulls away), the callback receives an invalid length condition where
(data_length == 0).

Once this condition occurs, the NFC peripheral completely ceases to work:

1. With Error Response: If the callback attempts to send an error response status word (via nfc_t4t_response_pdu_send()), the tag locks up and stops responding to any further communication.
2. Without Error Response: If sending an error response is omitted and the callback simply returns when data_length == 0, the tag still becomes unresponsive.
3. Peripheral Stall: Once stalled, subsequent taps from the phone are ignored. The peripheral stops generating NFC_T4T_EVENT_FIELD_ON (only NFC_T4T_EVENT_FIELD_OFF is observed, or no events at all), and the tag remains dead until a full SoC reboot.

Configuration Highlights

• CONFIG_NFC_T4T_ISODEP=y
• CONFIG_NFC_T4T_NRFXLIB=y
• CONFIG_NFC_T4T_APDU=y
• CONFIG_NFC_THREAD_CALLBACK=y
• CONFIG_NFC_OWN_THREAD=y
• CONFIG_NFC_RING_SIZE=256
• CONFIG_NFC_LIB_CTX_MAX_SIZE=64

Questions

1. In raw ISO-DEP mode, what is the expected handling if NFC_T4T_EVENT_DATA_IND delivers a frame with data_length == 0? Must the application still call nfc_t4t_response_pdu_send(), or does a zero length indicate ring buffer or framing corruption?
2. Can CONFIG_NFC_LIB_CTX_MAX_SIZE=64 cause incoming APDUs larger than 64 bytes to corrupt or truncate within the NFC platform ring buffer, leading to invalid or zero-length indications?
3. On nRF54L15 in NCS v3.4.0, is this stall related to known NFCT field-tear and re-arming issues where the peripheral fails to generate FIELD_ON after an incomplete transaction?
4. What is the recommended recovery or reset sequence to safely handle an invalid APDU or mid-transaction abort without requiring a full SoC cold reboot?

[Amanda Hsieh]

Hi, 

I am working on your case and will update it once I have enough information. 

Regards,
Amanda H.

[Amanda Hsieh]

Hi, 

Could you provide a simple project to help reproduce the issue?

-Amanda H.

[Amanda Hsieh]

Hi, 

In raw ISO-DEP mode, what is the expected handling if NFC_T4T_EVENT_DATA_IND delivers a frame with data_length == 0? Must the application still call nfc_t4t_response_pdu_send(), or does a zero length indicate ring buffer or framing corruption?

Zero-length DATA_IND in raw ISO-DEP: After the fix, the platform delivers a consistent zero-length indication. Handling (ignore, log, or protocol-specific error response) remains application responsibility, the previous hard stall was caused by ring corruption in the platform thread, not by a requirement to always send a response PDU for data_length == 0.

Can CONFIG_NFC_LIB_CTX_MAX_SIZE=64 cause incoming APDUs larger than 64 bytes to corrupt or truncate within the NFC platform ring buffer, leading to invalid or zero-length indications?

CONFIG_NFC_LIB_CTX_MAX_SIZE=64: This limits the size of the NFC library context copied through the ring, not the APDU payload length. It is not identified as the cause of zero-length indications in this case.

On nRF54L15 in NCS v3.4.0, is this stall related to known NFCT field-tear and re-arming issues where the peripheral fails to generate FIELD_ON after an incomplete transaction?

nRF54L15 FIELD_ON / re-arming: Observed behaviour is consistent with the platform ring-buffer fault path on the NFC thread. Recommend verification with PR 31543 before treating as a separate NFCT field-tear issue.

What is the recommended recovery or reset sequence to safely handle an invalid APDU or mid-transaction abort without requiring a full SoC cold reboot?

Recovery without cold reboot: With fixed platform handling, the tag should remain operational after invalid/zero-length events. If the ring was already corrupted on unfixed firmware, full SoC reset may still be required once.

Regards,
Amanda H.