Cannot exit deep power down mode (QSPI flash)

RE: Cannot exit deep power down mode (QSPI flash)

Adam Varga — Fri, 04 Jul 2025 09:17:48 GMT

Hey robca !

I just wanted to give a shoutout to your thorough investigation and good find on the zephyr commit! I faced this exact issue with my Seeed XIAO Sense board with the P25Q16H flash on it, but incorporating that trick solved the problem without needing to modify any SDK file. Thx a lot!

If anyone faces this issue, this is how my fix looks like:

static uint32_t *QSPI_Status_Ptr = (uint32_t*) 0x40029604;  // Setup for the SEEED XIAO BLE - nRF52840

static nrfx_err_t QSPI_IsReady(void) {
    if (((*QSPI_Status_Ptr & 8) == 8) && (*QSPI_Status_Ptr & 0x01000000) == 0) {
        return NRFX_SUCCESS;
    } else {
        return NRFX_ERROR_BUSY;
    }
}

static nrfx_err_t QSPI_WaitForReady(void) {
    while (QSPI_IsReady() == NRFX_ERROR_BUSY) {
        // TODO timeout
    }
    return NRFX_SUCCESS;
}

static nrfx_err_t QSPI_RDPWorkaroundInit(void) {
    nrfx_err_t err_code;
    nrf_qspi_pins_t pins;
    nrf_qspi_pins_get(NRF_QSPI, &pins);
    nrf_qspi_pins_t disconnected_pins = {
			.sck_pin = NRF_QSPI_PIN_NOT_CONNECTED,
			.csn_pin = NRF_QSPI_PIN_NOT_CONNECTED,
			.io0_pin = NRF_QSPI_PIN_NOT_CONNECTED,
			.io1_pin = NRF_QSPI_PIN_NOT_CONNECTED,
			.io2_pin = NRF_QSPI_PIN_NOT_CONNECTED,
			.io3_pin = NRF_QSPI_PIN_NOT_CONNECTED,
    };
    nrf_qspi_pins_set(NRF_QSPI, &disconnected_pins);

    nrf_qspi_enable(NRF_QSPI);
    nrf_qspi_event_clear(NRF_QSPI, NRF_QSPI_EVENT_READY);
    nrf_qspi_task_trigger(NRF_QSPI, NRF_QSPI_TASK_ACTIVATE);

    err_code = QSPI_WaitForReady();
    nrf_qspi_pins_set(NRF_QSPI, &pins);
    return err_code;
}

static nrfx_err_t QSPI_SendRDP(void) {
    nrfx_err_t err_code;
    
    // Send RDP cmd to wake up flash from DPM
    nrf_qspi_cinstr_conf_t cinstr_cfg_rdp = {
        .opcode    = 0xAB,
        .length    = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true,
        .io3_level = true,
        .wipwait   = false,
        .wren      = true
    };

    err_code = nrfx_qspi_cinstr_xfer(&cinstr_cfg_rdp, NULL, NULL);
    QSPI_WaitForReady();
    return err_code;
}

