NCS v2.4.0: low power by example

[pzuck]

Dear Support team,

I'm involved in the activity to migrate to NCS a project already developed & successfuly tested with using nRF52 SDK v17.1.0, over the custom board initially designed.

That custom board is based on nRF52832_xxAA, battery powered, equipped with an inertial sensor from STM (MEMS) over SPI0, and a 8Mbit flash memory over SPI1, plus some LEDs and one button. The original .dts file is contained in the folder "<ncs_path>\v2.4.0\zephyr\boards\arm\nrf52dk_nrf52832" successfully overlayed for what concerns the custom I/O mapping. Indeed, everything is working fine without MCUBOOT (I'll add it as a final step when everything will be fixed), until I decided to check the power absorbment from the battery that reported around 150 microAmps in "idle" mode (advertising active and the whole system waiting for events).

As I expect an absorbment from 10 to 20 microAmp, I decided to start from the beginning: the "empty" main as reported below:

int main(void)
{
   while(1)
      NRF_POWER->SYSTEMOFF = 1;

   return 0;
}

This "empty" main reports 30.0 microAmps (NCS) against the 0.30 microAmps reported by the same "empty" main in the APP built with SDK v17.1.0, anyone could tell me whats's possibly wrong ?

PS: "CONFIG_SERIAL=n" has been applied already as many posts seeemed to be resolutive, also in the overlay "&uart0" is stated as "disabled".

PS #2: already included and built some examples from zephyr/samples/bluetooth (only advertising just to remain basic) and I never saw an absorbment less than 100 microAmps, therefore I can't exclude the extension nRF Connect for VSCode, as it's common to all test made so far

[Håkon Alseth]

Hi,

 

Could you try setting the /CSN pins for these sensors to the inactive? 

If the SPI Flash is enabled, could you try setting it to a suspended state before entering systemoff?

dev = DEVICE_DT_GET(DT_NODELABEL(my_device));
pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND);

 

Kind regards,

Håkon

[pzuck]

Dear Hakon,

thank you for your prompt reply.

You got the point, indeed, even if no modules were compiled other than "main.c", there was CONFIG_SPI=y in prj.conf still enabled therefore your doubt about SPI initialized before main() was correct. Now the absorbment is back to 0.3 microAmps as reported from my multimeter (see picture attached).

Let me take advantage of your availability to ask you a working example of pm_device_action_run() so that I can understand the correct approach to save power when no resource are needed.

thank you so much for now

regards, Paolo

[Håkon Alseth]

That's correct. CSN is kept inactive, and is handled as a normal gpio by the spi.h API.

If you need to set this to a specific state, for instance if you're powering off the external sensor, it has to be done as a part of your firmware routine for powering on/off the specific sensor.

 

Kind regards,

Håkon

[Miguel Ferreira]

Thanks! Just to clarify, so before entering "sleep" while in SPIM mode I would need to set my CS gpio as input manually ?

[Håkon Alseth]

Hi,

 

No, it is always set to an inactive state after a transaction.

 

Kind regards,

Håkon

[Miguel Ferreira]

Hi,

Can you point me in the code where this is done ? Also to give more context why Im asking putting CS pin as input is due to power consumption, which I believe as input it will consume less. Or as GPIO_OUTPUT_INACTIVE will consume the same more less ?

[Håkon Alseth]

Hi,

 

If you have a specific problem, I would recommend that you create a dedicated thread on the topic and please share as much information as you can wrt. what the problem is and how your application is configured.

GPIO Input vs. output does not do anything wrt. power consumption in this scenario. The only thing that is required is that you pull the signal to a defined level, per the action that is performed.

 

CSN pin is handled by spi.h/spi_context.h:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1/drivers/spi/spi_context.h#L257

 

Kind regards,

Håkon