NRF5340 power management

RE: NRF5340 power management

Dker19 — Thu, 01 Jun 2023 11:39:01 GMT

Thanks Susheel Nuguru , So I can achieve this using lower down the peripherals like uart, radio etc. For other power handing I need to check, If you have some additional thoughts and some examples please share them here for power handling. help will be appreciated.

RE: NRF5340 power management

amar_d11 — Thu, 01 Jun 2023 11:11:05 GMT

"Yes, but you can add your own power handling that you think is suitable to your application."

can you please provide an example of how to do it?

RE: NRF5340 power management

Susheel Nuguru — Thu, 01 Jun 2023 10:57:27 GMT

[quote user="Dip1993"]

So other states like

1. PM_STATE_RUNTIME_IDLE
2. PM_STATE_SUSPEND_TO_IDLE
3. PM_STATE_STANDBY
4. PM_STATE_SUSPEND_TO_RAM
5. PM_STATE_SUSPEND_TO_DISK

are not supported by nrf5340? Can you please confirm?

[/quote]

Yes, but you can add your own power handling that you think is suitable to your application. We seems to have only implemented the deep sleep power state in the power manager.

RE: NRF5340 power management

Dker19 — Thu, 01 Jun 2023 10:40:35 GMT

khelmutlord I am working on nrf5340 dk board, I just want to confirm power state supported by nrf5340. As per your pointer only supported power management state is PM_STATE_SOFT_OFF. So other states like

1. PM_STATE_RUNTIME_IDLE
2. PM_STATE_SUSPEND_TO_IDLE
3. PM_STATE_STANDBY
4. PM_STATE_SUSPEND_TO_RAM
5. PM_STATE_SUSPEND_TO_DISK

are not supported by nrf5340? Can you please confirm? also, I required to lower the the power consumption so if I don't want to reset the board which will be reset if I use PM_STATE_SOFT_OFF. So what is the best way to do that. do I need to suspend the peripherals like uart,radio etc without using putting device in any power management state.

Thanks,

Dker19

RE: NRF5340 power management

Dker19 — Mon, 29 May 2023 16:11:20 GMT

Susheel Nuguru khelmutlord wifiuser

I required the device should be run in low power mode when there is no work to do. so I gone through the state.h and found that there are different states. So I choose PM_STATE_RUNTIME_IDLE or PM_STATE_SUSPEND_TO_IDLE so just curious like if I select one of them then on some event how to wakeup the device to a normal state.

Also is there any best state other than PM_STATE_SOFT_OFF which help my device to save more power without losing its context?

Do I just need to disable/suspend the resources that are taking more power, this will save the power consumption of the battery. CPU will automatically go into sleep mode?

Can you please enlighten why there are different modes and When to use them? like, PM_STATE_RUNTIME_IDLE, PM_STATE_SUSPEND_TO_IDLE, PM_STATE_STANDBY and

PM_STATE_SUSPEND_TO_RAM.
Also how to use them?

RE: NRF5340 power management

khelmutlord — Thu, 25 May 2023 14:35:05 GMT

Looking at the code for the nRF5340's power management, you can see that the only supported power management state is PM_STATE_SOFT_OFF.

https://github.com/zephyrproject-rtos/zephyr/blob/69d0dce978e11a17e6605a42067374ca56767483/soc/arm/nordic_nrf/nrf53/power.c#L10

Each driver (UART, for example) supports certain power management modes as well:

https://github.com/zephyrproject-rtos/zephyr/blob/fd346e846f1474468cd2bd67e7208b9560edd60e/drivers/serial/uart_nrfx_uart.c#LL1070C12-L1070C31

i.e. PM_DEVICE_ACTION_SUSPEND and PM_DEVICE_ACTION_RESUME

If the default UART driver uses too much power, consider using the Nordic LPUART library.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/uart_nrf_sw_lpuart.html#uart-nrf-sw-lpuart

