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

[Jiri Husak]

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

[Simonr]

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