nrf54 SDK connect: can't wake uart, shell when using pm_device_action_run(uart, PM_DEVICE_ACTION_RESUME);

[narfster]

Hi,

using nrf connect SDK v3.1.1

using nrf54L15 development board.

I have been trying to return set uart in low power mode and resume uart low power from a button press.

I have a working project that doesn't so much, I have set up the CLI shell using the standard uart20 as designed with this  dev board. 

my objective was trying to get to low power modes when suspending uart, on button wake uart and continue the shell CLI.

this doesn't work as expected with pm_device_action_run API.

const struct device *uart = DEVICE_DT_GET(DT_NODELABEL(uart20));

pm_device_action_run(uart, PM_DEVICE_ACTION_SUSPEND);

pm_device_action_run(uart, PM_DEVICE_ACTION_RESUME);

const struct device *uart = DEVICE_DT_GET(DT_NODELABEL(uart20));

void uart_enable(bool is_enable)
{

    if(is_enable == false)
    {
         pm_device_action_run(uart, PM_DEVICE_ACTION_SUSPEND);
    }
    else
    {
        pm_device_action_run(uart, PM_DEVICE_ACTION_RESUME);
    }
}

static int shell_disable(const struct shell *shell, size_t argc, char **argv)
{
    //uart_enable_cmd = 0; // disable
    //Timer_start(my_tmr, 7000, &uart_enable_cmd);
     uart_enable(false); // disable uart
    return 0;
}



SHELL_STATIC_SUBCMD_SET_CREATE(sleep_cmds,
    SHELL_CMD(shell_disable, NULL, "Disable shell ", shell_disable),
    SHELL_SUBCMD_SET_END
);

SHELL_CMD_REGISTER(uart, &sleep_cmds, "Sleep commands", NULL);

also have a standard gpio callback that works fine (low power), and calls this uart_enable(true) to re- enable the uart.

also ran these pieces of code thru k_work_schedule, not to run in ISR context, or not in a "shell command context"

to prove that it is not a context issue.

with

pm_device_action_run(uart, PM_DEVICE_ACTION_SUSPEND); i do observe that current goes to the expected 2.9uA, put i can't get shell to wake and start again.

a solution was to replace the pm_device_action_run commands with

pm_device_runtime_get /

pm_device_runtime_put /

pm_device_runtime_enable

here is my proj.conf

CONFIG_PM_DEVICE=y

CONFIG_PM_DEVICE_RUNTIME=y

#CONFIG_NRFX_UARTE20=y

#CONFIG_PINCTRL=y

#CONFIG_PINCTRL_NRF=y

#CONFIG_PINCTRL_DYNAMIC=y

# Shell

CONFIG_SHELL=y

CONFIG_SHELL_BACKEND_SERIAL=y

CONFIG_UART_CONSOLE=y

# Logging

CONFIG_LOG=y

CONFIG_LOG_DEFAULT_LEVEL=2

CONFIG_LOG_MODE_MINIMAL=n

#CONFIG_LOG_BACKEND_UART=n

CONFIG_LOG_RUNTIME_FILTERING=y              # adds ability to change log levels at runtime

#CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_LOG_CMDS=y                           # shell commands

CONFIG_LOG_PRINTK=y

why is this?

thanks

Dan

 

 

[Benjamin]

Hi Dan,

Thanks for reaching out. I want to confirm that I understand you correctly. You want to control UART using device runtime power management. You created a shell command to suspend UART, and you want to resume UART with a button press, but the shell does not work again afterward.

Have you tested whether only the shell is affected, or if UART itself is not working after the resume?

You also mentioned a solution, but it is not clear whether it resolved the issue or what steps you took. Could you clarify what you tried and whether it fixed the problem?

Regards,
Benjamin

[narfster]

Hi Benjamin,

You understand correctly,

I don;t know how to distinguish if uart, or the shell don't wake.  I do see on current measurements that the expected current when uart is turned back on does not return same consumption.

you can reproduce easily with my steps above, create a simple app with shell, and disable the uart as I did.  Notice the nrf54 dev board goes into minimum power, then try to wake it from the button. you should get the shell and uart back.

use the API pm_device_action_run API to reproduce.

for solution replace pm_device_action_run  API with pm_device_runtime_put API 

[narfster]

Well now, i updated to SDK 3.2.0

Issue is still open.

pm_device_runtime_put  - does not work anymore, does not put uart into sleep.

[narfster]

solved with 

 nrf54 wakeup using uart pins as gpio. 

we can close this.