nRF52840 QSPI Power Consumption

[ntennies]

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()?

[Turbo J]

The flash chip itself consumes much more current when CS is pulled low. The QSPI peripherial keeps CS low when using XIP mode  - in order to minimize acess latency.

You can exit XIP mode by using the regular nrfx_qspi_read()  on a dummy address.

[ntennies]

> The flash chip itself consumes much more current when CS is pulled low

Right, but I don't see how that's relevant here. The QSPI controller is setting nCS high when QSPI is initialized, and we're not performing any operations on the QSPI bus that would cause the QSPI controller to set nCS low. Certainly not in sleep mode.

Also, as I indicated, we're seeing this relatively high power consumption by the QSPI controller even when we configure it to use pins that are not connect to a Flash part, so that can't be what's causing the increase in power consumption.

>  The QSPI peripherial keeps CS low when using XIP mode  - in order to minimize acess latency.. You can exit XIP mode by using the regular nrfx_qspi_read()  on a dummy address

We're not using XIP mode.

[Simonr]

Hi Nathan

Sorry about the inconvenience, but due to the summer vacation period here in Norway, we're low on staff this week, and delayed replies must be expected. 

In order to achieve the lowest possible current consumption when using QSPI, you'll have to uninitialize the QSPI driver. You should also be aware of the erratum 122  present in the nRF52840, so the uninit should look something like this before you go to sleep.

    *(volatile uint32_t *)0x40029010ul = 1ul;
    *(volatile uint32_t *)0x40029054ul = 1ul;
    nrf_drv_qspi_uninit();

Best regards,

Simon

[ntennies]

Simon, thank for you the note about the erratum. However, we'd still like to understand if the  power consumption we're seeing when the QSPI controller is enabled is correct or if it is indicative of a problem. Can you provide numbers regarding expected QSPI controller power consumption at runtime (but when not actively transmitting)?

Specifically, we're seeing power consumption jump by at about 3 mW in run mode just after enabling QSPI but not actively transmitting anything. Is that what we should expect?

[Simonr]

Hi Nathan

I'm sorry, but we don't have any exact numbers of the QSPI current consumption, as this wasn't prioritized for the nRF52840 PS. Yes, the current consumption you're seeing seems to be correct, mostly due to the erratum I mentioned, where the QSPI draws current even if it's not in use. So in order to attain the lowest possible current consumption, you should uninitialize the QSPI like what I did below.

For reference, the current consumption should be similar to those of the SPI depending on which regulator is in use, which HF clock, and the frequency used, as it's the regulator, clock, and DMA that decides the current consumption, and not the peripheral itself.

Best regards,

Simon