Disabling QSPI draws much current SDK15+

[Cyril]

Hello,

I know this question has been asked but it's still unanswered, and I kind of need a solution...

On our custom board, I removed power from Flash and kept sending SPI commands*, then uninit QSPI and it works as expected:

• 783uA if I don't uninit QSPI
• 272uA once uninit on my board

As soon as I have a QSPI Flash wired: 

• 792uA once Flash powered down, QSPI not uninit
• 2mA as soon as I try to uninit QSPI

May it be related to RX?

* SPI commands are: QSPI_STD_CMD_RSTEN, QSPI_STD_CMD_RST, CMD_DEVICE_ID (0x9F), CMD_DEEP_PWRDOWN (0xB9).

I also tried with QSPI driver from SDK 15.2 (with nrf_qspi_disable(NRF_QSPI); used after the workaround) with no luck.

Best,

Cyril

[haakonsh]

Are you measuring the current of both the nRF52840 and the ext flash? If so I suggest you isolate the two devices and measure the current consumption of each individually. This will help you determine which device has the excessive current consumption. 

You should also halt the CPU after you've shut down the QSPI peripheral and read the QSPI registers, I'd like to see the state of the various registers.

[Cyril]

I broke 2 on my Power Profiler Kit (values have a huge offset)... waiting to get a new one and I will get all that answers for you. 

[Cyril]

Hello,

EDIT: Bug found. CS line has to be set high before QSPI uninit, otherwise Flash was woke up.

---

FYI, Flash is Macronix mx25r64 on our board.

Here are the results of my measurements:

Flash consumption:

• Flash init and powered off (0xB9 command): 7uA going through Flash
• Flash not init: 1.975mA going through Flash

All system consumption:

• Flash init / our system in off state: 670uA  (EDIT: I re-enabled QSPI during my tests which wasn't the expected behavior, see post below)
• Flash removed / our system in off state: 90uA

Meaning, when I communicate with the Flash using QSPI, it consumes about 500uA and never goes back to normal.

Here is the code powering down Flash:

    nrf_qspi_cinstr_conf_t cinstr_cfg = {
        .opcode    = CMD_DEEP_PWRDOWN,
        .length    = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true, /* High level during transmission */
        .io3_level = true, /* High level during transmission */
        .wipwait   = true,
        .wren      = false};

    uint32_t err_code = nrfx_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);
    APP_ERROR_CHECK(err_code);
    
    nrfx_qspi_uninit();
    

If I comment nrfx_qspi_uninit(); I still have 670uA.

Here is a memory dump corresponding to the QSPI registers once uninit:

Let me know if you find something wrong. (EDIT: something is wrong, QSPI is enabled)

Best

[Cyril]

Offset 0x500: ENABLE still equals 0x1 which is not normal.
After QSPI uninit, it is actually 0 but then it goes back to 1 for any reason. 

I will update the ticket soon.

[Cyril]

I finally found where the issue comes from after some tests I thought that Flash was actually awake as current was around 2mA. (Nice shot haakonsh)

All I had to do was to set CS line to GPIO output, and high level.
Then uninit QSPI and it goes well.
Flash might be woke up when trying to uninit.

    // uninit qspi
    nrf_gpio_cfg_output(QSPI_CS2);
    nrf_gpio_pin_set(QSPI_CS2);

    nrfx_qspi_uninit();

Best
Cyril

[haakonsh]

That's strange, the CS line should be held high after the last transaction has finished and until the uninitialization of the driver puts the CS line into a high impedance state. Maybe there's a leakage to ground from the CS line, creating a weak pulldown that sets the line to ground potential once the CS pin is in its high impedance state.