We're using the nRF52840 on a battery-powered device that requires very low power consumption, both in run mode and also in the Cortex-M4 sleep / deep sleep modes. We've recently identified the QSPI controller as an apparent consumer of a lot of power. For instance:
- On our board, we see under 0.4 mA current draw (which is good) if we do the following:
- power on our Flash
- init the QSPI controller, but perform no QSPI operations
- uninit the QSPI controller
- set our Flash's nCS pin output-high (since the QSPI controller isn't doing that anymore)
- enter deep sleep
- However, we see about 1.6 mA current draw if we do exactly the same but just let QSPI continue to be enabled (we don't uninit the QSPI controller or set nCS output-high)
- To eliminate the possibility of our Flash part contributing to this, we modded our firmware to change the QSPI interface to use six unconnected pins on our board. With this configuration we see about 0.3 mA current draw if we do the following:
- init the QSPI controller, but perform no QSPI operations
- uninit the QSPI controller
- enter deep sleep
- However, we see about 1.85 mA current draw if we do exactly the same but don't uninit the QSPI controller.
- Determining the impact of enabling QSPI in Run mode is a little tricker, but when we use the interactive debugger to step past nrfx_qspi_init(), we see current draw immediately jump by about 0.7 mA.
- Reducing the QSPI clockspeed doesn't seem to affect the current draw in these scenarios.
- We've verified that the board is staying in deep sleep mode once it enters that mode
Our primary question is, Is it correct that we should be seeing the QSPI controller use so much power when enabled -- 1.2 mA or more while in sleep mode, and at least 0.7 mA in run mode -- even when it is not actually in use?
Our secondary question is, Are there any options for significantly reducing the QSPI controller power consumption in run and sleep modes, other than calling nrfx_qspi_uninit()?
