Power consumption on nrf5340 when idle is about 4mA, how to get it lower?

I have a custom board, with nrf5340, nrf7002 on it.

I would like to get the uA levels of power consumption I see other nrf5340 projects talk about (eg here  How to achieve low power consumption on custom nRF5340 board.  ) when my application is idle and the wifi is off (ie 

net_if_down(net_if_get_default());
which gives same result as actually turning off the IOVDD control)

I read here  Optimizing Power on nRF5340 SoC Designs that I need to just set

CONFIG_PM=y
CONFIG_PM_DEVICE=y
and it should enter the lowest power mode possible automatically..But this post and many others are all using old versions of NCS, and it seems the PM stuff has evolved?

On my Otii, the lowest power consumption I can see is about 4mA! This is with everything on my board held in reset or power off, and PM/PM_DEVICE enabled.

Any pointers on how to get the nrf5340 to actually go into a state where we are looking at <1mA (with RAM preservation)?

Parents
  • Hi BrianW,

    Only information regarding CONFIG_PM is outdated. The System Power Management (PM) API controls the CPU state. However, as the nRF5340 only has two states, System ON and System OFF, support for PM has been dropped, and going into System OFF is done via the Power Off API instead.

    What kind of RAM retention are you looking for? With System OFF, the system reinitializes when it wakes up. Some level of RAM retention is possible, still.

    As for CONFIG_PM_DEVICE, it enables the Device Power Management API, which let you put the "Device" in DeviceTree, so peripherals and/or sensors with drivers, into different power state. It supports two methods, runtime and system-managed. Because the nRF5340 doesn't have System PM, you will need to use the runtime API and manually disable each device.
    The runtime API is enabled with CONFIG_PM_DEVICE_RUNTIME, and usage of the API is explained in that blog post.

    We also have this documentation: Optimizing application.

    I think perhaps the peripherals weren't disabled since you misunderstood the Device PM API a little. Could you please check again?

    Hieu

  • Only information regarding CONFIG_PM is outdated. The System Power Management (PM) API controls the CPU state. However, as the nRF5340 only has two states, System ON and System OFF, support for PM has been dropped, and going into System OFF is done via the Power Off API instead.

    Ok, so you really need to update or flag the blog post with this information.

    What kind of RAM retention are you looking for? With System OFF, the system reinitializes when it wakes up. Some level of RAM retention is possible, still.

    I do not want to turn the system off, I want it to be in the lowest possible power state when it is in the idle state in zephyr. I expected this to be automatic, but apparently not....

    Because the nRF5340 doesn't have System PM, you will need to use the runtime API and manually disable each device.

    And where do I do this? How does my app code 'know' that zephyr is in the idle state? I understand I can turn off different devices, but I only want (for example) the UART to be off when the app is idle (which I don't know as there are multiple tasks in the system eg for the wifi stack).

    Is there a sample showing how to get a proper low power application running, eg one of the ble operational cases? I saw a post here https://github.com/zephyrproject-rtos/zephyr/issues/41382 which makes the same point.... he then goes to hack various parts of the uart code to get it to deal with the idle -> power off case, but I don't want to go changing the core NCS source! (already had to do that for other 'features' and its not sustainable). Also his MCU seems to be a nrf52, and the NCS version is old (2.6 I think)

    btw, even if I turn off all my external hardware on my board, including the nrf70, then do sys_poweroff() : its still sucking around 3.2mA....this is not what I expected from a Nordic MCU...

    Can you give me some example code that actually gets proper low power operation using the device PM API here?

    Brian

Reply
  • Only information regarding CONFIG_PM is outdated. The System Power Management (PM) API controls the CPU state. However, as the nRF5340 only has two states, System ON and System OFF, support for PM has been dropped, and going into System OFF is done via the Power Off API instead.

    Ok, so you really need to update or flag the blog post with this information.

    What kind of RAM retention are you looking for? With System OFF, the system reinitializes when it wakes up. Some level of RAM retention is possible, still.

    I do not want to turn the system off, I want it to be in the lowest possible power state when it is in the idle state in zephyr. I expected this to be automatic, but apparently not....

    Because the nRF5340 doesn't have System PM, you will need to use the runtime API and manually disable each device.

    And where do I do this? How does my app code 'know' that zephyr is in the idle state? I understand I can turn off different devices, but I only want (for example) the UART to be off when the app is idle (which I don't know as there are multiple tasks in the system eg for the wifi stack).

    Is there a sample showing how to get a proper low power application running, eg one of the ble operational cases? I saw a post here https://github.com/zephyrproject-rtos/zephyr/issues/41382 which makes the same point.... he then goes to hack various parts of the uart code to get it to deal with the idle -> power off case, but I don't want to go changing the core NCS source! (already had to do that for other 'features' and its not sustainable). Also his MCU seems to be a nrf52, and the NCS version is old (2.6 I think)

    btw, even if I turn off all my external hardware on my board, including the nrf70, then do sys_poweroff() : its still sucking around 3.2mA....this is not what I expected from a Nordic MCU...

    Can you give me some example code that actually gets proper low power operation using the device PM API here?

    Brian

Children
No Data
Related