This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Regarding usage of power management config files

Hi,

   I am using nrf5340 kit. I would like to enable and test power management in mesh chat example.

1.  Can you please tell me the usage of below config file usage.

                  #define CONFIG_PM 1
                  #define   CONFIG_PM_DEEP_SLEEP_STATES 1

                  #define CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1 1

2. Can you please tell me which power mode will be default during SYSTEM ON  

                  a) CONSLAT

                   b) LOWPWR

3. Configurations which should be enabled in prj.config file for power management.

4. Also tell me how the clock initialization takes place in nrf connect sdk based codes

               a) Is this requires Zephyr rtos for initialization

                b) How the clock control is possible in application and network core

                 c) Will all the  nrf mesh examples use the network and application clocks together.

 5. Kindly tell me which config file should be enabled for waking up all the peripherals and CPU from idle state.

6. Is there examples in nrf connect sdk which explains the power and clock management code flow in a detailed way.

Parents
  • Hi

    1. CONFIG_PM is explained here. As for CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1 and CONFIG_PM_DEEP_SLEEP_STATES, where did you find these? Can you provide some information on this, as I didn't find any reference to these defines in the Zephyr, KConfig or NCS documentation.

    2. This depends on what project you're using. Typically you'll need to use constant latency only if for instance you need to take an action within <1us, the current consumption will be higher in constant latency mode. In low power mode, the current consumption is a very few uA and is the common usage for any battery powered product.

    3. Please check out the power management subsystem in Zephyr and NCS power manager module documentation for more information on this.

    4.

    a) Is what required in Zephyr RTOS for initialization? I'm afraid I don't understand the question?

    b) How clock control is done in and between the two cores on the nRF53 is done in the Power Management Unit inside the SoC. Please see the Power and Clock management section in the PS for details.

    c) Yes, only the network core will have access to the radio peripheral in nRF53, and in most cases (unless the application is very simple) the application core will need to run the actual application.

    5. I don't think this would be a config file, but rather a call to a task waking the device up.

    6. See links in question 3.

    Best regards,

    Simon

Reply
  • Hi

    1. CONFIG_PM is explained here. As for CONFIG_HAS_POWER_STATE_DEEP_SLEEP_1 and CONFIG_PM_DEEP_SLEEP_STATES, where did you find these? Can you provide some information on this, as I didn't find any reference to these defines in the Zephyr, KConfig or NCS documentation.

    2. This depends on what project you're using. Typically you'll need to use constant latency only if for instance you need to take an action within <1us, the current consumption will be higher in constant latency mode. In low power mode, the current consumption is a very few uA and is the common usage for any battery powered product.

    3. Please check out the power management subsystem in Zephyr and NCS power manager module documentation for more information on this.

    4.

    a) Is what required in Zephyr RTOS for initialization? I'm afraid I don't understand the question?

    b) How clock control is done in and between the two cores on the nRF53 is done in the Power Management Unit inside the SoC. Please see the Power and Clock management section in the PS for details.

    c) Yes, only the network core will have access to the radio peripheral in nRF53, and in most cases (unless the application is very simple) the application core will need to run the actual application.

    5. I don't think this would be a config file, but rather a call to a task waking the device up.

    6. See links in question 3.

    Best regards,

    Simon

Children
Related