Trouble initializing QSPI when the chip is actually busy

[J.Hollander]

Hi,

I noticed that when I initiate a chip-erase on the flash-chip and reset the MCU, I'm getting NRFX_ERROR_TIMEOUT's on my nrfx_qspi_init().

I found this ticket: https://devzone.nordicsemi.com/f/nordic-q-a/28947/what-does-qspi-activate-task-do

Which confirms that the QSPI periph tries to request the status register before doing anything, could it be that it blocks any further communication until the chip reports itself as ready? I tried to transmit the 0x66 / 0x99, RESET_ENABLE / RESET_MEMORY opcodes (after the failed init) to make it reset manually:

    nrfx_err_t rc = NRFX_SUCCESS;
    nrf_qspi_cinstr_conf_t enable_reset_cfg = {
        .opcode = 0x66,
        .length = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true,
        .io3_level = true,
        .wipwait = false,
        .wren = false
    };
    rc = nrfx_qspi_cinstr_xfer(&enable_reset_cfg, NULL, NULL);

    if(rc == NRFX_SUCCESS)
    {
        nrf_delay_us(QSPI_RESET_ENABLE_DELAY_US);
    }

    if(rc == NRFX_SUCCESS)
    {
        nrf_qspi_cinstr_conf_t memory_reset_cfg = {
            .opcode = 0x99,
            .length = NRF_QSPI_CINSTR_LEN_1B,
            .io2_level = true,
            .io3_level = true,
            .wipwait = false,
            .wren = false
        };
        rc = nrfx_qspi_cinstr_xfer(&memory_reset_cfg, NULL, NULL);
    }

    if(rc == NRFX_SUCCESS)
    {
        nrf_delay_us(QSPI_RESET_MEMORY_DELAY_US);
    }

But I am getting timeouts on these calls as well...

I their a sensible way to recover the unit without waiting for a full chip-erase. I'm a bit worried that a crash / reset / whatever mid erase may cause my unit to decide that the flash is broken on boot. (I'm supposed to do a self-check on boot, and die if that fails)

I'm using the 7.0.2 SDK with the S140 7.2.0 SD

[Kenneth]

I can find in nrfx_qspi_init() that it will wait for the peripheral to activate yes. This delay is configurable (through QSPI_DEF_WAIT_ATTEMPTS and QSPI_DEF_WAIT_TIME_US):

static nrfx_err_t qspi_ready_wait(void)
{
    bool result;
    NRFX_WAIT_FOR(nrf_qspi_event_check(NRF_QSPI, NRF_QSPI_EVENT_READY),
                                       QSPI_DEF_WAIT_ATTEMPTS,
                                       QSPI_DEF_WAIT_TIME_US,
                                       result);
    if (!result)
    {
        return NRFX_ERROR_TIMEOUT;
    }

    return NRFX_SUCCESS;
}

I their a sensible way to recover the unit without waiting for a full chip-erase.

I suggest to check with the vendor on what they recommend in terms of wait time and recovery. 

[J.Hollander]

A full chip-erase takes over a minute, the problem is not that there is no communication. the NRF simply refuses to send out the reset command, because the chip is busy...

[Kenneth]

You can consider adding another api to nrfx_qspi to force clear the busy bit?

void qspi_force_clear_busy(void)
{
    m_cb.is_busy = false;
}

[J.Hollander]

That flag is only set when calling qspi_task_perform(), which is not called by nrfx_qspi_init(), nor by nrfx_qspi_cinstr_xfer()

[Kenneth]

I am not aware of any issue, so I guess you will simply have to wait until the chip is ready in this case. I just wanted to make sure that it's the hardware that is waiting and not the state machine of the driver that was busy in this case.