nrfx_err_t QSPI_FlashInit(void) {
    nrfx_err_t err_code;
    nrfx_qspi_config_t config = NRFX_QSPI_DEFAULT_CONFIG;
    // TODO: set up config according to your needs
    err_code = nrfx_qspi_init(&config, NULL, NULL);
    if(err_code == NRFX_SUCCESS) {
        NRF_LOG_INFO("QSPI flash inited successfully");
    } else {
        NRF_LOG_ERROR("QSPI flash init error (%d), possibly due to flash RDP. Trying workaround...", err_code);
        if (QSPI_RDPWorkaroundInit() == NRFX_SUCCESS) {
            NRF_LOG_INFO("QSPI flash inited successfully with RDP workaround.");
            if (QSPI_SendRDP() != NRFX_SUCCESS) {
                NRF_LOG_ERROR("Could not wake up flash from deep power-down mode!);
            } else {
                return NRFX_SUCCESS;
            }
        } else {
            NRF_LOG_ERROR("QSPI flash init failed.");
        }
    }
    return err_code;
}

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Fri, 05 Jul 2024 13:12:06 GMT

Hello,

If you are able to make it work while disconnecting the QSPI pins, I would say that this is better. It doesn't require any extra GPIOs, and it doesn't actually output/input a physical signal to a disconnected GPIO.

It shouldn't really matter, but it sounds "cleaner" in my opinion.

Best regards,

Edvin

RE: Cannot exit deep power down mode (QSPI flash)

robca — Thu, 04 Jul 2024 18:26:37 GMT

I just realized that this same issue has been found and reported on the Zephyr-based SDK Connect https://github.com/zephyrproject-rtos/zephyr/pull/64782

Looking at the commit (https://github.com/zephyrproject-rtos/zephyr/commit/1727bbcc7046eb5870df7409310d58e0c9483233), they used a different strategy than mine: instead of defining IO1 as pulldown, the QSPI peripheral is initialized with NRF_QSPI_PIN_NOT_CONNECTED for every pin, the RDP command sent, then QSPI is re-enabled normally

Edvin can you please provide input on the safest way to send an RDP for SDK 17.1.0? Use IO1 pulldown or disconnect the QSPI pins? I do realize that SDK 17.1.0 is in maintenance mode, so I'm not asking for a fix, just an opinion on the best option to work around it.

RE: Cannot exit deep power down mode (QSPI flash)

robca — Sat, 29 Jun 2024 19:17:08 GMT

I decided to test with a modified nrfx_qspi.c implementation. I cloned nrfx_qspi_init() into nrfx_qspi_init_rdp() and added the code to configure DIO1 with pulldown, init the QSPI peripheral, then within that same function call nrfx_qspi_cinstr_xfer() with the 0xAB CMD_RELEASE_PWRDOWN command, finally redefining DIO1 as the other QSPI pins.

Basically QSPI init for EEPROM devices in Deep Power Down Mode that require 0xAB to exit. I confirmed that when the peripheral sends the first 0x05 with the EEPROM in DPM, the status register reads 0x00 (no data), and as soon as the 0xAB is sent, the EEPROM status reads 0x40. And the QSPI doesn't timeout, even if there's nothing on DIO1. Here's the trace of the nrfx_qspi_init_rdp() call followed by nrfx_qspi_mem_busy_check() (which reads 0x40 as expected)

I'm posting the modified files for reference. Other people might find this ticket when dealing with modern NOR flash chips. Can't promise it will work in all case, it's not fully tested yet

devzone.nordicsemi.com/.../nrf_5F00_drv_5F00_qspi.h devzone.nordicsemi.com/.../nrfx_5F00_qspi.c devzone.nordicsemi.com/.../nrfx_5F00_qspi.h

RE: Cannot exit deep power down mode (QSPI flash)

robca — Fri, 28 Jun 2024 22:20:23 GMT

Problem is: I need to save power, so I need to deinitialize the QSPI peripheral when in low power. Also, it will be disabled anyway when the device goes into sd_power_system_off(), and I need to initialize the QSPI to start sending commands.

I already tried disabling qspi_ready_wait() in nrfx_qspi_init() (or ignoring the error timeout), but the QSPI peripheral remains in error mode, and doesn't send anything else. Is there a way to clear a pending error?

The most concerning thing for me now is that I noticed an inconsistency between the board with the dead bug soldering and another board. So I used a PCBite setup on the 4 SPI pins of the QSPI interface, for the non-working board (I only have 4 PCBite probes). Then that board started working, too (DPM and RDP). In the end, I verified that if I have a logic analyzer probe on DIO1, the QSPI peripheral never times out (even when sending 0x05 to a sleeping EEPROM and not receiving 0x40 as a response. Just DIO1, all other pins make no difference.

I think we used the recommended QSPI pins, minus P0.18 which in the past gave us problems with PINRESET. And those same pins work just fine for everything else, only recover from DPM is a problem.

#define BSP_QSPI_CSN_PIN P0_16
#define BSP_QSPI_SCK_PIN P0_19
#define BSP_QSPI_IO0_PIN P0_21
#define BSP_QSPI_IO1_PIN P0_22
#define BSP_QSPI_IO2_PIN P0_23
#define BSP_QSPI_IO3_PIN P1_00

My logic analyzer (a DSlogic Plus) has never caused problems before, so I'm a a loss to understand how it could make such a huge difference for QSPI initialization. And I tried with an oscilloscope probe, which also is enough to solve the problem. So there's some hair-trigger logic situation happening (on all boards, also checked)

Of course if we could clear the QSPI error and send 0xAB after the error, it shouldn't matter

EDIT:

And I just found a horrible hack that seems to work. By editing the nrfx_qspi_init() and nrfx_qspi_cinstr_xfer() functions to configure the DIO1 pin as input pulldown (instead of input nopull), the init function returns success, and so does sending 0xAB. Basically, forcing DIO1 low seems to prevent the QSPI peripheral from noticing that the QSPI chip is not responding, until it sends 0xAB and the chip responds again.

I created a clone of init and xfer, where I define the DIO1 pin as input pulldown on entry and redefine as input no pull on exit. The rest of the library is unchanged. I mean, I guess it could work, but I really don't like this 🙂. It's "too clever by half" and those things tend to come back and bite.

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Fri, 28 Jun 2024 10:12:04 GMT

I see the same 0x05 as you see:

Out of curiousity, does it work if you don't uninit the QSPI? But send the 0xAB like you did with the CMD_DEEP_PWRDOWN packet? I don't know the consequences of this yet, but it is worth a shot just to check that everything else is working as intended.

edit: Or since we are already at this stage, what happens if you comment out the qspi_ready_wait() in nrfx_qspi_init(), and then send the 0xAB packet?

Best regards,

Edvin

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Thu, 27 Jun 2024 14:00:19 GMT

wow! This is great!

[quote user="robca"]To be honest, dead-bug soldering eight 35AWG wires directly the bottom of the WSON-8 version of MX25U51245G is not too bad,[/quote]

I agree that it is doable, but I don't have the chip-only either, so to test properly, I need some HW either way. And the breakout board is easier to re-purpose for different tests that may pop up later. I am sorry, but there is a lot to do, because many of our staff has started their summer holidays. I have modified my DK to be able to analyze the QSPI pins, but I have not yet been able to capture the trace. I will set it up, and see if I get time tonight.

I will get back to you with more updates.

Best regards,

Edvin

RE: Cannot exit deep power down mode (QSPI flash)

robca — Wed, 26 Jun 2024 23:51:58 GMT

Once again, I appreciate everything you are doing. And, funny you should ask, but I came to the exact same conclusion: we were flying blind and it was unfair for me to ask you to help without a logic analyzer trace. So I bit the bullet, desoldered the chip and create a horrible rat's nest of bodge wire.

My logic analyzer channels are: 0 - clock, 1 - DIO0, 2 - DIO1, 3 - DIO2, 4 - DIO3, 5 - CS

Here's what happens when nrf_drv_qspi_init() runs. The QSPI peripheral actually sends 0x05 (Read Status Register), the EEPROM replies

Then we have configure_memory. As you can see, every instruction is preceded by sending once more 0x05. It looks as if every instruction starts with 0x05 again, but I'm not sure I understand the 0x06 (Write Enable) before 0x66 (Reset Enable), 0x99 (Reset) and the change to the configuration register 0x01 0x40

Using your code, the instructions in line 5-12 look like this, i.e. sends yet another 0x05, followed by 0xB9 (deep power down)

Incidentally, absolutely the same as this code

    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};

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

as you can see here

Good, so now we are in deep sleep.

Then we get to lines 16-21 in your code snippet, which is supposed to wake up the EEPROM. As you can see, it simply tries to toggle CS as per the "old" EEPROM convention to exit DPM using only CS (I needed to use 2 screengrabs due to the different zoom levels, look at the timing on top to make sense of them)

The device is not out of DPM, though.

I'm seeing inconsistent results between the device I bodge-wired and another, and I need to do a bit more soldering, but wanted to start capturing some traces and share them.

Also, if I read the spec sheet correctly, this device should work like mine, and exit DPM only when receiving 0xAB. But I haven't tested it https://www.adafruit.com/product/5634

To be honest, dead-bug soldering eight 35AWG wires directly the bottom of the WSON-8 version of MX25U51245G is not too bad, so I'm not entirely sure you need a breakout board for the tests

EDIT: please let me know what traces you need. I'm seeing a slightly different behavior between the board with a dead bug soldered device and the unmodified one. I'm tired now, though, and I'm not sure if I'm doing something else wrong.

But if there were a way to send 0xAB instead of 0x05 during the qspi init call ,that would solve all problems. Otherwise it looks as if the init returns timeout because there's no reply from the EEPROM

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Wed, 26 Jun 2024 21:58:00 GMT

Hello,

[quote user="robca"]NRF_QSPI->IFCONFIG so I used NRF_QSPI->IFCONFIG1 instead, I'm sure it's just a typo)[/quote]

Indeed.

[quote user="robca"]Is there a way to send 0xAB as a custom QSPI instruction instead of using nrf_drv_qspi_cinstr_xfer()?[/quote]

It is not very clear to me. I did see that it is part of the instruction set, but I am not yet sure how this is used.

Do you have the possiblilty to analyze the QSPI pins using a logic analyzer to see whats actually happens when we try to reinitialize the QSPI and bring the chip back to life?

I was planning on doing so, but I don't have the QSPI flash chip that you are using. Also, it requires some modifications to the DK (which I can do), but if you have the possibility, it would perhaps give a better picture of what's going on, since it seems to work without issues on my side.

Or even better, if we can both do it, we can compare the traces to see what it waits for. If not, I need to check if I can get hold of a breakout board with the QSPI chip that you are using. Are you aware of any breakout boards containing the flash chip that you are using?

Best regards,

Edvin

RE: Cannot exit deep power down mode (QSPI flash)

robca — Tue, 25 Jun 2024 22:22:41 GMT

Thanks again for the code.

I first tried adding WAIT_FOR_PERIPH(); after the DPM instruction as you suggested, and it hangs forever. I believe that, at that point, the chip is already in DPM

So I removed it and added the rest of your code (just a note that line 14 uses NRF_QSPI->IFCONFIG so I used NRF_QSPI->IFCONFIG1 instead, I'm sure it's just a typo)

This is what I get

[00:00:03.219,238] <info> app: after change: IFCONFIG1: F1040401
[00:00:03.219,238] <info> app: after uninit: IFCONFIG1: F1040401
[00:00:03.219,299] <info> app: QSPI closed in DPM.
[00:00:03.726,013] <info> app: after delay: F1040401
[00:00:03.726,013] <info> app: after change: IFCONFIG1: F0040401
[00:00:03.728,820] <info> app: QSPI opened again.

Alas, line 23 call to configure_memory() errs with the same NRF_ERROR_TIMEOUT on the first nrf_drv_qspi_cinstr_xfer(). Since there is no 0xAB sent to the chip, it's still in DPM. Not sure why this time the nrf_drv_qspi_init() call worked (unlike in my case), but the QSPI peripheral doesn't seem to be able to send anything

I tried adding

    nrf_qspi_cinstr_conf_t cinstr_cfg = {
        .opcode    = CMD_RELEASE_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};

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

to actually send 0xAB, but it also errs on the nrf_drv_qspi_cinstr_xfer() (NRF_ERROR_TIMEOUT)

Is there a way to send 0xAB as a custom QSPI instruction instead of using nrf_drv_qspi_cinstr_xfer()?

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Tue, 25 Jun 2024 08:17:18 GMT

I see.

Unfortunately, I am not able to reproduce this with what I have at hand, because the QSPI chip on the DK reacts on the CSN pin only.

Can you please try to replace the rest of the main function, from line 115 in your snippet, with this one, and let me know what the log says?

    err_code = nrfx_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);          // send deep power down instruction
    APP_ERROR_CHECK(err_code);
    WAIT_FOR_PERIPH();                                                  // Check if this one makes a difference first.

    NRF_QSPI->IFCONFIG1 |= 0x01000000;
    nrf_delay_ms(100);
    NRF_LOG_INFO("after change: IFCONFIG1: %08x", NRF_QSPI->IFCONFIG1);

    nrf_drv_qspi_uninit();
    NRF_LOG_INFO("after uninit: IFCONFIG1: %08x", NRF_QSPI->IFCONFIG1);
    NRF_LOG_INFO("QSPI closed in DPM.");
    nrf_delay_ms(500);
    
    NRF_LOG_INFO("after delay: %08x", NRF_QSPI->IFCONFIG);

    NRF_QSPI->IFCONFIG1 &= ~(0x01000000);
    NRF_LOG_INFO("after change: IFCONFIG1: %08x", NRF_QSPI->IFCONFIG1);

    err_code = nrf_drv_qspi_init(&config, qspi_handler, NULL);      // NRF_ERROR_TIMEOUT error here
    APP_ERROR_CHECK(err_code);
    NRF_LOG_INFO("QSPI opened again.");

    configure_memory();

    err_code = nrf_drv_qspi_read(m_buffer_rx, QSPI_TEST_DATA_SIZE, 0);
    WAIT_FOR_PERIPH();
    NRF_LOG_INFO("Data read 2");

    for (;;)
    {
    }
}

