[NCS 2.6.1] NFC T4T response timing

[kartapusse]

Hi,

I am trying to use nfc_t4t_lib and I have some issues because processing incoming data takes some time (around 100 ms) and therefore sending the response occurs late after receiving the command.

There is a similar post but in my case, I am not using BLE at the same time, thus it is not exactly the same: devzone.nordicsemi.com/.../nfc-t4t-response-timing-sdk-15-3

If I have a delay (> 4 ms) after NFC_T4T_EVENT_DATA_IND, 

• nfc_t4t_response_pdu_send() returns success
• But reader receives 6E00 status word, although this is absolutely not the data I have sent with nfc_t4t_response_pdu_send()
• Moreover in the log, I observe the following error:

<err> nfc_platform: Tried to read data pointer: 4 bytes, read 0.
<err> nfc_platform: Reading nfc ring buffer failed, resetting ring buffer.

I was expecting the NFC T4T lib would send WTX to the reader until I call nfc_t4t_response_pdu_send() but it seems this is not the case. Am I missing something ?

Moreover, I was wondering: why NFC T4T library source code is not available ? Would it be possible to have access to it ?

Thanks and best regards,

Jean

[JONATHAN LL]

I was expecting the NFC T4T lib would send WTX to the reader until I call nfc_t4t_response_pdu_send() but it seems this is not the case. Am I missing something ?

You are not missing something. Will investigate internally. 


Proposal for possible workaround:

• set different FWI (Frame Wait Time) through nfc_t4t_parameter_set() to see if the possible race condition is resolved
• change the NFC callback processing: modify the IRQ priority of the callback or change the processing flow to use a dedicated thread instead of Work Queue: CONFIG_NFC_OWN_THREAD, CONFIG_NFC_THREAD_PRIORITY and maybe some others to see if it can help

Regards,
Jonathan

[kartapusse]

Hi,

Thanks for this first answer, I am waiting for your investigation concerning WTX that seems to be not sent.

I had already tested to set FWI to the maximum (8 if I have correctly understood) but this has no effect.

I just tested to change callback processing with CONFIG_NFC_OWN_THREAD and the behavior is the same on reader side. However the errors raised by nfc_platform that I have mentioned in my initial query are not raised in this configuration case. Thus, this configuration has an impact but it is not sufficient.

Regards,

Jean

[JONATHAN LL]

Hi Jean,

Which NFC reader is used?

I'd like to understand what the error code (6E00) means. No response from the tag, delayed response or invalid block?

Regards,

Jonathan 

[kartapusse]

I am using this reader: https://www.hidglobal.com/products/omnikey-5422

I am also a bit confused about this Status Word. So far I don't know if this SW comes from the NRF chip or if this is a default SW returned by the reader.

This is also why I asked if access to NFC T4T source code library would be possible to debug this.

BR

Jean

[JONATHAN LL]

Hi Jean, sorry for the slow response time here, but currently it is difficult for us to speed things up and I understand that that causes issues for you. 

Also providing you access to the lib is not a easy task as there is a legal machinery that need to be involved and its slow. 

I will try to get a more concrete timeline for you hare and follow up. Also pleas feel free to ask or push for updates if you want, fully understand that this is a timely issue for you. 

Regards, 
Jonathan

[kartapusse]

Hi Jonathan,

Could you at least confirm that you have the same behavior than me ?

So far I was using a custom board but to be sure, I reproduced the test on nrf5340 DK and I have the same behavior.

Is there any supplementary configuration to be done that could help ?

BR

Jean