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.

[Menon]

Hello,

nRF54L15 does support GPIO retention, but you need to enable it using the retention API, see nrf_gpio_pin_retain_enable.

That said, I’m not sure if the GPIO state will survive the reset that happens during FOTA, since that process involves a system reset and the behavior can depend on the reset type. I’ll double-check this and get back to you.

Kind Regards,

Abhijith

[Jishnu K J]

Hello Abhijith,

Okay, noted. I will wait for your update.

In the meantime, I checked the API you mentioned (nrf_gpio_pin_retain_enable), but it does not appear to be defined in SDK v3.0.2.

Best regards,

Jishnu K J

[Menon]

Hello,

GPIO configs are  only retained through a system off reset. For other reset sources they are cleared. So after the OTA update and reboot, the GPIO returning to its default/reset state is the expected behavior. Could you give some more context on what exactly is the use case here? See the section reset behavior.

Kind Regards,

Abhijith

[Jishnu K J]

Hello Abhijith,

Thank you for the clarification.

In our design, P1.06 (SYS_EN) is used as the power enable pin. It is initially set high to keep the system powered on. If this pin goes low, the system powers off.

We also have a power button in the circuit. The firmware detects the button press by reading P1.05 (SYS_OUT) and then toggles P1.06 (SYS_EN) to control the system power.

However, after performing FOTA, the device reboots and the state of P1.06 returns to its default value. As a result, SYS_EN becomes low and the system powers off. The device can only power on again when the button is pressed manually to power up the controller.

I have attached the relevant part of the schematic for reference.

Best regards,
Jishnu K J

[Menon]

Hello,

In this case, I don’t think GPIO retention is the right approach.

Instead, it’s worth trying to initialize the pin as early as possible in the bootloader. I’m not 100% sure this will work though, since it depends on how the GPIO behaves during reset. If the pin goes high-Z, it won’t actively drive the line low, so it may stay on long enough for the bootloader to re-assert it.

Kind Regards,

Abhijith