NCS 2.0.0 hang in qspi_device_uninit

[denis]

I have an application that is working in NCS 1.8.0.  When I build with NCS 2.0.0 and run then there is a hang in qspi_device_uninit (called by fd_mount, ..., qspi_nor_read).  nrfx_qspi_mem_busy_check is getting 0xff for the status_value, which sounds incorrect.  Any ideas to help track this issue down?

Also, the "CORTEX PERIPHERALS" view in vscode says "SVD: No active debug sessions or no SVD files specified".  So I can't look at the QSPI peripheral registers.  Any ideas why that would be?

[Simonr]

Hi again

So I asked our developers about this, and this was indeed an issue recently in upstream Zephyr as well, and we've fixed it here. https://github.com/zephyrproject-rtos/zephyr/pull/46514 

This line in the shim driver (and that handling of the anomaly 122 is something that was not present in NCS v1.5.1, hence the difference in behavior). In consequence, the shim driver does not wait until the erase operation completes and deinitializes the nrfx driver right away. When it then tries to reinitialize it before the next QSPI operation, the timeout in qspi_ready_wait occurs (because the erase operation needs to be completed first). And that's why the increasing of the timeout value helps. But instead of this, nrfx_qspi driver needs to be corrected so that nrfx_qspi_mem_busy_check sends the Read Status Register command with the IO3 line held high.

Best regards,

Simon