You can try only adding line 3 first, and then try to write to the IFCONFIG1 register. According to the documentation, this should be written to to enable DPM. Let me know whether it changes anything.

Best regards,

Edvin

RE: Cannot exit deep power down mode (QSPI flash)

robca — Mon, 24 Jun 2024 17:40:55 GMT

Thanks for looking into my issue.

I'm using this code, a small variation of the code linked in the original question

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "nrf_drv_qspi.h"
#include "nrf_delay.h"
#include "app_util_platform.h"
#include "app_error.h"
#include "boards.h"

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"
#include "sdk_config.h"

#define QSPI_STD_CMD_WRSR   0x01
#define QSPI_STD_CMD_RSTEN  0x66
#define QSPI_STD_CMD_RST    0x99
#define CMD_DEEP_PWRDOWN    0xB9

#define QSPI_TEST_DATA_SIZE 256

#define WAIT_FOR_PERIPH() do { \
        while (!m_finished) {} \
        m_finished = false;    \
    } while (0)

static volatile bool m_finished = false;
static uint8_t m_buffer_tx[QSPI_TEST_DATA_SIZE];
static uint8_t m_buffer_rx[QSPI_TEST_DATA_SIZE];

static void qspi_handler(nrf_drv_qspi_evt_t event, void * p_context)
{
    UNUSED_PARAMETER(event);
    UNUSED_PARAMETER(p_context);
    m_finished = true;
}

