Deep power mode of QSPI

[Shang Ting]

I am trying to minimize the power consumption of serial flash. Is there any example for DPM of QSPI? 

[haakonsh]

We do not have an example as each flash chip seems to have a unique way of entering DPM. You'll need to read the datasheet of the flash you're using and set the proper registers as according to the nRF52840 PS:

Deep power-down mode

The external flash memory can be put in deep power-down mode (DPM) to minimize its current consumption when there is no need to access the memory.

DPM is enabled in the IFCONFIG0 register and configured in the DPMDUR register. The DPM status of the external memory can be read in the STATUS register. The DPMDUR register has to be configured according to the external flash specification to get the information in the STATUS register and the timing of the READY event correct.

Entering/exiting DPM is controlled using the IFCONFIG1 register.

[royalbee]

Maybe you can provide DPM example for one specific flash device, in order to understand the flow needed to enter and exit DPM?

It is not clear when to set each of the DPM related registers and also how to do that in conjunction with the call to nrfx_qspi_uninit():  do we need to modify the registers inside the uninit() code ?

Maybe use macronix flash (that is used on the DK) for such example?

This will be very helpful, thanks.

[haakonsh]

I can notify the developers that there's a need for a DPM example, but it will take quite some time until it will reach the SDK.

You can set the DPMDUR and IFCONFIG0.DPMENABLE register at any time after you've called nrfx_qspi_init, then I believe you write to   IFCONFIG1.DPMEN to enter or exit DPM.

Why do you need to uninit the qspi driver, do you intend to go into SystemOFF?

[royalbee]

Without calling uninit to the qspi driver, it keeps consuming (a lot of) power.
BTW, I think that it is a design-problem in the SDK that this function is actually called "uninit" and not "close"  (since we should call open and close on each read/write operation and not init and uninit).

As for DPM, I already managed to make it work on our flash device, after figuring out the main issues (including how to set the dpm-duration register).
It seems like my suggestion to use the DK flash for your example won't be the best, since DK flash starts in DPM mode by default, so getting it into DPM won't change anything..

[haakonsh]

royalbee said:

Without calling uninit to the qspi driver, it keeps consuming (a lot of) power.

That's not good, the peripheral should enter a low power mode when there's no ongoing task, at least other peripherals behave in this manner. Hopefully, your workaround does not have a huge impact on your application. 

 

royalbee said:

BTW, I think that it is a design-problem in the SDK that this function is actually called "uninit" and not "close"  (since we should call open and close on each read/write operation and not init and uninit).

It will be hard to convince the developers to use another term for the QSPI driver as init/uninit is the term used for all other drivers.

royalbee said:

As for DPM, I already managed to make it work on our flash device, after figuring out the main issues (including how to set the dpm-duration register).

 That register is a bit hard to find, good job on getting it to work

[Gordon]

Does anyone have a link to a working example for getting DPM working? I'm struggling a bit.

By setting/unsetting QSPI_IFCONFIG1_DPMEN when sleeping I seem to be able to get total system consumption down from 3mA to 0.8mA, but with old old bit-bashing method I was getting 0.1mA, so something is still drawing excess power.

And then there's the issue of XIP - if an interrupt wakes the device up and we try and access the XIP address before DPMEN has been disabled, it locks up.