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

[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