Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Fri, 07 Nov 2025 14:06:11 GMT

Yes, that has fixed the problem : the NFC reader now waits for the response and get it when I send it (even after 30-50ms the time to get a response from the iso7816 smartcard).

for info, I have remained with my code that uses the "no thread" platform interface to the nfc T4T library and deals with processing in the IRQ.

thanks for your help!

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Fri, 07 Nov 2025 14:05:25 GMT

Hi,

Yes. Those are the commits with a proposed fix. I look forward to hear if this helps with the issue.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Fri, 07 Nov 2025 09:31:30 GMT

I hadn't realised I needed to update my git locally to be able to cherry-pick remote commits (git fetch --all --tags --prune)

I will now test if this helps with the issue!

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Thu, 06 Nov 2025 17:56:16 GMT

Hi,

Can you confirm that by sdk-nrfxlib you mean the nrfxlib subdirectory of the NCS? and same for sdk-nrf?

(I'm not a power git user I freely admit!)

When I try to apply these commits (using git cherry-pick) I get 'bad object' errors

C:\ncs\v2.9.0\nrfxlib>git cherry-pick -n 9a7b8e6aec3f031b520ff55c658462c748f0ed3e
fatal: bad object 9a7b8e6aec3f031b520ff55c658462c748f0ed3e

C:\ncs\v2.9.0\nrf>git cherry-pick 5d31704051562b37c1c81d60cafdc71bb519a982
fatal: bad object 5d31704051562b37c1c81d60cafdc71bb519a982

I can find these commits in the gitlab projects:

https://github.com/nrfconnect/sdk-nrfxlib/commit/9a7b8e6aec3f031b520ff55c658462c748f0ed3e

https://github.com/nrfconnect/sdk-nrf/commit/5d31704051562b37c1c81d60cafdc71bb519a982

Are these the fixes you mean?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Thu, 06 Nov 2025 14:47:08 GMT

Hi,

Please try cherry-picking the following commits, which contains proposed patches:

sdk-nrfxlib: 9a7b8e6aec3f031b520ff55c658462c748f0ed3e
sdk-nrf: 5d31704051562b37c1c81d60cafdc71bb519a982

With those applied, do you still see the issue, for your project?

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Fri, 31 Oct 2025 13:55:12 GMT

Hi,

Thank you for the patience, and for your minimal example for reproduction.

We have already reproduced a state where the NFCT gets stuck, and are in the process of narrowing down where exactly it happens, but your added information and example for reproduction are of course highly appreciated.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Fri, 31 Oct 2025 11:41:18 GMT

This is dragging on...

To help you check it with the developers, I have taken the NCS2.9.0 sample from nrf/samples/nfc/record_text", and updated the main.c to the minimal code that will demonstrate this behaviour.

The code now:

- uses T4T library, in APDU passing mode

- sets FWI to 8

- uses the "no thread callback" api by setting CONFIG_NFC_THREAD_CALLBACK=n in prj.conf (which configures the library to use the wrapper nrf/subsys/nfc/lib/platform_internal_irq.c, which calls the application callback function _nfc_t4t_apdu_cb() directly on the ISR from the NFC lib)

- handles received cmd and generates response on the sysworkq in _process_apdu_cmd()

- the response is just hardcoded to 0x6A82 to make the reader go to its next cmd.

- before sending the response it waits for N ms (k_msleep()) to simulate the processing delays.

I have tried with 2 readers : an HID Omnikey 5032CL, and a Elatec TWNN4 Slim. With Windows 11, as soon as a tag is detected, windows automatically tries to interrogate it (security service) so its easy to see if it works or not. I used wireshark with the USB pcap plugin to see if the request responses are ok or not.

If the delay is 0 -> all is ok.

Anything more and the reader fails to get the response (and will retry the command). The HID shows the card as 'not present, failed' after each attempt, the elatec just sends nothing.

I also tried using the Android app TagInfo (from NXP) : this also fails to get responses but eventually gives up and reports just the basic ATS info.

To test this, build the record_text sample, replacing the src/main.c and prj.conf with the attached files.... It should work on a nrf5340 dev board, although I haven't tried : I have our custom nrf5340 board, but the NFC part is straight from the dev kit schema with an on-PCB RF loop.

devzone.nordicsemi.com/.../0647.prj.conf devzone.nordicsemi.com/.../4747.main.c

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Tue, 21 Oct 2025 08:39:13 GMT

Any progress? I'm worried this is going to turn out to be a hardware issue and need to know before we commit to mass production....

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Mon, 06 Oct 2025 14:31:34 GMT

Hi,

I am sorry for little feedback from our end. We are looking into a couple of alternatives, but unfortunately no conclusions yet.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 06 Oct 2025 07:51:09 GMT

Hi, I'd really like to make some progress on this as its blocking my POCs for digital wallet solutions (access control, authentication etc) using the NFC channel.

Any ideas on the way to move forward?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 29 Sep 2025 13:27:25 GMT

any word back on this?

I have rewritten my code to process the callback from the IRQ directly (CONFIG_NFC_THREAD_CALLBACK=n) instead of using platform_internal_thread.c and always get the same result (works if response sent immediately, bad NFC if takes > 3-4ms).

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 15 Sep 2025 14:58:25 GMT

Ok, I see that this option essentially calls my code in the IRQ context directly using platform_internal_irq.c - not surprising it ends up in an assert().

By creating a 'test' callback function which is IRQ safe, and just makes a fixed response to the DATA_IND event using nfc_t4t_response_pdu_send() , the reader operates as expected.

However, if there is any delay (more than a couple of ms) in generating the response (eg I use the system queue to schedule the response outside of the callback) then the reader does not manage to see the response correctly.

I think this demonstrates that the problem is not in the platform.c or platform_internal.c code but in the library (as already hinted at in your previous responses).

My callback code for the build case with CONFIG_NFC_THREAD_CALLBACK=n:

static uint8_t _nok_resp[] = { 0x6a, 0x82};

static void _apdu_cmd_test_resp(void* p_ctx) {

struct _nfc_ctx* ctx = (struct _nfc_ctx*)p_ctx;

if (ctx==NULL) {

return;

}

int ret;

if ((ret=nfc_t4t_response_pdu_send(_nok_resp, sizeof(_nok_resp)))!=0) {

log_warn("nfcmgr: t4t apdu test resp NOT sent after %dms error (%d)", (gettime_ms()-ctx->lastRead), ret);

} else {

log_warn("nfcmgr:t4t apdu test resp sent after %dms", (gettime_ms()-ctx->lastRead));

}

static void _apdu_cmd_test_print(void* p_ctx) {

log_warn("nfcmgr: test event %d", (int32_t)p_ctx);

}

// ADPU type operation test callback, called directly on IRQ, just always responds with 'no'

static void _nfc_t4t_test_cb_from_irq(void *context, nfc_t4t_event_t event, const uint8_t *data, size_t data_length, uint32_t flags) {

struct _nfc_ctx* ctx = (struct _nfc_ctx*)context;

if (ctx==NULL) {

return;

}

switch(event) {

case NFC_T4T_EVENT_FIELD_ON: {

ctx->nfc_active = true;

wsched_request(_apdu_cmd_test_print, (void*)NFC_T4T_EVENT_FIELD_ON);

break;

}

case NFC_T4T_EVENT_FIELD_OFF: {

///< External Reader polling stopped

ctx->nfc_active = false;

wsched_request(_apdu_cmd_test_print, (void*)NFC_T4T_EVENT_FIELD_OFF);

break;

}

case NFC_T4T_EVENT_DATA_IND: {

ctx->lastRead = gettime_ms();

int ret=nfc_t4t_response_pdu_send(_nok_resp, sizeof(_nok_resp));

wsched_request(_apdu_cmd_test_print, (void*)ret);

// wsched_request(_apdu_cmd_test_print, (void*)NFC_T4T_EVENT_DATA_IND);

// will generate a response

// wsched_request(_apdu_cmd_test_resp, ctx);

break;

}

case NFC_T4T_EVENT_DATA_TRANSMITTED: {

// just to log

wsched_request(_apdu_cmd_test_print, (void*)NFC_T4T_EVENT_DATA_TRANSMITTED);

break;

}

default: {

wsched_request(_apdu_cmd_test_print, (void*)event);

break;

}

Note if the case for DATA_IND uses the system work queue to schedule the function _apdu_cmd_test_resp() then the problem occurs, if it directly does pdu_send() then it does not.

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 15 Sep 2025 09:39:47 GMT

[quote userid="8164" url="~/f/nordic-q-a/122735/using-nfc-library-in-raw-apdu-mode-how-to-set-fwi-fwtx/547961"]disable CONFIG_NFC_THREAD_CALLBACK this should bypass platform.c, which should reveal if the error is in the library itself.[/quote]

This option

CONFIG_NFC_THREAD_CALLBACK=n

causes the code to crash immediately the NFC reader is presented. Do I need other config set or other code changes?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Fri, 05 Sep 2025 17:17:49 GMT

I'm very doubtfull about this, as my changes to platform.c/platform_internal_thread.c were made to add debugging to see if there was an issue about the ring buffer/scheduling or not...(and there are some issues).

I will need to come back to the project and see what happens when I rebuild with this option.

What happened to this investigation?

[quote userid="8164" url="~/f/nordic-q-a/122735/using-nfc-library-in-raw-apdu-mode-how-to-set-fwi-fwtx/543482"]What we see initially, is that it looks like the 3-byte Tx frame logged is the corrupted frame[/quote]

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Fri, 05 Sep 2025 16:16:58 GMT

Hi,

I have some feedback now, that your modifications to platform.c might be invalid. If you disable CONFIG_NFC_THREAD_CALLBACK this should bypass platform.c, which should reveal if the error is in the library itself.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Tue, 19 Aug 2025 16:10:44 GMT

Hi,

Not yet, I am afraid. I will keep you informed when I know more.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 18 Aug 2025 08:15:36 GMT

Hi Terje, Any news from the dev team?

thanks

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Thu, 24 Jul 2025 11:58:14 GMT

Hi,

[quote user="BrianW"]Ok, thats great. Hopefully we can find out how to get this fixed[/quote]

What we see initially, is that it looks like the 3-byte Tx frame logged is the corrupted frame. Due to key persons away at the moment, I am afraid further inquiry might delay until well into August when they are back. I am sorry for any inconvenience.

[quote user="BrianW"] what is the reason for not providing the nfc lib as source[/quote]

Licensing terms from a third party prevents us from sharing the source code with others. The library is therefore shared in compiled binary form only.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 21 Jul 2025 16:44:57 GMT

[quote userid="8164" url="~/f/nordic-q-a/122735/using-nfc-library-in-raw-apdu-mode-how-to-set-fwi-fwtx/543036"]nRF Connect SDK v2.9.0 (which from what I understand is the version you are using.)[/quote]

Correct.

[quote userid="8164" url="~/f/nordic-q-a/122735/using-nfc-library-in-raw-apdu-mode-how-to-set-fwi-fwtx/543036"]We need to look further into the issue, and will get back to you when we know more or if we are in need of more information for reproducing the issue in our end.[/quote]

Ok, thats great. Hopefully we can find out how to get this fixed...

By the way, what is the reason for not providing the nfc lib as source (as then I could at least try to debug it myself)?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

tesc — Mon, 21 Jul 2025 13:15:06 GMT

Hi,

This seems to be related to a known issue which was patched prior to nRF Connect SDK v2.9.0 (which from what I understand is the version you are using.)

It seems to happen when the application attempts to transmit a response PDU, while the transmission of an S(WTX) block has already started.

We need to look further into the issue, and will get back to you when we know more or if we are in need of more information for reproducing the issue in our end.

Regards,
Terje

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Wed, 16 Jul 2025 09:47:28 GMT

With a little more logging info (including the contents of the buffers), I think the library is not accepting my response, and the tx of size 3 is in fact a WTX S-block of some kind around the timeout time (occurs 85ms after the reception of the command).

[00:04:09.985,107] <inf> NRFX_NFCT: Field detected
[00:04:09.998,809] <inf> NRFX_NFCT: Selected
[00:04:09.998,901] <wrn> app: nfc_requestor : NFC field on for APDU routing START
[00:04:09.998,992] <wrn> app: ISO7816: START - card already open
[00:04:09.999,786] <inf> NRFX_NFCT: Rx fend evt (2) [05 78 ]
[00:04:09.999,877] <inf> NRFX_NFCT: Tx start evt (5) [05 78 80 82 02 ]
[00:04:10.000,427] <inf> NRFX_NFCT: Tx fend evt (5)
[00:04:10.010,345] <inf> NRFX_NFCT: Rx fend evt (1) [c2 ]
[00:04:10.010,375] <inf> NRFX_NFCT: Tx start evt (1) [c2 ]
[00:04:10.010,620] <inf> NRFX_NFCT: Tx fend evt (1)
[00:04:10.019,409] <inf> NRFX_NFCT: Selected
[00:04:10.020,385] <inf> NRFX_NFCT: Rx fend evt (2) [05 78 ]
[00:04:10.020,477] <inf> NRFX_NFCT: Tx start evt (5) [05 78 80 82 02 ]
[00:04:10.020,996] <inf> NRFX_NFCT: Tx fend evt (5)
[00:04:10.027,130] <inf> NRFX_NFCT: Rx fend evt (14) [02 00 a4 04 00 07 d2 76 00 00 85 01 01 00 ]
[00:04:10.031,799] <inf> NRFX_NFCT: Tx start evt (2) [f2 01 ]
[00:04:10.032,104] <inf> NRFX_NFCT: Tx fend evt (2)
[00:04:10.033,050] <inf> NRFX_NFCT: Rx fend evt (2) [f2 01 ]
[00:04:10.063,293] <inf> app: iso7816: cmd (00:A4:04:00 lc=7, le=0) sent OK, response (6A:82 le=0) bytes
[00:04:10.063,385] <inf> app: ISO7816: routing PROCESS (next) returns successful response of size 2

[00:04:10.063,629] <wrn> app: nfc_requestor : NFC APDU routed OK cmd (00a4040007d276000085010100) response (6A:82 le=2)
[00:04:10.063,751] <wrn> app: nfcmgr:cmd rx@250027, process@250027, resp@250063, now@250063
[00:04:10.110,351] <inf> NRFX_NFCT: Tx start evt (2) [f2 01 ]
[00:04:10.110,656] <inf> NRFX_NFCT: Tx fend evt (2)
[00:04:10.111,633] <inf> NRFX_NFCT: Rx fend evt (2) [f2 01 ]
[00:04:10.111,694] <inf> NRFX_NFCT: Tx start evt (3) [f2 01 91 ]
[00:04:10.112,091] <inf> NRFX_NFCT: Tx fend evt (3)
[00:04:10.113,037] <inf> NRFX_NFCT: Rx fend evt (2) [f2 11 ]
[00:04:11.049,316] <inf> NRFX_NFCT: Field lost
[00:04:11.049,438] <wrn> app: nfc_requestor : NFC field off for APDU routing END
[00:04:11.049,530] <inf> app: ISO7816: routing END

I see the ATS being sent (twice...) as TL T0 TA TB TC ( values 05 78 80 82 02 look reasonable, and set the FWI to 8 as expected)

Then the tx of [f2 02] and rx of same are the S-block WTX request and responses...

But I can't understand

- why no sending of the response I submit to the library (at 4:10:063 timestamp, 36ms after the command was received)

- the last S-block of length 3 [f2 01 91] - what is the extra byte of 0x91? and the response of [f2 11] is a protocol error for me!

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Wed, 16 Jul 2025 07:54:32 GMT

[quote userid="134465" url="~/f/nordic-q-a/122735/using-nfc-library-in-raw-apdu-mode-how-to-set-fwi-fwtx/542394"]The only log from the NRFC_NFCT driver appears to be the "Tx start" INFO level one.... Should there be more? why always Tx (and never Rx)?[/quote]

Ok,because the other logs are all debug level. I updated them to INFO, and also added the size of the tx or rx data block. This gives me:

[00:01:21.869,384] <inf> NRFX_NFCT: Field detected
[00:01:21.870,422] <inf> NRFX_NFCT: Field detected
[00:01:21.870,483] <inf> NRFX_NFCT: Field detected
[00:01:21.884,185] <inf> NRFX_NFCT: Selected
[00:01:21.884,216] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:01:21.884,216] <err> nfc_platform: cb_work: no data.
[00:01:21.884,307] <wrn> app: nfc_requestor : NFC field on for APDU routing START
[00:01:21.884,368] <wrn> app: ISO7816: START - card already open
[00:01:21.885,131] <inf> NRFX_NFCT: Tx start2 (5)
[00:01:21.885,131] <inf> NRFX_NFCT: Rx fend evt (2)
[00:01:21.885,162] <inf> NRFX_NFCT: Tx start evt (5)
[00:01:21.885,803] <inf> NRFX_NFCT: Tx fend evt (5)
[00:01:21.885,803] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:01:21.885,833] <err> nfc_platform: cb_work: no data.
[00:01:21.896,820] <inf> NRFX_NFCT: Tx start2 (1)
[00:01:21.896,850] <inf> NRFX_NFCT: Rx fend evt (1)
[00:01:21.896,881] <inf> NRFX_NFCT: Tx start evt (1)
[00:01:21.897,155] <inf> NRFX_NFCT: Tx fend evt (1)
[00:01:21.905,944] <inf> NRFX_NFCT: Selected
[00:01:21.905,975] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:01:21.905,975] <err> nfc_platform: cb_work: no data.
[00:01:21.906,890] <inf> NRFX_NFCT: Tx start2 (5)
[00:01:21.906,890] <inf> NRFX_NFCT: Rx fend evt (2)
[00:01:21.906,951] <inf> NRFX_NFCT: Tx start evt (5)
[00:01:21.907,562] <inf> NRFX_NFCT: Tx fend evt (5)
[00:01:21.913,787] <inf> NRFX_NFCT: Tx start2 (2)
[00:01:21.913,787] <inf> NRFX_NFCT: Rx fend evt (14)
[00:01:21.913,818] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2015, data_size 33
[00:01:21.918,579] <inf> NRFX_NFCT: Tx start evt (2)
[00:01:21.918,945] <inf> NRFX_NFCT: Tx fend evt (2)
[00:01:21.919,860] <inf> NRFX_NFCT: Tx start2 (2)
[00:01:21.919,860] <inf> NRFX_NFCT: Rx fend evt (2)
[00:01:21.949,890] <inf> app: iso7816: cmd (00:A4:04:00 lc=7, le=0) sent OK, response (6A:82 le=0) bytes
[00:01:21.949,981] <inf> app: ISO7816: routing PROCESS (next) returns successful response of size 2

[00:01:21.950,225] <wrn> app: nfc_requestor : NFC APDU routed OK cmd (00a4040007d276000085010100) response (6A:82 le=2)
[00:01:21.950,347] <wrn> app: nfcmgr:cmd rx@81913, process@81913, resp@81950, now@81950
[00:01:21.997,161] <inf> NRFX_NFCT: Tx start evt (2)
[00:01:21.997,497] <inf> NRFX_NFCT: Tx fend evt (2)
[00:01:21.998,413] <inf> NRFX_NFCT: Tx start2 (3)
[00:01:21.998,413] <inf> NRFX_NFCT: Rx fend evt (2)
[00:01:21.998,474] <inf> NRFX_NFCT: Tx start evt (3)
[00:01:21.998,901] <inf> NRFX_NFCT: Tx fend evt (3)
[00:01:21.999,816] <inf> NRFX_NFCT: Rx fend evt (2)
[00:01:22.943,023] <inf> NRFX_NFCT: Field lost
[00:01:22.943,084] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:01:22.943,084] <err> nfc_platform: cb_work: no data.
[00:01:22.943,176] <wrn> app: nfc_requestor : NFC field off for APDU routing END
[00:01:22.943,237] <inf> app: ISO7816: routing END

