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

[pzuck]

Hi Hakon,

In your scope screenshot I don't see /CSN going low for 1 sec by the call:

       pm_device_action_run(spi_dev, PM_DEVICE_ACTION_SUSPEND);

therefore the sensor (virtual in your scenario) will never turn OFF.

If everything worked we should see two times CS hi-low-hi transaction. The first very short as SPI read from sensor, the second with a duration of 1000 ms

Let me know

thank you, Paolo

[Håkon Alseth]

Hi,

 

The idle level of /CSN is high. If you power off your external sensor, you need to set that pin low to ensure that you're not back-powering your external sensor.

Here's a way to set/clr the GPIO:

#include <hal/nrf_gpio.h>


...
nrf_gpio_pin_clear(DT_SPI_DEV_CS_GPIOS_PIN(DT_NODELABEL(spi0_cs)));
pm_device_action_run(spi_dev, PM_DEVICE_ACTION_SUSPEND);
...
nrf_gpio_pin_set(DT_SPI_DEV_CS_GPIOS_PIN(DT_NODELABEL(spi0_cs)));
pm_device_action_run(spi_dev, PM_DEVICE_ACTION_RESUME);

 

Kind regards,

Håkon

[pzuck]

Hi Hakon,

I would need to call nrf_gpio_pin_clear() to put low also the signals CLK,MISO,MOSI. Then remove the modification I made in "spi_nrfx_spi.c".

How can I get CLK,MISO,MOSI pin numbers like what you made for CS with "DT_SPI_DEV_CS_GPIOS_PIN(DT_NODELABEL(spi0_cs))" ?

thank you, Paolo

[Håkon Alseth]

Hi.

CLK and MOSI should be set as output, low, when you have placed the device in PM_DEVICE_ACTION_SUSPEND:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.3.99-ncs1/drivers/pinctrl/pinctrl_nrf.c#L122C1-L140

 

MISO is input to the nRF, which'll be low when your external device is powered off.

 

Are you seeing that the pins are high in the _SUSPEND state?

 

Kind regards,

Håkon

[Miguel Ferreira]

Hi,

Sorry to jump in a old issue but I have some doubts also regarding pm_device_action_run(m_spi_dev, PM_DEVICE_ACTION_SUSPEND) on spi device. Basically, when entering in suspend the SPI driver should configure the CS pin but this config is being skipped:



Where the default config is:

RF_STATIC_INLINE void nrf_gpio_cfg_default(uint32_t pin_number)

{

nrf_gpio_cfg(

pin_number,

NRF_GPIO_PIN_DIR_INPUT,

NRF_GPIO_PIN_INPUT_DISCONNECT,

NRF_GPIO_PIN_NOPULL,

NRF_GPIO_PIN_S0S1,

NRF_GPIO_PIN_NOSENSE);

How can I config the CS pin without the driver skipping it ?

Thank you!

[Håkon Alseth]

Hi,

 

pinctrl takes over and configures the state based on your DT configuration:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1/drivers/spi/spi_nrfx_spim.c#L546-L557

 

CSN is kept inactive (effectively handled as a normal gpio output, controlled by the spi.h API), and not touched by the devicetree.

 

Kind regards,

Håkon

[Miguel Ferreira]

Correct, but for example de SS pin is not changed to input because we are skipping the gpio_cfg. I debug the code since the point you mentioned and the nrf_gpio_cfg_default is always skipped. Am I correct ?

Also:

#if defined(NRF_PSEL_SPIM)

case NRF_FUN_SPIM_SCK:

NRF_PSEL_SPIM(reg, SCK) = pin;

write = 0U;

dir = NRF_GPIO_PIN_DIR_OUTPUT;

input = NRF_GPIO_PIN_INPUT_CONNECT;

break;

case NRF_FUN_SPIM_MOSI:

NRF_PSEL_SPIM(reg, MOSI) = pin;

write = 0U;

dir = NRF_GPIO_PIN_DIR_OUTPUT;

input = NRF_GPIO_PIN_INPUT_DISCONNECT;

break;

case NRF_FUN_SPIM_MISO:

NRF_PSEL_SPIM(reg, MISO) = pin;

dir = NRF_GPIO_PIN_DIR_INPUT;

input = NRF_GPIO_PIN_INPUT_CONNECT;

break;

#endif /* defined(NRF_PSEL_SPIM) */

I dont see the CS pin being changed here

[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