nRF54L15 - NFCT Pins as GPIO with TF-M

[MarkLaloo]

Good day,

I'm trying to use pin 1.02 as a GPIO in a TF-M build using a (custom) non-secure board target, and I'm struggling to find the appropriate way to accomplish this. 

All current resources point to deprecated Kconfig defines (USE_NFCT_PINS_AS_GPIO), do not support non-secure targets (uisng the &uicr node in devicetree), are for older SoCs (

TFM_NFCT_PINS_AS_GPIOS only applies to nRF5340 according to v2.9.0 SDK). The only working option I've found is to edit the NFCT PADCONFIG register (which worked); are there any other options?

Thank you

Kind regards,

Mark Laloo

[Hieu]

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

[MarkLaloo]

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 

[Hieu]

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

[Hieu]

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

[MarkLaloo]

HI Hieu,

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

Kind regards,
Mark Laloo

[JVer]

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

[Hieu]

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

[JVer]

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