I guess the 2 byte tx messages are the 'please wait' generated automatically by the library?

And it seems like the response (3 bytes) is transmitted at 00:01:21.998,413-901 (Tx start evt, Tx fend evt); but the reader isn't seeing it. Any ideas?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

BrianW — Mon, 14 Jul 2025 13:20:26 GMT

I enabled the logging

CONFIG_NRFX_NFCT_LOG=y

This gave me this for a test (where it takes around 35ms to process the command):

[00:03:00.368,896] <wrn> app: nfc_requestor : NFC field on for APDU routing START
[00:03:00.368,988] <wrn> app: ISO7816: START - card already open
[00:03:00.369,720] <inf> NRFX_NFCT: Tx start
[00:03:00.370,422] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:03:00.370,422] <err> nfc_platform: cb_work: no data.
[00:03:00.385,864] <inf> NRFX_NFCT: Tx start
[00:03:00.395,019] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:03:00.395,019] <err> nfc_platform: cb_work: no data.
[00:03:00.395,904] <inf> NRFX_NFCT: Tx start
[00:03:00.408,569] <inf> NRFX_NFCT: Tx start
[00:03:00.408,599] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2015, data_size 33

-> reception of the APDU command

[00:03:00.414,642] <inf> NRFX_NFCT: Tx start
[00:03:00.444,641] <inf> app: iso7816: cmd (00:A4:04:00 lc=7, le=0) sent OK, response (6A:82 le=0) bytes
[00:03:00.444,732] <inf> app: ISO7816: routing PROCESS (next) returns successful response of size 2

