QSPI EVENT_READY

[Remy]

Hello, 

I'm using the flash MX25L1283 together with the NRF52840. I've implemented a new driver for that flash using the nrfx library. Everything works fine ! 

However, I can't understand what's the EVENT_READY. When nrfx_qspi_init() is called, it seems that the external flash will be accessed to read the "Write in progess" bit ? This is done in a loop until that bit is cleared, right ? I can see a lot of 0x05 command (read status register) executed there. 

When exactly that read status register is done ?  When we send a custom command with "WIP_WAIT" flag setted, we will read that status register before sending the command, right? Is the status register read after that or not at all ? I can see that you are also waiting for the EVENT_READY there. 

Thanks in advance for your reply

Best regards

Rémy

[Simonr]

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

[Remy]

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

[Simonr]

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