Skip to content

nrf52: high standby current on nrf52840 when using MCUBOOT + UART_ASYNC_API + PM_DEVICE #90466

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mjm987 opened this issue May 25, 2025 · 3 comments
Assignees
Labels
area: UART Universal Asynchronous Receiver-Transmitter bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug

Comments

@mjm987
Copy link

mjm987 commented May 25, 2025

Describe the bug
When using CONFIG_PM_DEVICE up to Zephyr v3.7 the standby current was about 6 uA by setting pm_device_action_run(uart0, PM_DEVICE_ACTION_SUSPEND) with or without any combination of CONFIG_UART_ASYNC_API and/or CONFIG_BOOTLOADER_MCUBOOT.

But since Zephyr v4.0 the standby current after pm_device_action_run(uart0, PM_DEVICE_ACTION_SUSPEND) is between 0.5mA and 1mA when using following config combination :
CONFIG_PM_DEVICE=y + CONFIG_UART_ASYNC_API=y + CONFIG_BOOTLOADER_MCUBOOT=y

If either CONFIG_UART_ASYNC_API=n or no MCUBOOT is used, the current is as expected.

To Reproduce

  1. Use eg. the Nordic nRF52840DK board (-b nrf52840dk/nrf52840).

  2. Use blinky sample

  3. Add in prj.conf:
    CONFIG_PM_DEVICE=y
    CONFIG_UART_ASYNC_API=y
    CONFIG_SERIAL=y
    CONFIG_LOG=y
    CONFIG_BOOTLOADER_MCUBOOT=y

  4. Replace in main.c::main() the printk() statement by:
    pm_device_action_run(DEVICE_DT_GET(DT_NODELABEL(uart0)), PM_DEVICE_ACTION_RESUME);
    LOG_INF("LED state: %s\n", led_state ? "ON" : "OFF");
    while (log_process()) ;
    pm_device_action_run(DEVICE_DT_GET(DT_NODELABEL(uart0)), PM_DEVICE_ACTION_SUSPEND);

Expected behavior
The standby current should be about 6uA

Impact
The standby current is about 500uA ... 1000uA

Environment (please complete the following information):

Zephyr >= v4.0 (tested with v4.0 and v4.1)

@mjm987 mjm987 added the bug The issue is a bug, or the PR is fixing a bug label May 25, 2025
@henrikbrixandersen henrikbrixandersen added the platform: nRF Nordic nRFx label May 26, 2025
@github-project-automation github-project-automation bot moved this to To triage in nRF platform May 26, 2025
@dkalowsk dkalowsk added the priority: low Low impact/importance bug label May 27, 2025
@nordicjm nordicjm added the area: UART Universal Asynchronous Receiver-Transmitter label May 28, 2025
@nordic-piks nordic-piks moved this from To triage to Backlog in nRF platform Jun 5, 2025
@nordic-piks nordic-piks assigned nvlsianpu and unassigned anangl and masz-nordic Jun 5, 2025
@carlescufi
Copy link
Member

carlescufi commented Jun 5, 2025

@nvlsianpu and @nordicjm could MCUboot be leaving a peripheral turned on?
@nordic-krch any clues?
@bjarki-andreasen adding you here since there's PM device involved

@nordic-krch
Copy link
Collaborator

if it's only when MCUBOOT is present then i would check this: #75703 uart driver does not attempt to do any cleanup for the bootloader. If it is needed application need to do that before UART is initialized.

@mjm987
Copy link
Author

mjm987 commented Jun 5, 2025

Unfortunately the cleanup as shown in #75703 did not help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: UART Universal Asynchronous Receiver-Transmitter bug The issue is a bug, or the PR is fixing a bug platform: nRF Nordic nRFx priority: low Low impact/importance bug
Projects
Status: Backlog
Development

No branches or pull requests

10 participants