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

There were some pretty big changes between versions 1.x.x and 2.x.x of the nRF Connect SDK. Have you gone through the migration and release note for the NCS v2.0.0? I'm not familiar with this issue in particular, but if you haven't done that, I'm guessing it can be resolved by following the migration notes closely for your application.

Best regards,

Simon

[denis]

Yes, I did review the release and migration notes.  I didn't notice anything related to QSPI.

[Simonr]

Hi

The qspi_device_uninit() is new to NCS v2.0.0. Have you added the Multithreading configCONFIG_MULTITHREADING=y in your project? This should ensure that qspi_device_init is only called and uninitialized at the last call so you don't get multipli qspi_device_uninit calls.

See nrf_qspi_nor.c l.362 for details.

Best regards,

Simon

[denis]

CONFIG_MULTITHREADING=y is the default, so yes, and I am using threads.

[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