Thanks,

Helmut Lord

RE: NRF5340 power management

amar_d11 — Thu, 25 May 2023 05:01:43 GMT

What can be done to create a simple scenario where an application has a gpio and an uart and the end goal is to put the system in sleep mode?

using

PM_STATE_SOFT_OFF

is not the solution for me .

how to use the other power down modes ?

RE: NRF5340 power management

Susheel Nuguru — Wed, 24 May 2023 17:14:11 GMT

This thread have somehow escaped my working queue and looking at the events it seems like I clicked some wrong button by mistake. I did not get this to work but since I did not hear from the author to remind me, I am guessing that they managed to make it work?

RE: NRF5340 power management

amar_d11 — Wed, 24 May 2023 11:49:48 GMT

struct pm_state_info sleep_state = {PM_STATE_SUSPEND_TO_RAM, 0, 0};
pm_state_force(0u, &sleep_state);

how did you get this working??

did you make any changes to

pm_state_set(); ?

Susheel Nuguru

RE: NRF5340 power management

Susheel Nuguru — Fri, 02 Dec 2022 11:57:45 GMT

I managed to reproduce this and I am not able to make SPIM2 or 4 to go to low power mode.

I have to dive a bit deeper into the lib and driver for this and rule out if this is a firmware issue. But since i am able to reproduce this, it is possible find the root cause for this. I will keep you updated. Thanks for your patience so far.

RE: NRF5340 power management

Susheel Nuguru — Wed, 30 Nov 2022 09:00:33 GMT

Hi Oral, sorry for the delays, I will try to use your project settings today and debug this.

RE: NRF5340 power management

Susheel Nuguru — Fri, 18 Nov 2022 10:18:06 GMT

Honestly, I have not tried this myself or seen any samples doing this.

So I need to do some experimentation to see how this is done. I might have to attempt to do that early next week and provide you a solution for that.

RE: NRF5340 power management

wifiuser — Tue, 15 Nov 2022 15:55:36 GMT

My last issue now is how to effectively set the SPIM2 and SPIM4 into SUSPEND mode?

RE: NRF5340 power management

Susheel Nuguru — Tue, 15 Nov 2022 05:45:09 GMT

Good to hear that the crash issue is resolved.

RE: NRF5340 power management

wifiuser — Mon, 14 Nov 2022 14:07:35 GMT

The crash for pm_device_action_run(i2c_dev, PM_DEVICE_ACTION_SUSPEND) turned out to be a hardware issue. After switching boards it worked as expected. I had created another ticket for that as you suggested and updated that ticket to show that.

RE: NRF5340 power management

Susheel Nuguru — Mon, 14 Nov 2022 08:58:36 GMT

Orai, Sorry for late response.

