nrf5340 SDK 1.9.1 idle mode consumption and power management

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Wed, 20 Jul 2022 10:07:10 GMT

If you can't find v1.9.2 it in the TCM, this is the way to upgrade in Windows

cd /nrf
git fetch
git checkout v1.9.2
west update

If you don't want to mess with the v1.9.1 ncs folders (which you're using now), you can just install NCS v1.9.0 from TCM and run the above commands from there

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Tue, 19 Jul 2022 18:19:37 GMT

Thank you..

I am unable to see an option install and try 1.9.2 from Toolchain manager.. as you know, 2.0.0 doesn't seem to support SES (just installing that SDK seems to break all previous versions as i had tried it and quickly uninstalled the SDK) and I am at the EVT phase and don't want to try anything adventurous at this time. I am also using toolchain manager v1.1.1 but I see 1.1.3 is available. could that be the reason why I don't see 1.9.2 ? last time I upgraded TCM, it was a nightmare for a few days and hence trying to stick to what's working :-)

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Tue, 19 Jul 2022 10:59:07 GMT

[quote user="sshenoy105"]thank you for all your help.. while i wouldn't say this has been completely resolved, all your inputs were very useful and helped..[/quote]

I'm happy to help :)

[quote user="sshenoy105"]I will file new tickets [/quote]

Thanks

[quote user="sshenoy105"]As you know, your ticket search is fairly horrible :-)[/quote]

You could also try to search using Google, using this approach:

Please also check out NCS v1.9.2 (or NCS v2.0.0), where an issue was fixed that caused HF clock to stay active, which caused an increased current consumption.

https://github.com/nrfconnect/sdk-nrf/commit/1ae47b06abb2ecc567f64844db9f0147fb873186#diff-6d407a77922a4d622d288c698bbdd11187fe0d4975764b0a82fa52f9a3e7b9f4R82

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Fri, 15 Jul 2022 21:33:01 GMT

thank you for all your help.. while i wouldn't say this has been completely resolved, all your inputs were very useful and helped.. I will file new tickets .. Only reason i wanted to continue here is o be useful for many others who will have similar power consumption questions and hence will have one place to look at. As you know, your ticket search is fairly horrible :-)

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Fri, 15 Jul 2022 21:19:17 GMT

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Mon, 11 Jul 2022 14:31:23 GMT

I'm happy you found one cause of the high current consumption.

[quote user="sshenoy105"]I do have a few more things to check.. I am doubting I2C current (when not doing transactions) is not as low as what's mentioned in the nrf5340 spec and will disable them while not in use and enable only when needed and see if that helps[/quote]

Would you be able to open a new ticket about this? I know that this question is still in in-scope of this ticket, but I see that this ticket is starting to get quite long and unorganized, also current consumption is not my expertise, so if you open a new ticket it will get assigned to an engineer with more knowledge about this. A huge part of the support team are on vacation, so it may take a little longer time than usual before you get a reply.

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Mon, 11 Jul 2022 14:22:56 GMT

Sorry for the delay. A huge part of the support team are on summer vacation and you may expect delays.

I was not able to reproduce this. I added the following to zephyr/samples/hello_world/prj.conf (NCS v2.0.0):

CONFIG_PM=y
CONFIG_PM_DEVICE=y

I also added the following under #ifdef CONFIG_PM_DEVICE=y in uart_nrfx_uarte.c∗:

#error "CONFIG_PM_DEVICE is enabled!!"

and when building the sample, this error message popped up.

I also saw CONFIG_PM_DEVICE=y in zephyr/samples/hello_world/build/zephyr/.config

∗For uart0, the driver uart_nrfx_uarte.c will be used by default, this is because the compatible field in the uart0 node is set to "nordic,nrf-uarte" by default. See zephyr/dts/arm/nordic/nrf5340_cpuapp_peripherals.dtsi#L85. Also the nRF5340 does not have a UART peripheral, only UARTE (the nRF52840 for example, has both UART and UARTE).

The difference between UART and UARTE is that UARTE uses EasyDMA. Read more in UART and UARTE difference.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Fri, 08 Jul 2022 18:33:02 GMT