static void configure_memory()
{
    uint8_t temporary = 0x40;
    uint32_t err_code;
    nrf_qspi_cinstr_conf_t cinstr_cfg = {
        .opcode    = QSPI_STD_CMD_RSTEN,
        .length    = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true,
        .io3_level = true,
        .wipwait   = true,
        .wren      = true
    };

    // Send reset enable
    err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    // Send reset command
    cinstr_cfg.opcode = QSPI_STD_CMD_RST;
    err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    // Switch to qspi mode
    cinstr_cfg.opcode = QSPI_STD_CMD_WRSR;
    cinstr_cfg.length = NRF_QSPI_CINSTR_LEN_2B;
    err_code = nrf_drv_qspi_cinstr_xfer(&cinstr_cfg, &temporary, NULL);
    APP_ERROR_CHECK(err_code);
}


int main(void)
{
    uint32_t i;
    uint32_t err_code;

    err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_DEFAULT_BACKENDS_INIT();

    NRF_LOG_INFO(""
                 "QSPI write and read example using 24bit addressing mode");

    srand(0);
    for (i = 0; i < QSPI_TEST_DATA_SIZE; ++i)
    {
        m_buffer_tx[i] = (uint8_t)rand();
    }

    nrf_drv_qspi_config_t config = NRF_DRV_QSPI_DEFAULT_CONFIG;

    config.phy_if.dpmen = false;
    config.prot_if.dpmconfig = true;
    NRF_QSPI->DPMDUR = (0x3 << 16) | 0x3;
    
    err_code = nrf_drv_qspi_init(&config, qspi_handler, NULL);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_INFO("QSPI example started.");

    configure_memory();

    m_finished = false;

    err_code = nrf_drv_qspi_read(m_buffer_rx, QSPI_TEST_DATA_SIZE, 0);
    WAIT_FOR_PERIPH();
    NRF_LOG_INFO("Data read");

    uint32_t nConfigOld = NRF_QSPI->IFCONFIG1;

    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};

    err_code = nrfx_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);          // send deep power down instruction
    APP_ERROR_CHECK(err_code);

    nrf_drv_qspi_uninit();
    NRF_LOG_INFO("QSPI closed in DPM.");
    nrf_delay_ms(500);

    NRF_QSPI->IFCONFIG1 = nConfigOld;

    err_code = nrf_drv_qspi_init(&config, qspi_handler, NULL);      // NRF_ERROR_TIMEOUT error here
    APP_ERROR_CHECK(err_code);
    NRF_LOG_INFO("QSPI opened again.");

    configure_memory();

    err_code = nrf_drv_qspi_read(m_buffer_rx, QSPI_TEST_DATA_SIZE, 0);
    WAIT_FOR_PERIPH();
    NRF_LOG_INFO("Data read 2");

    for (;;)
    {
    }
}

