**[Bug report] nRF54L15 NFC T4T: peripheral stalls after APDU transaction — only FIELD_OFF events received, never FIELD_ON**
**Environment**
- SoC: nRF54L15 (TrustZone non-secure context)
- NCS version: v3.2.1
- Zephyr: v4.2.99
- nrfxlib: bundled with NCS v3.2.1 (NFC binary library, nfc_t4t.a)
- NFC stack: nfc_t4t (Type 4 Tag emulation, closed binary)
- NFC reader: tested with multiple Android phones (Pixel, Samsung)
---
**Description**
After a complete or partial APDU transaction over NFC T4T, the NFCT peripheral enters a stall state. Once stalled, the application callback (registered via `nfc_t4t_setup()`) receives only `NFC_T4T_EVENT_FIELD_OFF` events when the NFC reader applies its field. The expected `NFC_T4T_EVENT_FIELD_ON` event is never generated, and no further NFC sessions are possible without a full device reboot.
---
**Steps to reproduce**
1. Initialize NFC T4T with `nfc_t4t_setup()` and `nfc_t4t_emulation_start()`.
2. Bring an NFC reader (Android phone) close to the device.
3. Allow a full or partial APDU exchange to occur (e.g. SELECT NDEF, READ BINARY, or incomplete transaction due to reader pulling away).
4. Remove the reader, then bring it back close again.
5. Observe: FIELD_ON callback is never fired. Only FIELD_OFF is received on subsequent field applications. Device requires reboot to recover.
---
**Expected behaviour**
After each NFC session ends (FIELD_OFF), the peripheral should re-arm field detection and generate FIELD_ON on the next reader approach, allowing a new session to begin normally.
**Actual behaviour**
After the stall, the peripheral appears to detect field loss (fires FIELD_OFF) but never re-arms for field-on detection. FIELD_ON is never delivered to the application callback for the lifetime of the firmware run.
---
**Attempted workarounds**
```c
// 1. Full re-init via work queue on stall detection — does NOT recover:
static void nfc_reinit_handler(struct k_work *work)
{
nfc_t4t_emulation_stop();
nfc_t4t_done();
k_msleep(100);
nfc_t4t_setup(nfc_callback, NULL);
// re-register NDEF message
nfc_t4t_emulation_start();
}
// 2. stop()/start() cycle on every FIELD_OFF — does NOT recover:
case NFC_T4T_EVENT_FIELD_OFF:
nfc_t4t_emulation_stop();
nfc_t4t_emulation_start();
break;
// 3. Direct NFCT register reset after nfc_t4t_done() — does NOT recover:
NRF_NFCT_NS->TASKS_DISABLE = 1;
k_msleep(10);
NRF_NFCT_NS->ERRORSTATUS = 0xFFFFFFFF;
NRF_NFCT_NS->FRAMESTATUS.RX = 0xFFFFFFFF;
NRF_NFCT_NS->TASKS_SENSE = 1;
```
None of the above restore normal operation. The stall persists until the device is power-cycled or rebooted.
---
**Questions for Nordic**
1. Is this a known issue with the nrfxlib NFC binary on nRF54L15 (NCS v3.2.1)?
2. Is there a supported API or sequence to fully reset the NFCT peripheral state from application code, given that the IRQ handler is owned by the binary library?
3. Does the nrfxlib binary on nRF54L15 apply the NFCT errata workarounds equivalent to those documented for nRF52840 (Errata 98, 190)?
4. Is there a patched nrfxlib version or NCS patch available that addresses this stall?
---
**Additional notes**
The issue is consistently reproducible with fast NFC readers (Android phones with aggressive polling). The stall appears to be triggered more reliably when the reader withdraws mid-transaction. Because the NFC IRQ handler is entirely inside the closed nrfxlib binary, we have no visibility into the internal NFCT state machine and cannot apply low-level workarounds independently.
