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