This code works for any SPI NOR flash chip that can be released from deep power down using the CS line. For most NOR flash chips, the datasheet says “After CS# goes high, there is a delay of tRDP before the device transitions from Deep Power-down mode back to Stand-by mode.”

In the newer 512 Mbit chips (all of them, not just mine), the device doesn't exit deep power down only using the CS line, it explicitly requires a 0xAB instruction to release. Problem is, the QSPI peripheral won't let me send anything, can't even complete the init function.

I haven't connected a logic analyzer yet, because it would require removing the chip and soldering wires. But from everything I have seen, when initializing the QSPI peripheral, it sends 0x05 to the chip to verify that a chip is connected. In my case, the chip ignores the 0x05 because the only instruction it recognizes is 0xAB. So QSPI times out (I changed QSPI_DEF_WAIT_TIME_US but it makes no difference, given it's not a real timeout issue)

I need a way to either change the QSPI peripheral initialization to send 0xAB instead of 0x05, or a way to "trick" the QSPI peripheral to initialize even if the flash chip doesn't reply, so that I can send 0xAB either as a custom instruction or a nrfx_qspi_cinstr_xfer()

Let me try to convey why this is more than just a minor issue for a specific case: all new 256/512Mbit chips cannot exit deep power down only by using CS, as far as I can tell. They all need the 0xAB instruction (it's done to improve security and avoid exiting low power by mistake). As such, none of those chips can be properly used by the nRF52840 QSPI when extreme low power is needed.

RE: Cannot exit deep power down mode (QSPI flash)

Edvin — Mon, 24 Jun 2024 14:01:45 GMT

Hello,

I don't have the same flash chip that you are using, but have you tried to use a logic analyzer and capture a logic trace of when the NRF_QSPI_TASKS_ACTIVATE is called? Does it generate any data on the QSPI pins? Have you tried to increase the QSPI_DEF_WAIT_TIME_US from 10 to a higher number? Just for debugging purposes.

Also, is it possible to upload the application that you are using to reproduce this issue?

Best regards,

Edvin