Low power management of external flash

RE: Low power management of external flash

AHaug — Mon, 24 Mar 2025 13:57:12 GMT

Hi Riccardo,

I see. The approach your going for seems right/possible to implement your own custom solution for power power management. I can't quite see why it shouldn't work given that you design the solution so that it handles the typical edge cases for your product.

Let me know if your testing results in something different,

Kind regards,
Andreas

RE: Low power management of external flash

Riccardo Gaiati — Fri, 21 Mar 2025 09:56:36 GMT

Hi Andreas !

thanks for the reply. I think i understand the approach of the PM APIs by giving to the user of a specific device the possibility to control the low power of the external flash. If i am not wrong, this pattern relies on the user to do the "right thing" according to its needs.

My idea is simply to avoid spreading those apis between the users of the flash and relies only on the driver (spi_nor.c), which will create a single manager of the power management, instead of as many as the users of it.

Since the entry and exit time in low power are measured typically in microseconds, it is reasonable to convert them into ticks (eventually rounded them up) and use those values as input parameters for the delays. I have attached here the modifications i made in the spi_nor.c file. I did not change the wake up sequence, since i am not using (the modifications are pretty straightforward to do in case).

devzone.nordicsemi.com/.../0334.spi_5F00_nor.c

Kind regards

Riccardo

RE: Low power management of external flash

AHaug — Wed, 19 Mar 2025 12:59:11 GMT

Hmm, maybe. I did some looking around because I remembered another case from roughly 1.5 years ago with NCS v2.4.1. At this point in time we had limited/experimental XIP over QSPI support and to showcase how to do a "low" power version of this a colleague of mine created a demo. You might be able to apply a similar application to the logging functionality and/or external flash as done below in the excerpt of main() within the attached xip sample.

The interesting part in the snippet below that I'm referring to is related to

pm_device_action_run(uart_dev, PM_DEVICE_ACTION_RESUME);
pm_device_action_run(flash_dev, PM_DEVICE_ACTION_RESUME);

int main(void)
{
	int blink_status = 0;
	int err;
	
	const struct device *flash_dev = DEVICE_DT_GET(FLASH_NODE);
	const struct device *uart_dev = DEVICE_DT_GET(UART_NODE);

  printk("XIP test sample\n");
  k_sleep(K_SECONDS(1));

  for (;;) {
    printk("Start test loop\n");

#if CONFIG_NORDIC_QSPI_NOR_XIP
    nrf_qspi_nor_xip_enable(flash_dev, true);
    for(int i = 0; i < 10; i++){
      xip_test_write_ext_flash();
      k_sleep(K_MSEC(1));
      printk("XIP external flash write %d\n",i);
    }
#endif

    for(int i = 0; i < 10; i++){
      test_write_ext_flash();
      k_sleep(K_MSEC(1));
      printk("External flash write %d\n",i);
    }

    printk("Disable test loop and sleep for 10 sec\n");
    pm_device_action_run(uart_dev, PM_DEVICE_ACTION_SUSPEND);
    pm_device_action_run(flash_dev, PM_DEVICE_ACTION_SUSPEND);
#if CONFIG_NORDIC_QSPI_NOR_XIP
    xip_enabled = 0;
    nrf_qspi_nor_xip_enable(flash_dev, false);
#endif

    dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);
    k_sleep(K_SECONDS(10));

    pm_device_action_run(uart_dev, PM_DEVICE_ACTION_RESUME);
    pm_device_action_run(flash_dev, PM_DEVICE_ACTION_RESUME);
    xip_enabled = 1;
  }
}

devzone.nordicsemi.com/.../8156.xip_5F00_write_5F00_run_5F00_disable_5F00_feat_5F00_xip_5F00_thread-_2800_3_2900_.zip

I.e you can use PM API to suspend the flash_device when you've finished your activity with/on the external flash, but I'm not sure how well this translates to how to do this with the logging module. Let me know if you have any thoughts w.r.t how suspending the flash device is done in this sample

Kind regards,
Andreas

RE: Low power management of external flash

Riccardo Gaiati — Wed, 19 Mar 2025 09:34:38 GMT

Thanks for the reply.

The logging system is using the littlefs and the external flash. From your reply, i understand that this approach with the PM apis would not work in my case; unless i create a wrapper for the log functions where those PM apis are then invoked.

At this point, i find easier to modify the actual implementation of spi_nor.c where the delays are now defined in TICKS, so that all the other modules that use it are not affected.

#if DT_INST_NODE_HAS_PROP(0, t_enter_dpd)
#define T_DP_US (DT_INST_PROP(0, t_enter_dpd) / NSEC_PER_USEC)
#define T_DP_TICK (k_us_to_ticks_near32(T_DP_US))
#else /* T_ENTER_DPD */
#define T_DP_MS 0
#endif /* T_ENTER_DPD */
#if DT_INST_NODE_HAS_PROP(0, t_exit_dpd)
#define T_RES1_US (DT_INST_PROP(0, t_exit_dpd) / NSEC_PER_USEC)
#define T_RES1_TICK (k_us_to_ticks_near32(T_RES1_US))

Honestly, i dont see why this approach cannot be considered in the future, instead of rounding up to 1 ms all the delays to enter and exit the low power of a flash. Is there an official place where a proposal like this can be done ?

Thanks again for your support.

RE: Low power management of external flash

AHaug — Wed, 19 Mar 2025 08:54:38 GMT

Hi,

Yes, if I understand your question correct. The logging system itself doesn't automatically call PM functions, but if you're for instance logging over UART you can use the PM API to suspend the UART device, somewhat similar to what's shown below and thus disable/enable logging:

const struct device *uart0_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));  
pm_device_action_run(uart0_dev, PM_DEVICE_ACTION_SUSPEND);

From here you can resume the UART device when you need it to enable logging again. I believe this public case might still be relevant, allthough it is >2 years old. Do note that some API's and configs may have changed from the relevant NCS version at that point in time and the latest and greatest now in 2025: Nordic Q&A: nRF52840 Power Management when idle.

Let me know if I understood your question properly and please clarify if I missed what you were referring to

Kind regards,
Andreas

RE: Low power management of external flash

Riccardo Gaiati — Tue, 18 Mar 2025 16:21:36 GMT

Hi,

thanks for the reply.

Regarding the PM APIs, i can control the entry ti and exit from low power of the flash through those functions. But what about the log system ? Would it call these function aswell ?

RE: Low power management of external flash

AHaug — Tue, 18 Mar 2025 13:36:09 GMT

Hi,

[quote user=""]1. Why the need to convert in milliseconds those delays (in the specific case, causing an increase between 30 and 100 times) ?[/quote]

In the API we're using we're rounding up to nearest ms. If your device are capable of running with those delays and your activity can handle it (and you can handle the extra current consumption that might come with this), you're free to test out using 30 and 10 µs instead.

[quote user=""]2. For such kind of microseconds delay would not be better to use even a blocking delay like NRFX_DELAY_US ? (I have modified the spi.nor file and seems to work properly)[/quote]

If it works and you've tested it properly, then you should be able to use the nrfx_delay_us instead, but note that we've only tested with what is present in the SDK by default

[quote user=""]3. Is there a way - even i looked for but could not find it - to enable the power management for the external flash at runtime ? So in my case, it would be disabled at the boot up and once done, it gets enabled.[/quote]

PM device API: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/pm/index.html

[quote user=""]4. Eventually, could this change be considered in the future version of sdk ?[/quote]

I'm not 100% sure this is relevant after you've seen through the PM device in item 3, but let me know if that change sanything

Kind regards,
Andreas