nRF54L15 P0.01 cannot be configured/used as GPIO input while P0.03 works

[Akshay]

Hello Nordic team,

I am working with an nRF54L15dk and have an issue using P0.01 as a GPIO input.

P0.03 works correctly with the same GPIO configuration, but P0.01 does not respond to the input signal.

According to the nRF54L Series documentation, P0 is the GPIO port associated with the low-power domain, and all P0 pins should support general-purpose GPIO functionality. P0 also supports GPIO SENSE/DETECT and GPIOTE.

Issue

• P0.03: GPIO input works correctly.
• P0.01: GPIO input does not work.
• UARTE30 is disabled in my application.
• I have also tried enabling CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y, but this did not resolve the issue.
• I tested P0.01 using a minimal GPIO configuration rather than relying on a peripheral.

The basic configuration is:

const struct device *gpio0 = DEVICE_DT_GET(DT_NODELABEL(gpio0));

int ret = gpio_pin_configure(gpio0, 1, GPIO_INPUT | GPIO_PULL_UP);

printk("P0.01 configure ret = %d\n", ret);

while (1) {
    printk("P0.01 = %d\n", gpio_pin_get(gpio0, 1));
    k_sleep(K_MSEC(500));
}

I also compared this directly with P0.03:

gpio_pin_configure(gpio0, 3, GPIO_INPUT | GPIO_PULL_UP);

P0.03 behaves as expected.

I have verified that UARTE30 is disabled, so P0.01 should not be occupied by UARTE30 in my application.

I would like to understand:

1. Is there any specific restriction, erratum, or configuration requirement for P0.01 on the nRF54L15?
2. Is there any low-power-domain/GPIO configuration that can prevent P0.01 from functioning as a normal GPIO input?
3. Is P0.01 affected by any GRTC, UICR, pin configuration, or other hardware ownership that is not visible through the normal Zephyr GPIO configuration?
4. Are there any known issues with P0.01 on the particular nRF54L15 silicon revision?
5. Is there a recommended register-level test to verify that P0.01 is actually configured as GPIO input?

I would appreciate any guidance on how to debug this further.

Thank you.

[Edvin]

Hello,

As Turbo J  says, check the back of the DK. For the case of P0.01, you can see that this is used for UART RX, and it is connected to the debugger. Since it is the nRF54L15's UART RX, this means that the debugger is pulling it high. Try disabling the UART interfaces using nRF Connect for Desktop -> Board Configurator like shown in this screenshot:

I don't recall which one is which, but I believe it is actually VCOM1 (but try both).

Note that this may, depending on how you have set up your logging, disable UART logging, but I think it is VCOM0 that is being used by UART logging by default.

Best regards,

Edvin

[Akshay]

I started experiencing this on our custom board, that's when I checked it on the DK. I have UARTE30 disabled in my overlay.
I disabled both VCOM0 and 1 using the board configurator. Still have the issue.

regards,

[Edvin]

Can you please upload the application that you are using to reproduce the issue, and I can have a look, and try to reproduce what you are seeing here. Zip the application that you are using, and let me know what NCS version you are using, and I can see what is going on.

Best regards,

Edvin

[Akshay]

Hi Edvin,

I can't post the entire application here due to company policy. What I can do is post code snippets related to this issue. NCS version is 3.3.0.

devicetree overlay

/{

gpio_input:gpio_input{

		compatible = "gpio-keys";

		latch_switch:latch_switch{
			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
			label = "LATCH SWITCH";
		};

		door_sensor:door_sensor{
			gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
			label = "DOOR SENSOR";
		};
	};

};

&uart20{
    status = "disabled";
};
&uart30 {
    status = "disabled";
};

application

#include <zephyr/kernel.h>
#include <zephyr/devicetree.h>
#include <zephyr/device.h>
#include <zephyr/sys/printk.h>
#include <zephyr/drivers/gpio.h>

#define LATCH_SWITCH_NODE   DT_NODELABEL(latch_switch)
#define DOOR_SENSOR_NODE    DT_NODELABEL(door_sensor)


static const struct gpio_dt_spec latch_switch_spec = GPIO_DT_SPEC_GET(LATCH_SWITCH_NODE,gpios);
static struct gpio_callback latch_switch_cb_data;

static const struct gpio_dt_spec door_sensor_spec = GPIO_DT_SPEC_GET(DOOR_SENSOR_NODE,gpios);
static struct gpio_callback door_sensor_cb_data;

unsigned char read_latch_status(void){
   return gpio_pin_get_dt(&latch_switch_spec);
}


unsigned char read_door_status(void){
   return gpio_pin_get_dt(&door_sensor_spec);
}

static void latch_switch_handler(const struct device *dev, struct gpio_callback *cb, uint32_t pins)
{
	ARG_UNUSED(dev);
	ARG_UNUSED(cb);
	ARG_UNUSED(pins);

   
}

static void door_sensor_handler(const struct device *dev, struct gpio_callback *cb, uint32_t pins)
{
	ARG_UNUSED(dev);
	ARG_UNUSED(cb);
	ARG_UNUSED(pins);
   
}

void init_lock_system(void){

    gpio_pin_configure_dt(&latch_switch_spec,GPIO_INPUT);
    gpio_pin_interrupt_configure_dt(&latch_switch_spec,GPIO_INT_EDGE_BOTH);
    gpio_init_callback(&latch_switch_cb_data,latch_switch_handler,BIT(latch_switch_spec.pin));
    gpio_add_callback(latch_switch_spec.port,&latch_switch_cb_data);

    gpio_pin_configure_dt(&door_sensor_spec,GPIO_INPUT);
    gpio_pin_interrupt_configure_dt(&door_sensor_spec,GPIO_INT_EDGE_BOTH);
    gpio_init_callback(&door_sensor_cb_data,door_sensor_handler,BIT(door_sensor_spec.pin));
    gpio_add_callback(door_sensor_spec.port,&door_sensor_cb_data);

}

regards,