[00:03:00.444,976] <wrn> app: nfc_requestor : NFC APDU routed OK cmd (00a4040007d276000085010100) response (6A:82 le=2)
[00:03:00.445,098] <wrn> app: nfcmgr:cmd rx@180408, process@180408, resp@180445, now@180445

-> response sent back to nfct lib (took 37ms to generate)

[00:03:00.493,194] <inf> NRFX_NFCT: Tx start

-> could this be it sent to the reader?

[00:03:01.574,798] <err> nfc_platform: cb_work entry : ring buffer size 2048, free space 2028, data_size 20
[00:03:01.574,829] <err> nfc_platform: cb_work: no data.
[00:03:01.574,920] <wrn> app: nfc_requestor : NFC field off for APDU routing END

-> but reader doesn't seem to see or process it, and 81ms later it gives up

The only log from the NRFC_NFCT driver appears to be the "Tx start" INFO level one.... Should there be more? why always Tx (and never Rx)?

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

Marte Myrvold — Fri, 11 Jul 2025 13:11:29 GMT

Hi,

Regarding logging, you can enable logs from the NFCT driver, which should show most NFC events on the HW interface level. You can use NRFX_NFCT_LOG and set the log level to debug in the system.

Best regards,
Marte

RE: Using NFC Library in 'raw' APDU mode : how to set FWI/FWTX?

Marte Myrvold — Fri, 11 Jul 2025 12:39:48 GMT

Hi,

Thank you, I have forwarded this to the developers. I cannot comment on the schedule since this needs to be prioritized against other tasks. Please get in touch with RSM if this is critical.

Best regards,
Marte