stm32h747 dual quad-flash reading failure

[FRASTM]

Describe the bug

stm32h747i_disco // m7 reading the dual quad flash is not correct
west build p -b stm32h747i_disco//m7 samples/drivers/spi_flash

Regression

• This is a regression.

Steps to reproduce

release: Zephyr 4.2.0-rc3

Relevant log output

spi-nor-flash-1@0 SPI flash testing
==========================

Perform test on single sector
Test 1: Flash erase
Flash erase failed at offset 0xff000 got 0x88888888

Perform test on multiple consecutive sectors
Test 1: Flash erase
Flash erase failed at offset 0xff000 got 0x88888888

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

Expected output (whater the CONFIG_STM32_MEMMAP is)

qspi-nor-flash-1@0 SPI flash testing
==========================

Perform test on single sector
Test 1: Flash erase
Flash erase succeeded!

Test 2: Flash write
Attempting to write 4 bytes
Data read matches data written. Good!!

Perform test on multiple consecutive sectors
Test 1: Flash erase
Flash erase succeeded!

Test 2: Flash write
Attempting to write 4 bytes at offset 0xff000
Data read matches data written. Good!!
Attempting to write 4 bytes at offset 0x100000
Data read matches data written. Good!!

[FRASTM]

With the PR #92737,

• when the CONFIG_STM32_MEMMAP=n, the QSPI_DUALFLASH_DISABLE could be set after the flash_stm32_qspi_send_reset() and not re-enable during the qspi_read_sfdp()
  Because the qspi_read_sfdp() is called several times in a loop, disabling/enabling the QUADSPI_CR_DFM bit could be placed inside just before BFP process (instead of inside the qspi_read_sfdp function).

• When the CONFIG_STM32_MEMMAP=y, reading is not correct neither

A change like the following could make the test PASSED :

diff --git a/drivers/flash/flash_stm32_qspi.c b/drivers/flash/flash_stm32_qspi.c
index c955fc9e86c..411c3a92c3d 100644
--- a/drivers/flash/flash_stm32_qspi.c
+++ b/drivers/flash/flash_stm32_qspi.c
@@ -395,19 +395,6 @@ static int qspi_read_sfdp(const struct device *dev, off_t addr, void *data,
 
 	LOG_INF("Reading SFDP");
 
-#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) && defined(QUADSPI_CR_DFM)
-	/*
-	 * In dual flash mode, reading the SFDP table would cause the parameters from both flash
-	 * memories to be read (first byte read would be the first SFDP byte from the first flash,
-	 * second byte read would be the first SFDP byte from the second flash, ...). Both flash
-	 * memories are expected to be identical so to have identical SFDP. Therefore, the dual
-	 * flash mode is disabled during the reading to obtain the SFDP from a single flash memory
-	 * only.
-	 */
-	MODIFY_REG(dev_data->hqspi.Instance->CR, QUADSPI_CR_DFM, QSPI_DUALFLASH_DISABLE);
-	LOG_DBG("Dual flash mode disabled while reading SFDP");
-#endif /* dual_flash */
-
 	QSPI_CommandTypeDef cmd = {
 		.Instruction = JESD216_CMD_READ_SFDP,
 		.Address = addr,
@@ -438,10 +425,6 @@ static int qspi_read_sfdp(const struct device *dev, off_t addr, void *data,
 	dev_data->cmd_status = 0;
 
 end:
-#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) && defined(QUADSPI_CR_DFM)
-	/* Re-enable the dual flash mode */
-	MODIFY_REG(dev_data->hqspi.Instance->CR, QUADSPI_CR_DFM, QSPI_DUALFLASH_ENABLE);
-#endif /* dual_flash */
 
 	return ret;
 }
@@ -1593,6 +1576,19 @@ static int flash_stm32_qspi_init(const struct device *dev)
 	k_busy_wait(DT_INST_PROP(0, reset_cmd_wait));
 #endif
 
+#if DT_PROP(DT_NODELABEL(quadspi), dual_flash) && defined(QUADSPI_CR_DFM)
+	/*
+	 * In dual flash mode, reading the SFDP table would cause the parameters from both flash
+	 * memories to be read (first byte read would be the first SFDP byte from the first flash,
+	 * second byte read would be the first SFDP byte from the second flash, ...). Both flash
+	 * memories are expected to be identical so to have identical SFDP. Therefore, the dual
+	 * flash mode is disabled during the reading to obtain the SFDP from a single flash memory
+	 * only.
+	 */
+	MODIFY_REG(dev_data->hqspi.Instance->CR, QUADSPI_CR_DFM, QSPI_DUALFLASH_DISABLE);
+	LOG_DBG("Dual flash mode disabled while reading SFDP");
+#endif /* dual_flash */
+
 	/* Run NOR init */
 	const uint8_t decl_nph = 2;
 	union {

[danieldegrasse]

@FRASTM can you submit a PR with this fix? We'd like to resolve this for the release

[JarmouniA]

Cc @taltenbach

[taltenbach]

@FRASTM Unless I'm mistaken, with the changes you provided, you're completely disabling the dual-flash mode, so the test does pass but I guess this is because the flash memory is written/read in single-flash mode.

I guess there is an issue regarding the erasure/writing to the flash memory in dual-flash mode after my changes. I will check if I can reproduce and fix that today.

[taltenbach]

I was able to reproduce and I probably found the root cause.

Before #92737, the test was passing with CONFIG_STM32_MEMMAP disabled (which is the default configuration, using the spi_flash sample) but with CONFIG_STM32_MEMMAP enabled, the test was failing with the exact same error. This is because, before that PR, dual-flash mode was not enabled when CONFIG_STM32_MEMMAP was defined, even though dual-flash is set in the devicetree. The PR fixed that, leading to dual-flash mode to be always enabled, as it should, when dual-flash is set. Therefore, the actual issue is that the test is failing in dual-flash mode.

In dual-flash mode, each time a sector is erased, the erase command is sent to both flash chips, leading to two sectors to be erased, one on each chip. Assuming both chips are identical (which is always the case in dual-flash configuration), this implies that:

• The actual erase size, seen by the flash driver, must be twice the erase size of a single chip. So if the datasheet specifies 4-KiB sectors, from the flash driver point of view each sector will be 8 KiB large.
• When erasing, the flash driver has to wait for the operation to complete on both chips.

Neither of those two points are properly handled at the moment by the flash driver and the issue seems to be caused by the latter (adding k_msleep(1000) after each erase "fixes" the issue). I will make a PR very soon to fix the flash driver.