one more weird thing i noticed..

v1.9.1\zephyr\drivers\serial\uart_nrfx_uart.c

in line #1147.. CONFIG_PM_DEVICE seems to be not enabled while proj.conf has it enabled (and i see it enabled in other modules).. This is ok if UART is disabled but useful when we need som eprints and the ability to shut UART down

had to replace the #ifdef CONFIG_PM_DEVICE with #if 1

//#ifdef CONFIG_PM_DEVICE
#if 1
static int uart_nrfx_pm_action(const struct device *dev,
enum pm_device_action action

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Thu, 07 Jul 2022 23:04:37 GMT

Simon,

found one issue that seems to help get better power numbers.. we use SPI4 to access our NAND chip and looks like CS (SS) was low even when SPI4 is uninitialized.. Since our Nand is powered all the time, this CS staying low seems to trigge tit to some kind of active mode and henc etalke almost 500uA extra current. Checked SPI code..

Found that SPI uninit API from Nrf SDK doesn't configure the CS (SS) pin to pull up .. needed SDK change in the function
spi uninit with CS pull up
void nrfx_spim_uninit(nrfx_spim_t const * p_instance) in C:\ncs\v1.9.1\modules\hal\nordic\nrfx\drivers\src\nrfx_spim.c
if (p_cb->ss_pin != NRFX_SPIM_PIN_NOT_USED)
{
//nrf_gpio_cfg_default(p_cb->ss_pin);
nrf_gpio_cfg_spi(p_cb->ss_pin); ----> newly added
}

new api nrf_gpio_cfg_spi in C:\ncs\v1.9.1\modules\hal\nordic\nrfx\hal\nrf_gpio.h
NRF_STATIC_INLINE void nrf_gpio_cfg_spi(uint32_t pin_number)
{
nrf_gpio_cfg(
pin_number,
NRF_GPIO_PIN_DIR_INPUT,
NRF_GPIO_PIN_INPUT_DISCONNECT,
NRF_GPIO_PIN_PULLUP,
NRF_GPIO_PIN_S0S1,
NRF_GPIO_PIN_NOSENSE);
}

Checked with the probe that this ensure CS stays high.. and now i see my baseline current below 500uA..

I do have a few more things to check.. I am doubting I2C current (when not doing transactions) is not as low as what's mentioned in the nrf5340 spec and will disable them while not in use and enable only when needed and see if that helps

I confirm that k_cpu_idle gets called but given only way to confirm that was using the debugger, I didn't bother checking the power numbers..

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Mon, 04 Jul 2022 09:25:28 GMT

I'm sorry to hear about that. Feel free to open a new ticket about that issue, or engage in (Missing Forum Thread)

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Thu, 30 Jun 2022 18:32:37 GMT

Unfortunately, I was stupid enough to trust "Tool chain manager" update and updated.. now my environment is broken as observed by many in the community and plenty of tickets flying around exactly like this one.. so can't do much.. I really have no idea why do you guys do this to us :-)

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Thu, 30 Jun 2022 16:34:17 GMT

I ran the hello_world sample with nrf5340dk_nrf5340_cpuapp with the following modification in idle.c-->idle():

if (pm_system_suspend(_kernel.idle) == false) {
	printk("pm_system_suspend() returned false");
	k_cpu_idle();
}else{
	printk("pm_system_suspend() returned true");
}

I disabled UART/serial logging and used RTT instead

I saw that "pm_system_suspend() returned false" was printed, which means that k_cpu_idle() will run and put the system to System ON sleep.

Do you see the same? Even in the case where pm_system_suspend() does not suspend the system (returns false), the k_cpu_idle() should still be called and put the chip into system ON sleep (2-3uA).

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Wed, 29 Jun 2022 20:03:28 GMT

@simon,
I use the same board files as nrf5340dk.. a few pins are modified using overlay..
i put a few prints and can confirm that we never enter idle..

No suitable power state found for cpu: 0! ---->from struct pm_state_info pm_policy_next_state(uint8_t cpu, int32_t ticks)
No PM operations done. id 0 ---> from function bool pm_system_suspend(int32_t ticks) in pm.c
suspend failed ---> added this line in idle.c if (pm_system_suspend(_kernel.idle) == false)

why would this be ? in the zephyr.dts file created after build, i don;t see any entries for cpu-power-states or min-residency-us which is needed by PM to go to low power modes..

Can you please help me understand this ?

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Tue, 28 Jun 2022 01:13:59 GMT

@simon,
I use the same board files as nrf5340dk.. a few pins are modified using overlay..
i put a few prints and can confirm that we never enter idle..

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Fri, 24 Jun 2022 16:31:13 GMT

I provided you some answers to more of your questions. However, since my reply ended up in the middle of the reply-stack, you might not notice it. So I'm referring to it here: https://devzone.nordicsemi.com/support-private/support/290899#permalink=768551

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Fri, 24 Jun 2022 16:27:28 GMT

[quote user="sshenoy105"]By default, the high voltage regulator is configured to also source external components from the VDD pin. To save power this feature should be disabled. For details, see High voltage mode[/quote]

I think what is meant by this is that normal voltage mode uses less power than high voltage mode. If you aren't using VDD as power, or if you already have an external regulator on the board you can enable normal voltage. To enable normal voltage mode, you connect VDD to VDDH (so that VDD equals VDDH), then the high voltage regulator (VREGH) will be bypassed.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Thu, 23 Jun 2022 22:26:43 GMT

you may have missed this in my cluster of replies.. can you please respond to the following ?

While I wait for any further help, I have couple of questions.. looking at this post, especially the following: Can you please let me know what Zephyr/Nrf APIs to use to achieve what ever is being recommended as they seem worth trying

By default, the high voltage regulator is configured to also source external components from the VDD pin. To save power this feature should be disabled. For details, see High voltage mode
All regulators operate in LDO mode by default. DC/DC mode can be enabled independently for each regulator. The advantage of using a regulator in DC/DC mode is that the overall power consumption is reduced.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Thu, 23 Jun 2022 15:10:42 GMT

[quote user="simoniversen"]I will do some testing tomorrow and upload a new hex f[/quote]

Okay, now I created a hex file, based on the hello_world with CONFIG_SERIAL=n.

I executed these steps:

Run nrfjprog --recover --coprocessor CP_NETWORK && nrfjprog --recover
Run nrfjprog --program app_core_image2.hex --chiperase
- I have attached app_core_image2.hex
- If --coprocessor is not specificed it will program to app core by default
Run nrfjprog --pinreset

devzone.nordicsemi.com/.../app_5F00_core_5F00_image2.hex

Do the same on your end, and let me know you result. Then we can continue searching for the cause.

Best regards,

Simon

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Thu, 23 Jun 2022 01:14:42 GMT

while I wait for any further help, I have couple of questions.. looking at this post, especially the following: Can you please let me know what Zephyr/Nrf APIs to use to achieve what ever is being recommended as they seem worth trying

By default, the high voltage regulator is configured to also source external components from the VDD pin. To save power this feature should be disabled. For details, see High voltage mode
All regulators operate in LDO mode by default. DC/DC mode can be enabled independently for each regulator. The advantage of using a regulator in DC/DC mode is that the overall power consumption is reduced.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Tue, 21 Jun 2022 22:55:21 GMT

[quote user="sshenoy105"]I will also try a few things with one of the examples like you mentioned and see .. hello world as is with no changes except CONFIG_SERIAL=n should consume less than 3 uA on nordic 5340 DK right ?[/quote]

Yes, that is correct, program the hello world sample (with CONFIG_SERIAL=n) to the application core. However, if stuff is running on the netcore, that may consume current. Try erasing both of the cores before programming the hello world sample: nrfjprog --recover --coprocessor CP_NETWORK && nrfjprog --recover

However, if you have added a custom board folder, you might have enabled Kconfigs there that causes a high current consumption, so I can't say for certain that hello world with uart disabled will be sufficient. I will do some testing tomorrow and upload a new hex file.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Tue, 21 Jun 2022 22:45:35 GMT

Also, between Bluetooth events the chip goes into System ON sleep. What is your floor current? Could you check if it enters System ON sleep (2-3 uA) between peripheral and Bluetooth events/interrupts?

I was around 1.4mA.. Last night, I did find an issue with our touch controller power saving mode fixing which saved me about 200uA.. my floor is close to 1.2mA right now.. One strange thing is this floor remains the same when UART is enabled or not which i fid a bit suspect..

I am not expecting anywhere near 2-3uA given all my components and their quiescent currents.. In fact, at least two of my components are always on.. I am trying to understand why i see suspend failed print (when i enable prints) a and make sure no matter what cpu goes to sleep when it is supposed to..

I will also try a few things with one of the examples like you mentioned and see .. hello world as is with no changes except CONFIG_SERIAL=n should consume less than 3 uA on nordic 5340 DK right ?

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Tue, 21 Jun 2022 16:32:50 GMT

If your goal is to find the cause of the high current consumption I would recommend you to start with a really simple sample. For example the hello_world sample with CONFIG_SERIAL=n in prj.conf. Erase both of the cores and program the sample. Then you should se a current of around 2-3 uA. Using this approach you can easily figure out if the high current consumption is due to the firmware or the custom board

The hex file in the initial reply was copied from an older ticket I handled, and I think it was ahello world sample with CONFIG_SERIAL=n. I re-test this tomorrow and upload a new hex file to be certain.

So if you still see a high current consumption with this ample, you know the custom hardware is the cause.

Questions

I have some knowledge about current consumption, but I'm not an expert. But I will answer the questions I know the answer to and ask some colleagues about the rest tomorrow.

[quote user=""]1a. FPU is ON.. does it make any difference (we need it and hence can't turn it off).. [/quote]

Will get back to you about this

[quote user=""]1b: shutting UART off should reduce power by 500uA right ? or is it more ? [/quote]

Yes, that is correct, it will consume around 500uA. Remember to disable it (set CONFIG_SERIAL=n) in all child images. In addition to the ones you mentioned, it may be b0n (netboot, which is a bootloader for netcore) or b0 (secure bootloader for appcore).

[quote user=""]3. do we have to add CONFIG_PM=y and CONFIG_PM_DEVICE=y to mcuboot and hci_rpmsg conf files too ? I haven't tried it yet[/quote]

As far as I'm aware, it should not be necessary to set these for the child images. I will test this tomorrow and get back to you.

In the main application, CONFIG_PM should be enabled by default, and I don't think you necessarily need to set CONFIG_PM_DEVICE=y to decrease the current consumption, unless you want to use the pm_device_action_run() function (with this function you can enable UART in prj.conf, and disable it in the application when it's not used).

Actually Zephyr will handle almost everything regarding current consumption, and you don't need to do too much. The most important thing is to disabe UART. When the CPU is not doing any work, the idle thread will run and the chip will go into System ON sleep (2-3uA). All the peripherals, except UART I think, will release the HFCLK when they're idle (even if CONFIG_PM_DEVICE=n). Also, between Bluetooth events the chip goes into System ON sleep. What is your floor current? Could you check if it enters System ON sleep (2-3 uA) between peripheral and Bluetooth events/interrupts?

I will get back to you about the rest of the questions tomorrow.

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

sshenoy105 — Mon, 20 Jun 2022 23:16:57 GMT

Thank you for getting back quickly.. I flashed the images you attached.. I see a current consumption of 540-580uA on my board.. I can look at that and see what's consuming this (assuming your image put the system to sleep)..

but would appreciate your responses to my questions/concerns

RE: nrf5340 SDK 1.9.1 idle mode consumption and power management

Simon — Mon, 20 Jun 2022 12:53:21 GMT

Before looking into all your questions, try the following:

Run nrfjprog --recover --coprocessor CP_NETWORK && nrfjprog --recover
Run nrfjprog --program app_core_image.hex --chiperase
- I have attached app_core_image.hex
- If --coprocessor is not specificed it will program to app core by default
Run nrfjprog --pinreset

After I completed these steps I saw a current of 2.5uA on the nRF5340 DK

devzone.nordicsemi.com/.../7180.app_5F00_core_5F00_image.hex

Best regards,

Simon