Low power management of external flash

Hi,

my setup is the following:

- SDK 2.6.3

- nRF5340

- Low power management for external flash enabled

- Logging enabled (based on littleFS)

- external flash used to store continuously data 

With this configuration i am observing an exponential increase of booting time due to the introduction of the the entry to and exit from low power of the external flash as defined in the file \v2.6.3\zephyr\drivers\flash\spi_nor.c.

The characteristic of my external flash for entry and exit the deep sleep mode are the following:

- 30us to enter in Deep Power down mode

- 10us to exit Deep Power down mode

Those values are rounded up to 1 ms each by the defines in \v2.6.3\zephyr\drivers\flash\spi_nor.c 

1. Why the need to convert in milliseconds those delays (in the specific case, causing an increase between 30 and 100 times) ?

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)

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.

4. Eventually, could this change be considered in the future version of sdk ?

Thanks in advance for your support.

Kind regards

Riccardo Gaiati

 

Parents
  • Hi,

    1. Why the need to convert in milliseconds those delays (in the specific case, causing an increase between 30 and 100 times) ?

    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.

    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)

    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

    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.

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

    4. Eventually, could this change be considered in the future version of sdk ?

    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

  • 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 ? 

Reply
  • 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 ? 

Children
  • 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:

    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
  • 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.

    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.

  • 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);

    8156.xip_write_run_disable_feat_xip_thread (3).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

  • 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).

    Kind regards

    Riccardo 

  • 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