Trouble initializing QSPI when the chip is actually busy

RE: Trouble initializing QSPI when the chip is actually busy

Kenneth — Tue, 05 Jan 2021 08:30:36 GMT

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.

RE: Trouble initializing QSPI when the chip is actually busy

J.Hollander — Mon, 04 Jan 2021 15:37:40 GMT

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

RE: Trouble initializing QSPI when the chip is actually busy

Kenneth — Tue, 24 Nov 2020 12:48:46 GMT

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

RE: Trouble initializing QSPI when the chip is actually busy

J.Hollander — Fri, 20 Nov 2020 11:09:09 GMT

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...

RE: Trouble initializing QSPI when the chip is actually busy

Kenneth — Tue, 17 Nov 2020 15:15:20 GMT

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

[quote user=""]I their a sensible way to recover the unit without waiting for a full chip-erase. [/quote]

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