• State Suggested Answer
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 66 subscribers
  • Views 678 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 327765
Options

Subscribing to power manager events.

kat829

Hi!

I am trying to subscribe to the power management events that correspond to the following log lines (which I can clearly see in the log):

I: POWER event ready
I: POWER event removed
I: SUSPEND state detected
I: RESUMING from suspend

I have been trying with this code:

#include "power.h"
#include <zephyr/logging/log.h>
#include <zephyr/drivers/gpio.h>
#include <zephyr/sys/util.h>
#include <zephyr/pm/device.h>
#include <zephyr/pm/state.h>
#include <zephyr/pm/pm.h>

LOG_MODULE_REGISTER(my_module, LOG_LEVEL_INF);

void pm_notifier_cb(enum pm_state state)
{
    printk("PM: %i", state);
}

static struct pm_notifier notifier = {
    .state_entry = pm_notifier_cb,
    .state_exit = pm_notifier_cb,
};

void InitPower(void) {
    printk("Power Init");
    pm_notifier_register(&notifier);
}

I have extended prj.conf with:

CONFIG_PM_DEVICE_RUNTIME=y
CONFIG_PM_DEVICE=y
CONFIG_PM=y


Results:

  • - "Power Init" is getting printed just fine
  • - but the callback is never called.

Setup:

  • - NCS_VERSION=v2.6.0
  • - Running from Ubuntu
  • - Any other info needed?

Any idea what I am doing wrong?

Parents
  • 0

    Hello,

    Support for the PM subsystem (CONFIG_PM, not CONFIG_PM_DEVICE) was removed in SDK v2.5.0 by this commit: https://github.com/nrfconnect/sdk-zephyr/commit/96b38273138f05dd06cf7a58fa361f401e773e5e. So, unless you have reverted this change, you should be getting a Kconfig warning in your build output stating that the CONFIG_PM symbol did not end up being selected. 

    Does this application allow the idle thread to be run?

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Well, as for warnings, I am getting this, but to tell the truth I find it rather unintelligible and the "see ..." section is not very helpful:

    warning: PM (defined at soc/arm/silabs_exx32/efr32bg22/Kconfig.defconfig.series:18,
soc/arm/silabs_exx32/efr32bg27/Kconfig.defconfig.series:18,
soc/arm/silabs_exx32/efr32mg24/Kconfig.defconfig.series:19,
soc/arm/st_stm32/stm32f4/Kconfig.defconfig.series:20, subsys/pm/Kconfig:13) was assigned the value
'y' but got the value 'n'. Check these unsatisfied dependencies: ((SOC_SERIES_EFR32BG22 &&
SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32BG27 && SOC_FAMILY_EXX32) || (SOC_SERIES_EFR32MG24 &&
SOC_FAMILY_EXX32) || SOC_SERIES_STM32F4X || (SYS_CLOCK_EXISTS && HAS_PM)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_PM and/or look up PM in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

    The relevant excerpt from `kernel threads` and thread analyzer logs (after adding some `CONFIG_THREAD_ANALYZER` options) is:
    $kernel threads 

...

 0x2000cfc0 idle
        options: 0x1, priority: 15 timeout: 0
        state: , entry: 0x5e245
        Total execution cycles: 999756 (72 %)
        stack size 320, unused 272, usage 48 / 320 (15 %)

 0x2000d098 main
        options: 0x1, priority: 0 timeout: 17
        state: suspended, entry: 0x5d731
        Total execution cycles: 193498 (14 %)
        stack size 2048, unused 1128, usage 920 / 2048 (44 %)

...

Thread analyze:
 idle                : STACK: unused 272 usage 48 / 320 (15 %); CPU: 73 %
      : Total CPU cycles used: 1442089
 main                : STACK: unused 1128 usage 920 / 2048 (44 %); CPU: 13 %
      : Total CPU cycles used: 271937
 ISR0                : STACK: unused 904 usage 1144 / 2048 (55 %)

    Based on this I would say that yes it is allowed to run.

    (I have removed other threads since they are a potentially sensitive information.)

  • 0 in reply to kat829

    The warning indicates that CONFIG_PM can't be enabled due to missing dependencies (HAS_PM), which is expected since we have removed PM support. However, I assumed you had reverted the changes from the commit since the pm_notifier_register() function definition was included in your build (pm.c, which implements this function, should only be included if CONFIG_PM is selected).

    Since PM is not supported, I would recommend that you look at other alternatives to acheive what you want. Could you say a bit more about what you are trying to acheive? From the thread analyzer you can see that your application is spending 72% of the time in sleep (SYSTEM ON).

  • 0 in reply to Vidar Berg

    > However, I assumed you had reverted the changes from the commit

    No.

    > Could you say a bit more about what you are trying to acheive?

    I would like to know whether the device is running on battery, so that I can adjust power-consumption-related features. E.g., decrease intensity of led lights, or turning them off after some timeout.

  • 0 in reply to kat829

    Thanks for the clarification. pm_notifier_register(), which isn't supported for the nRF series,  is used to register callbacks for when the chip is entering and exiting sleep. It doesn't tell you if the chip is battery or mains powered. 

  • 0 in reply to Vidar Berg

    I see.

    So where do the mentioned POWER log lines come from?

    I: POWER event ready
I: POWER event removed

Reply Children
Related