GPIO state not retained after FOTA reboot on nRF54L15 (Zephyr SDK 3.0.2)

[Jishnu K J]

Hi,

I am using nRF54L15 with Zephyr RTOS in nRF Connect SDK v3.0.2.

After performing a FOTA update, the device reboots. I need to retain the state of a GPIO pin across this reboot.

The GPIO I am trying to retain is P1.06. I attempted to configure it with retention using the following code:

#define PIN_P1_06 38
#define P1_INDEX  6

void configure_retained_gpio(void) {
    // Configure the pin as output with retention enabled
    nrf_gpio_cfg_output(PIN_P1_06);
 
    NRF_P1->PIN_CNF[P1_INDEX] &= ~GPIO_PIN_CNF_CTRLSEL_Msk;
    NRF_P1->PIN_CNF[P1_INDEX] |= (GPIO_PIN_CNF_CTRLSEL_GPIO << GPIO_PIN_CNF_CTRLSEL_Pos);
}

However, after the OTA update and subsequent reboot, the GPIO state is cleared and does not retain the previous value.

My questions:

1. Is there any additional configuration required in nRF54L15 to retain GPIO states across a reboot after FOTA?

2. Is GPIO retention supported across MCU reset triggered by FOTA, or is it only supported for specific low-power modes?

Any guidance or recommended approach to preserve the GPIO state across OTA reboot would be greatly appreciated.

Thanks.

[Jishnu K J]

Hello Abhijith,

I tried configuring the GPIO pin in the bootloader, but it did not work. I suspect that the overlay file I created (mcuboot.overlay) is not being applied during the boot process.

The overlay file I used is shown below:

&gpio1 {
    status = "okay";

    /* Ensure P1.06 stays HIGH during MCUboot */
    load_cell_en_hog: load-cell-en-hog {
        gpio-hog;
        gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
        output-high;
        line-name = "load-cell-enable";
    };
};

The file is placed at:

my_project/
 └── child_image/
      └── mcuboot.overlay

I have also added CONFIG_BOOTLOADER_MCUBOOT=y in sysbuild.conf.

Is there anything I might be missing? Also, is there any documentation available for properly applying overlays to MCUboot?

Best regards,

Jishnu K J

[Menon]

hello,

Since you are using NCS v3.0.2, I assume you are working with sysbuild. In that case, creating a child_image folder is not the correct approach for configuring MCUboot. Instead, you should create a sysbuild folder and include an mcuboot.overlay file there. Please refer to this sample, which demonstrates how to configure the bootloader.

Kind Regards,

Abhijith

[Jishnu K J]

Hi Abhijith,

I followed your suggestion and configured the bootloader using the sysbuild approach. I created a sysbuild folder and added both mcuboot.overlay and mcuboot.conf, similar to the sample you shared.

After building, I can confirm that the overlay is being applied correctly. I verified this in build/mcuboot/zephyr/zephyr.dts, where the GPIO hog is present:

gpio1: gpio@d8200 {
    compatible = "nordic,nrf-gpio";
    gpio-controller;
    reg = < 0xd8200 0x300 >;
    #gpio-cells = < 0x2 >;
    ngpios = < 0x10 >;
    status = "okay";
    port = < 0x1 >;
    gpiote-instance = < &gpiote20 >;
    phandle = < 0x11 >;

    load_cell_en_hog: load-cell-en-hog {
        gpio-hog;
        gpios = < 0x6 0x0 >;
        output-high;
        line-name = "load-cell-enable";
    };
};

However, in our case, it still does not work. After the firmware update, the GPIO pin P1.06 is cleared, and the device powers off.

Best regards,

Jishnu K J

[Menon]

Hello,

I believe you only need to configure the mcuboot.overlay to initialize the pin in the bootloader. Regarding the issue you raised, does it occur only during DFU (FOTA)? Based on your description, the same behavior should also be observed during a normal reboot, such as after an assertion or a watchdog reset.

Kind Regards,

Abhijith

[Jishnu K J]

Hello Abhijith,

Yes, we observe the same behavior not only during DFU (FOTA), but also during a normal reboot.

In all these cases, the GPIO pin P1.06 (SYS_EN) returns to its default state after reset, causing the system to power off before the bootloader or application can reconfigure it.

Best regards,
Jishnu K J