From 397376ebcb7cdf0e98f8bf76f142829e2b6f9e20 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andrzej=20G=C5=82=C4=85bek?= Date: Wed, 23 Apr 2025 11:40:47 +0200 Subject: [PATCH] [nrf fromtree] drivers: flash: nrf_qspi_nor: Prevent CPU hang when XIP is re-enabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add a simple non-XIP transaction before deactivating the QSPI after a XIP transaction is performed. This prevents a CPU hang from occuring when another XIP transaction is attempted after the QSPI is activated again. Signed-off-by: Andrzej Głąbek (cherry picked from commit fb1d0785ae3bcc60282c94d31e253ae7f1b4360e) --- drivers/flash/nrf_qspi_nor.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/flash/nrf_qspi_nor.c b/drivers/flash/nrf_qspi_nor.c index f60ca2d2c0e..12eeb3f4a3e 100644 --- a/drivers/flash/nrf_qspi_nor.c +++ b/drivers/flash/nrf_qspi_nor.c @@ -1359,6 +1359,18 @@ void z_impl_nrf_qspi_nor_xip_enable(const struct device *dev, bool enable) #endif if (enable) { (void)nrfx_qspi_activate(false); + } else { + /* It turns out that when the QSPI peripheral is deactivated + * after a XIP transaction, it cannot be later successfully + * reactivated and an attempt to perform another XIP transaction + * results in the CPU being hung; even a debug session cannot be + * started then and the SoC has to be recovered. + * As a workaround, at least until the cause of such behavior + * is fully clarified, perform a simple non-XIP transaction + * (a read of the status register) before deactivating the QSPI. + * This prevents the issue from occurring. + */ + (void)qspi_rdsr(dev, 1); } dev_data->xip_enabled = enable;