nRF54L15 - NFCT Pins as GPIO with TF-M

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

WiWa — Mon, 17 Nov 2025 15:16:23 GMT

Hi Hieu,

I was able to fix the issue by deleting the PADCONFIG bit manually like suggested by you. I used:

static int disable_nfc_pads_early(const struct device *unused)
{
    ARG_UNUSED(unused);

    /* Clear the PADCONFIG bit so the NFC pads stop being forced to NFC */
    NRF_NFCT_NS->PADCONFIG = 0;   /* Use NRF_NFCT_NS if called from non-secure */
    return 0;
}

/* Run before GPIO and pinctrl take effect */
SYS_INIT(disable_nfc_pads_early, PRE_KERNEL_1, 0);

Walter

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

WiWa — Mon, 17 Nov 2025 12:06:56 GMT

Hi Hieu,
I am trying to use P1.02 and P1.03 as PWM outputs on a custom board that I developed. Now I am running into the same issue, that disabling NFC does not release these two GPIOs. As I need 8 Analog inputs and 7 analog outputs I used all GPIOs from P1 and cannot simply change the PIN. Could you please assist me in solving that issue?
Do you have any news from the DeviceTree team working on this?

Thank you in advance!

Best regards,

Walter

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Mon, 10 Nov 2025 09:07:18 GMT

Hi Justin,

No problem. I too agree that choosing a less special pin is the best way forward. Would also limit the amount of change necessary if one day in the future, NFC is considered.

Please just let me know if the issue becomes bothersome again in the future.

-----------------------

Hi Mark,

If the issue is blocking your project, please let me know.

Best regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

JVer — Mon, 10 Nov 2025 07:50:00 GMT

Hi Hieu,

Sorry for the delay, We only have one nRF54L15 dev kit laying around and we modified it to function exactly as in the prototype hardware so getting an exact working example is difficult and I also do not have enough time to prepare a minimal repoducable example.

I cut and soldered the connections such that the external 32kHz crystal is disconnected and redirected to the IO headers just like the NFC pins. I use the dev kit board files as base with an overlay file to redirect the debug uart pins on the P1 block to other pins since I needed the default UART pins for different connections. My project Kconfig contains some additional configurations to enable the internal RC oscilator.

I attempted to write the PADCONFIG register in the main function while in secured and non-secured to attempt to change it with the mentioned results. The results reflect the same on the prototype hardware in that we are unable to change the register in non-secured mode.

Sadly I do not have enough time to dive much deeper since we internally decided to just use different pins and avoid the problem in our next revision of the hardware. If required I can provide more information but I do not have the time to setup a dev kit for further testing.

Sadly it is not a quick fix and you provided good support but we need to continue.

Kind regards,
Justin Verkade

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Thu, 06 Nov 2025 11:09:07 GMT

Hi Justin and Mark,

Sorry for the late reply. I broke the environment on my machines and can't test anything for a while.

That is fixed now, but I still can't reproduce your issue with NVS v3.1.1.

Do you have a minimal setup I can reproduce the issue with?

Here is my copy of modified zephyr/samples/basic/blinky sample, where P1.02 works as expected.

devzone.nordicsemi.com/.../c339307_2D00_251106_5F00_01.zip

Best regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

JVer — Fri, 31 Oct 2025 12:54:13 GMT

Hi Mark,

Thanks for the additional information on this case, this helps.

I configured the NRF5L15 dev kit and resoldered the connections to output to the IO headers. I can observe the same behavior as metioned that the IO does not get unlocked when building with TF-M and the application running non-secured. I can toggle the pin when it is unlocked in a secured build.

I did some additional testing and noticed that the NRF_NFCT_NS->PADCONFIG is set to 0 inside the driver init as it gets cleared by the POST_KERNEL function I have but the debugger says the register is still set.

Trying to write to it does alter NRF_NFCT_NS->PADCONFIG but it does not correlate to the actual register as shown by the debugger.

Kind regards,
Justin Verkade

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

MarkLaloo — Fri, 31 Oct 2025 11:23:02 GMT

Hi Hieu, Justin

I've noticed (due to recommendations in other tickets to upgrade our SDK) that the solution we have been using (NRF_NFCT_NS->PADCONFIG=0) no longer works in our project. We previously built using NCS v2.9.1 (where it worked), and have moved to v3.1.1 (no longer working). Tests were completed using non-secure build target, building with TF-M.

I have also tested on v3.1.1 with TF-M removed (and building with secure target), and NFCT config now works as expected (using NRF_NFCT_S).

Note, in this specific test, the GPIO was used to drive an LED.

Kind regards,
Mark Laloo

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Thu, 30 Oct 2025 14:28:19 GMT

Hi Justin,

Can you get a very simplified test going where you only control the pin as a GPIO?

Here is my project where I overlayed the Devicetree to have P1.02 as LED1 and toggle it.

Kind regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

JVer — Thu, 30 Oct 2025 08:59:11 GMT

Hi Hieu,

We have a MCP251xFD CAN transceiver connected and we are using the can_mcp251xfd zephyr driver. The pins are connected to the SS and MOSI, and the pins and managed by the zephyr driver. The function to disable the IO lock runs in POST_KERNEL with a priority of 20 and has been verified using a debugger to run before the can_mcp251xfd driver. The SDK version is v3.1.1.

A result table of my findings in secured and non-secured builds are:

Secured:

NRF_NFCT->PADCONFIG <> Writes the register correctly.
NRF_NFCT_S->PADCONFIG <> Writes the register correctly.
NRF_NFCT_NS->PADCONFIG <> Jumps to z_arm_usage_fault().

Non-Secured:

NRF_NFCT->PADCONFIG <> Steps over the operation but does not write the register.
NRF_NFCT_S->PADCONFIG <> Jumps to SecureFault_Handler().
NRF_NFCT_NS->PADCONFIG <> Steps over the operation but does not write the register.

The jumps to SecureFault_Handler() are expected but the NRF_NFCT and NRF_NFCT_NS both step over the write without faults but do not update the register.

In a secured build where the register does get written correctly the device boots correctly and everything works as intended.

One additional bit of information that I do not think matters is that we are using a nRF54L10 instead of a L15.

We are out of ideas and wil most likely change the hardware but we are interested to see if we can find a fix for it.

Kind regards,
Justin Verkade

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Thu, 30 Oct 2025 01:26:42 GMT

Hi Justin,

What is the driver that you are trying to use the pin with?
At what initialization priority does it initialize?
And what SDK version are you testing with?

I didn't try to write to NRF_NFCT_S not during initialization time, but just in main(), and can see pin 1.02 is able to toggle correctly in NCS v3.1.1.

Kind regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

JVer — Tue, 28 Oct 2025 15:16:44 GMT

Hi Hieu,

Thanks for the response.

Sorry for my bad explenation, I ment to say that writing the PADCONFIG register only works in non secure mode using the NRF_NFCT_S and NRF_NFCT versions but the solution to use the NRF_NFCT_NS with a Non-Secure build does not work.

The program correctly faults when attempting to write using the NRF_NFCT_NS version in a secure build.

I verified that using the NRF_NFCT_S and NRF_NFCT set the register correctly while probing using a debugger with a secure build but changing these to NRF_NFCT_NS and building the application in a Non-Secure build causes the debugger to continue running the code but the register does not update.

I try to unlock the NFCT pins using a function running POST_KERNEL with a priority of 20. The debugger shows that it gets in the init function before reaching the drivers that require the pins to function as GPIO but although the function runs and exits the register does not get changed.

We are considering updating the hardware design to avoid the use of these pins,but understanding why it is not possible to unlock the pins in a Non-Secure build is favorable over updating the hardware.

I tried running the unlock function in PRE_KERNEL_1 but the code seems to crash if I set it like this.

Kind regards,
Justin Verkade

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Tue, 28 Oct 2025 13:27:20 GMT

Hi JVer,

Are you certain that NRF_NFCT_NS->PADCONFIG works when you build without TF-M?

Without TF-M, your application should be built to run in the Secure Environment, which means it should write to NRF_NFCT_S instead.

With TF-M, your application should be built to run in the Non-secure Environment, thus NRF_NFCT_NS.

Kind regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

JVer — Mon, 27 Oct 2025 16:04:53 GMT

Hi Hieu,

We tried this solution to write the memory using the NRF_NFCT_NS->PADCONFIG register but this only works for us when building the application without TF-M. We are using the SDK 3.1.1 and we are wondering if the solution does not work anymore or if a different solution has been found to fix the issue?

Kind regards,
JVer

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

MarkLaloo — Fri, 31 Jan 2025 07:41:31 GMT

HI Hieu,

Thank you for the response; we will continue using the PADCONFIG register until a driver solution is available.

Kind regards,
Mark Laloo

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Wed, 29 Jan 2025 14:39:47 GMT

Hi Mark,

Unfortunately, the people working on the DeviceTree solution are unavailable at the moment.

I also would like to correct that writing NRF_NFCT_NS->PADCONFIG works. I didn't know that P1.02 isn't connected from the SoC to the pin header on the DK. Checking R33 on the DK shows that the pin works normally.

Could you please use the direct register write method for now?

I will file an internal ticket for a driver approach solution to the problem.

Best regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Thu, 23 Jan 2025 22:45:34 GMT

Hi Mark,

My apology. I am able to reproduce the issue. I actually am not able to work around it by writing to NRF_NFCT_NS->PADCONFIG. Did you write to that register from the secure domain?

I am also asking internally if there is any DeviceTree method for this instead. I will get back to you when I got an answer.

Best regards,

Hieu

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

MarkLaloo — Wed, 22 Jan 2025 08:02:31 GMT

HI Hieu,

Thanks for the response. I've seen this post before, with no luck.

I've tried disabled the NFC node using:

&nfct {

status = "disabled";

};

in board_nrf54l15_cpuapp_ns.dts, and after testing again, this does not solve the issue. Debugging in VSCode/Ozone and inspecting the registers, PADCONFIG is still enabled in the NFCT_NS register, and the pin does not function as a GPIO unless I manually disable. Worth noting, the TFM_NFCT_PINS_AS_GPIO appears to target only the 5340 SoC. Is there perhaps something I'm missing alongside the NFCT node change in devicetree?

Kind regards,
Mark Laloo

RE: nRF54L15 - NFCT Pins as GPIO with TF-M

Hieu — Tue, 21 Jan 2025 19:22:35 GMT

Hi Mark,

Referring to this earlier DevZone case: nRF5340: best way to configure P0.02 (NFCT) as GPIO with TFM .

As long as the NFC node is disabled in DeviceTree on the non-secure target, P1.02 will be enabled as a GPIO pin by default.

Best regards,

Hieu