This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Zephyr power management issues

Dear Nordic, 

As per power management, could you please suggest any thoughts for following:

We have two ICs on the board connected to nRF52840: 6-DOF sensor (over SPI) and flash mem (over QSPI). Both of them are powered from one external LDO regulator controlled by GPIO output, and there is a 'regulator' node has been defined for it. 

1. 'nordic,qspi-nor' device node model doesn't include 'vin-supply' parameter, how we could connect it to regulator to take automatic control over QSPI flash power?

2. When accessing 6-DOF sensor, we need to take manual control over it's powering, and - when it is not in work - it should be disabled completely, including SPI lines. For now, when we turn off the regulator manually, the SPI lines stays active and give parasitic supply to the sensor and increase overall consumption. What approach is preferred to implement here? Something like that? (https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/subsys/pm/device_pm/src/main.c)

Parents
  • Hi

    1. Yes, in order to add a 'vin-supply' field I'd recommend making a custom implementation of the QSPI driver with this field.

    2. That sounds like a good idea if you need to manage the power usage of multiple external devices, as PM_DEVICE_RUNTIME lets devices be suspended/resumed based on device usage.

    3. The SPI documentation specifies that a GPIO node is supposed to be used when instantiating a SPI_CS_CONTROL structure. 

    Thank you for notifying us of the missing bracket. I've reported it internally.

    Best regards,

    Simon

  • Hi Simonr,

    1. OK.

    2. Yes, we've implemented. For clarity, could you please suggest: 

    a) when PM_DEVICE_RUNTIME is enabled, should we turn-off device power on init or turn-on by default? Different device drivers have different implementations, and example (dummy_driver) is disabled (turned off) by default. What's the common approach?

    b) when PM_DEVICE_RUNTIME is disabled (and PM_DEVICE) still enabled, should we enable device power by default?

    c) at which usecases we should use PM_DEVICE without PM_DEVICE_RUNTIME?

    3. Yes, but it isn't turned off when SPI driver goes to suspended state, and this pin provides parasitic power for the sensor, leads to 14 uA consumption in addition.

    For the SPI driver, could you please consider the following suggestions to the driver's source?

    For spi_context.h:

    // @ctmlab added ->

    static inline void spi_context_cs_deconfigure(struct spi_context *ctx)

    {

    if (ctx->config->cs && ctx->config->cs->gpio_dev) {

    gpio_pin_configure(ctx->config->cs->gpio_dev,

    ctx->config->cs->gpio_pin,

    GPIO_DISCONNECTED);

    } else {

    LOG_INF("CS control inhibited (no GPIO device)");

    }

    }

    // <-

    For spi_nrfx_spim / spim_nrfx_pm_control():

    case PM_DEVICE_STATE_LOW_POWER:

    case PM_DEVICE_STATE_SUSPEND:

    case PM_DEVICE_STATE_OFF:

    if (data->pm_state == PM_DEVICE_STATE_ACTIVE) {

    nrfx_spim_uninit(&config->spim);

    // @ctmlab 2021-09-10 added ->

    struct spi_context *ctx = &get_dev_data(dev)->ctx;

    spi_context_cs_deconfigure(ctx);

    // <-

    }

    break;

    For spi_nrfx_spim / spim_nrfx_pm_control():

Reply
  • Hi Simonr,

    1. OK.

    2. Yes, we've implemented. For clarity, could you please suggest: 

    a) when PM_DEVICE_RUNTIME is enabled, should we turn-off device power on init or turn-on by default? Different device drivers have different implementations, and example (dummy_driver) is disabled (turned off) by default. What's the common approach?

    b) when PM_DEVICE_RUNTIME is disabled (and PM_DEVICE) still enabled, should we enable device power by default?

    c) at which usecases we should use PM_DEVICE without PM_DEVICE_RUNTIME?

    3. Yes, but it isn't turned off when SPI driver goes to suspended state, and this pin provides parasitic power for the sensor, leads to 14 uA consumption in addition.

    For the SPI driver, could you please consider the following suggestions to the driver's source?

    For spi_context.h:

    // @ctmlab added ->

    static inline void spi_context_cs_deconfigure(struct spi_context *ctx)

    {

    if (ctx->config->cs && ctx->config->cs->gpio_dev) {

    gpio_pin_configure(ctx->config->cs->gpio_dev,

    ctx->config->cs->gpio_pin,

    GPIO_DISCONNECTED);

    } else {

    LOG_INF("CS control inhibited (no GPIO device)");

    }

    }

    // <-

    For spi_nrfx_spim / spim_nrfx_pm_control():

    case PM_DEVICE_STATE_LOW_POWER:

    case PM_DEVICE_STATE_SUSPEND:

    case PM_DEVICE_STATE_OFF:

    if (data->pm_state == PM_DEVICE_STATE_ACTIVE) {

    nrfx_spim_uninit(&config->spim);

    // @ctmlab 2021-09-10 added ->

    struct spi_context *ctx = &get_dev_data(dev)->ctx;

    spi_context_cs_deconfigure(ctx);

    // <-

    }

    break;

    For spi_nrfx_spim / spim_nrfx_pm_control():

Children
No Data
Related