NFC T4T – WTX timer not cancelled after nfc_t4t_response_pdu_send

[cpaula]

Hi,

I am working with the nRF54L15 on sdk-nrf 3.2.3 and I am experiencing an unexpected behaviour with the NFC T4T stack regarding WTX frame timing.

Here is the observed sequence:

• t = 0 ms: the PICC receives a command from the PCD
• t = 4.8 ms: the PICC answers with a WTX request
• t = 6 ms: the PCD acknowledges the WTX request
• t = 15 ms: the response is ready and sent by calling nfc_t4t_response_pdu_send function
• t = 83 ms: the PICC sends a WTX request (~77 ms after receiving the first WTX ACK)
• t = 84.2 ms: the PCD acknowledges the WTX request
• t = 84.3 ms: the PICC finally sends the response 

The response was ready at t = 15 ms, well before the FWT expiration at ~83 ms. I call nfc_t4t_response_pdu_send directly inside the NFC_T4T_EVENT_DATA_IND callback, and the function returns 0 (success). Despite this, the lib does not emit the response immediately — it still waits for the FWT to expire, sends a WTX, and only transmits the response after receiving the WTX acknowledge.

As far as I understand ISO 14443-4, the FWT is a maximum delay, not a mandatory one. The PICC is allowed to respond at any point before the FWT expires, and a WTX should only be necessary when more time is actually needed. There is no requirement to wait for the timer to fire.

My question is:

Is there a known reason why the nfc_t4t library does not interrupt the internal WTX timer and send the response frame immediately when nfc_t4t_response_pdu_send is called before the FWT expires? Any guidance or workaround would be greatly appreciated.

 

Thank you.

[Kenneth]

Hello,

I have asked internally if someone can take a look at what might be occurring here, I will let you know their feedback.

Kenneth

[Kenneth]

Hello,

After analyzing the scenario and code, they understand the root cause:

1. After the PCD (reader) sends a complete command block, the PICC’s (nRF54L15) NFC stack decides it may need more time than the negotiated frame-wait time allows before it can answer.

2. Before the NFC_T4T_EVENT_DATA_IND callback is executed, the PICC starts a Wait-Time-eXtension (WTX) exchange with the PCD: it sends a WTX-style frame and waits for the PCD’s acknowledgment.

   t = 4.8 ms: the PICC answers with a WTX request
t = 6 ms: the PCD acknowledges the WTX request

3. Shortly after initiating the WTX request, the NFC stack invokes the application (NFC_T4T_EVENT_DATA_IND). The PCD’s WTX acknowledgment may occur later on the link (e.g. ~6 ms in trace). The application may then build the response quickly and ask to send it.

4. While the WTX exchange is still considered active, the NFC stack does not put the application’s response on the air immediately. The nfc_t4t_response_pdu_send() function “buffers” that response and ties sending to later steps in the same WTX handshake. So even if the application is ready early, the air interface can still wait until that window behavior lines up with the next WTX step.

   t = 83 ms: the PICC sends a WTX request (~77 ms after receiving the first WTX ACK)
t = 84.2 ms: the PCD acknowledges the WTX request
   t = 84.3 ms: the PICC finally sends the response 

From the application’s point of view, the response is “ready” and “accepted” early because the nfc_t4t_response_pdu_send() returns 0, but the stack’s sequencing and buffering around WTX means the first bytes of the real response only go out after another WTX cycle (often close to when the frame-wait timer would have expired anyway). That diverges from the usual ISO-DEP expectation that FWT is only an upper bound and that you may answer as soon as you are ready, without being forced through extra WTX rounds.

Kenneth

[cpaula]

Hello Kenneth,

Thank you for the detailed analysis — it clearly explains why the stack behaves this way.

We now understand that the response is buffered until the WTX handshake completes, even when the application is ready well before the FWT expires. However, this behavior is a significant issue for us.

We are currently developing an application where end-to-end NFC transaction timing is critical. The extra WTX round adds ~77 ms of latency that we cannot absorb, as it directly impacts the overall transaction time with the PCD.

Given that ISO 14443-4 explicitly defines FWT as an upper bound — not a mandatory wait — we would like to ask:

1. Is there a planned fix or improvement in a future sdk-nrf release that would allow the stack to send the response immediately when nfc_t4t_response_pdu_send() is called before the FWT expires, bypassing the unnecessary WTX cycle?
2. In the meantime, is there any workaround available — such as a lower-level API, or a way to cancel/shorten the internal WTX timer from the application side?

Any guidance would be greatly appreciated.

Thank you.