Regarding my comment regarding PM_DEVICE_DT_DEFINE(SPIM(idx), we need to put that on hold.

I have tried to replicate the issue you have by trying to modify the systemoff sample, but I am not able to replicate the crash your were mentioning when using pm_device_action_run(i2c_dev, PM_DEVICE_ACTION_SUSPEND);

Can I get your project so that I can do some quick tests on what your contexts your application is calling power management calls.

RE: NRF5340 power management

wifiuser — Thu, 10 Nov 2022 16:51:55 GMT

Any updates on this issue?

RE: NRF5340 power management

Susheel Nuguru — Tue, 08 Nov 2022 15:37:05 GMT

Orai, I am sorry for delay, I was OoO and could not test this. I will test this tomorrow.

RE: NRF5340 power management

wifiuser — Mon, 07 Nov 2022 16:05:17 GMT

Have you been able to verify the issue I am seeing and figure out a possible solution? Any updates/solution would be great.

thanks.

RE: NRF5340 power management

wifiuser — Thu, 03 Nov 2022 17:51:55 GMT

I attached a reduced version of my project with just SPIM2 to show the SPIM2 compilation issue I see when I want to include the PM_DEVICE_DT_DEFINE

devzone.nordicsemi.com/.../reduced_5F00_proj.zip

RE: NRF5340 power management

wifiuser — Wed, 02 Nov 2022 13:51:48 GMT

I would rather not post my entire project publicly. Can I get a private link to upload it so only you can see and debug it?

RE: NRF5340 power management

Susheel Nuguru — Wed, 02 Nov 2022 13:11:32 GMT

I have not tried this combo before, So I need to evaluate this myself, can you please upload your project here so that I can try to debug this myself here? It seems like the spi config and default pinctrl config are not allowing us to enable the SPIM2 instance, but not sure what extra needs to be done here.

RE: NRF5340 power management

wifiuser — Mon, 31 Oct 2022 16:08:36 GMT

Thanks for the reply sorry to include so many different questions. I will open a different ticket for the other points as you suggested.

Based on your reply, I see that in order to get the power management for SPIM2 enabled I have to this define

PM_DEVICE_DT_DEFINE(SPIM(idx), spim_nrfx_pm_action);

enabled but, that requires

#define SPI_NRFX_SPIM_DEVICE(idx)

After looking at https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/spi/spi_nrfx_spim.c I see

CONFIG_SPI_2_NRF_SPIM has to be enabled. It is not settable directly according to the documentation.

In order to get that defined, I added these two new settings to my prj.conf file

CONFIG_SPI=y

CONFIG_SPI_NRFX=y

This results in a build error below for the expansion of that macro with regards to PINCTRL and legacy pins. What setting am I missing in my config file to get the PM_DEVICE_DT_DEFINE for my peripherals? Code builds fin and runs OK with those two settings but the power management doesn't get enabled.

-c C:/ncs/v2.0.0/zephyr/drivers/spi/spi_nrfx_spim.c
In file included from C:\ncs\v2.0.0\zephyr\include\zephyr\toolchain.h:50,
from C:\ncs\v2.0.0\zephyr\include\zephyr\init.h:10,
from C:\ncs\v2.0.0\zephyr\include\zephyr\device.h:29,
from C:\ncs\v2.0.0\zephyr\include\zephyr\drivers\spi.h:24,
from C:\ncs\v2.0.0\zephyr\drivers\spi\spi_nrfx_spim.c:7:
C:\ncs\v2.0.0\zephyr\include\zephyr\toolchain\gcc.h:77:36: error: static assertion failed: "/soc/peripheral@50000000/spi@b000 has legacy *-pin properties defined although PINCTRL is enabled"
77 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
| ^~~~~~~~~~~~~~
c:\ncs\v2.0.0\zephyr\soc\arm\nordic_nrf\common\soc_nrf_common.h:229:2: note: in expansion of macro 'BUILD_ASSERT'
229 | BUILD_ASSERT(!IS_ENABLED(CONFIG_PINCTRL) || \
| ^~~~~~~~~~~~
C:\ncs\v2.0.0\zephyr\drivers\spi\spi_nrfx_spim.c:518:2: note: in expansion of macro 'NRF_DT_CHECK_PIN_ASSIGNMENTS'
518 | NRF_DT_CHECK_PIN_ASSIGNMENTS(SPIM(idx), 1, \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.0.0\zephyr\drivers\spi\spi_nrfx_spim.c:586:1: note: in expansion of macro 'SPI_NRFX_SPIM_DEVICE'
586 | SPI_NRFX_SPIM_DEVICE(2);
| ^~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.0.0\zephyr\include\zephyr\toolchain\gcc.h:77:36: error: static assertion failed: "/soc/peripheral@50000000/spi@a000 has legacy *-pin properties defined although PINCTRL is enabled"
77 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert(EXPR, "" MSG)
| ^~~~~~~~~~~~~~
c:\ncs\v2.0.0\zephyr\soc\arm\nordic_nrf\common\soc_nrf_common.h:229:2: note: in expansion of macro 'BUILD_ASSERT'
229 | BUILD_ASSERT(!IS_ENABLED(CONFIG_PINCTRL) || \
| ^~~~~~~~~~~~
C:\ncs\v2.0.0\zephyr\drivers\spi\spi_nrfx_spim.c:518:2: note: in expansion of macro 'NRF_DT_CHECK_PIN_ASSIGNMENTS'
518 | NRF_DT_CHECK_PIN_ASSIGNMENTS(SPIM(idx), 1, \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.0.0\zephyr\drivers\spi\spi_nrfx_spim.c:594:1: note: in expansion of macro 'SPI_NRFX_SPIM_DEVICE'
594 | SPI_NRFX_SPIM_DEVICE(4);
| ^~~~~~~~~~~~~~~~~~~~
[140/431] Building C object zephyr/drivers/eeprom/CMakeFiles/drivers__eeprom.dir/eeprom_handlers.c.obj
[141/431] Building C object zephyr/drivers/spi/CMakeFiles/drivers__spi.dir/spi_handlers.c.obj
[142/431] Linking C static library zephyr\drivers\i2c\libdrivers__i2c.a
[143/431] Linking C static library zephyr\drivers\sensor\libdrivers__sensor.a
[144/431] Linking C static library zephyr\drivers\sensor\tmp116\libdrivers__sensor__tmp116.a
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: 'c:\ncs\toolchains\v2.0.0\opt\bin\cmake.EXE' --build 'c:\Projects\VHI\Code\oncodisc\build'

RE: NRF5340 power management

Susheel Nuguru — Mon, 31 Oct 2022 08:00:09 GMT

[quote user=""]What devices are supported by pm_device_action_run? It runs OK in the sample for UART0 listed above but not for I2C1 or SPI2.[/quote]

Here you can see that the uart/i2c/spi implements the pm actions so it should be ok to call pm_actions on any of these peripherals as long as you are using nrfx drivers for these.

[quote user=""]Does the peripherals have to be un-initialized and the pins configured in output low mode for the greatest power saving?[/quote]

The pin configurations and their release/assignment to the peripherals should be taken care by the drivers when they implement the pm states. The application should not do anything else apart from knowing that it does not start any transactions on the peripherals before calling the power management functions. I fyou look in zephyr\drivers\i2c\i2c_nrfx_twim.c you can see life in function i2c_nrfx_twim_recover_bus that the driver tries to set the pin states to the config that suits the state

[quote user=""]What is the correct order of operation for the peripherals:

For wakeup? Set to active state, then initialize or vice versa?
For sleep? Set to suspend then un-initialize or vice versa?

[/quote]

1. I would first initialize the peripheral and state the active state.
2. I would first uninitialize the peripheral and set to suspend.

[quote user=""]Should I even bother trying to run a pm_device_action_run on the I2C1, SPIM2, etc... or will the power management set that for me automatically?[/quote]

The drivers in the nrfx lib implements the callback for the pm action, so the application can call them when needed.

[quote user=""]I have a tmp117 attached to I2C1 and am using the zephyr driver to communicate with it. How do you unconfigure the I2C1? Again is it even necessary to configure it, use it then unconfigure it after use to achieve power savings?[/quote]

Please create a separate thread for this.

[quote user=""]Do I need to setup power states in my overlay file? I didn't see one in the sample I sited above.[/quote]

No, i do not see or know any pm states that you can set in device tree. There are some pinctrl states you can set for the pins but not for the peripherals.

Please create separate tickets for the rest of the points, please do not mix too many questions into one as they tend to flood the ticket with unrelated info which is difficult to search for others.

RE: NRF5340 power management

Susheel Nuguru — Fri, 28 Oct 2022 13:38:04 GMT

Seems like a lot of questions bundled into one thread. I will go through them on Monday and will try to answer you point by point.