QSPI EVENT_READY

RE: QSPI EVENT_READY

Simonr — Wed, 21 Sep 2022 12:03:10 GMT

Hi Jiri

I'm not sure what you do in your project code, or for how long this "loop" is running in your case. Either way, you shouldn't skip the qspi_ready_wait(). As this ticket is close to half a year old. can you create your own support ticket where you explain what nRF device you're using, what external flash device this happens in, and what your application code does exactly.

Best regards,

Simon

RE: QSPI EVENT_READY

Jiri Husak — Wed, 21 Sep 2022 06:50:34 GMT

Dear Support,

I'm facing similar issue. I guess it's more a lack of documentation. COuld you please confirm that the QSPI peripheral HW is responsible for this 0x05 command loop? I see this to happen at the exact moment I start the QSPI with the ACTIVATE task.

In the SDK there are calls to qspi_ready_wait() inside the nrfx_qspi_init(), however those calls are not polling the lines, only the status bit. The memory seems to be is polled by the HW even if I completely skip the qspi_ready_wait() call.

Could you please confirm such behavior?

In our case this is not really fortunate as we normally disable the MCU during Flash Erase (could be long) and then reinitilize the QSPI after typical flash erase time. Of course it may happen that the flash is not ready on that time, so we see long time of such super loop and in parallel the NRF driver asserts on the timeouts (which are hardcoded in the driver).

Other thing is that if we want to poll the memory on our own, the nrfx_qspi_cinstr_xfer() function is asseting on NRFX_ASSERT(p_config->wipwait); even if we configure the wipwait inside nrf_qspi_cinstr_conf_t as false (due to timeouted init funciton).

Do you see a solution for our use case?

Many thanks in advance for any hint.

Jiri

RE: QSPI EVENT_READY

Simonr — Thu, 12 May 2022 05:58:30 GMT

Hi Rémy

I would recommend making sure the QSPI device is "awake" before initializing it, then putting it back to sleep by setting it in standby mode from the nRF is you want it in that mode. In the nrfx_qspi driver this is indeed how the QSPI peripherals are initialized and activated, but you're free to modify the driver if you want to I.E. run a "Release deep power mode" instruction as part of the init() function to make sure the device wakes up.

Best regards,

Simon

RE: QSPI EVENT_READY

Remy — Wed, 11 May 2022 07:09:25 GMT

Hi Simon,

Thanks for your reply.

I'm currently using SDK 15.0.0 and we plan to upgrade to the SDK15.3.0 soon.

When the flash I'm using is in deep standby mode, all instructions are ignored expect "RDP" (Release deep power mode). It means that the read status register command will be ignored. So, if the flash is in deep standby mode, the nrfx_qspi_init() command will always return a timeout error.

Is there any way to change that activation process behavior or not ?

This is the piece of code to wake-up the flash :

static int wake()
{
    const nrf_qspi_cinstr_conf_t cinstr_cfg = {
        .opcode = 0xAB,
        .length = NRF_QSPI_CINSTR_LEN_1B,
        .io2_level = true,
        .io3_level = true,
        .wipwait = true,
        .wren = false};

    // Wake
    ret_code_t err_code = nrfx_qspi_cinstr_xfer(&cinstr_cfg, NULL, NULL);
    APP_ERROR_CHECK(err_code);

    return 0;
}

If I set "wipwait" to true, the flash will ignore the read status register command and return a timeout error.

I was afraid that once the command is sent, we have the same poll and wait mechanism that during initialization, but it's not the case right ? Otherwise, I'm not able to wake-up the flash, since after sending the wake-up command, I can't touch the CS line during 30us.

I think main question here, is concerning that poll and wait mechanism ,is that set in stone that the command 0x05 is used ? No configuration possible ?

Best regards

Rémy

RE: QSPI EVENT_READY

Simonr — Wed, 11 May 2022 06:12:49 GMT

Hi Rémy

What SDK and SDK version are you using for development? The nrfx_qspi_init() functionn configures the peripheral and its interrupts to activate it. During the activation process, the internal clocks are started and the QSPI peripheral tries to read the status byte to read the busy bit. This is done in a simple poll and wait mechanism.

Can you show me the custom WIP_WAIT function so I can take a look at what you're doing exactly?

Best regards,

Simon