[SOLVED] Re-reading Octo SPI flash in memoryMapped mode after indirect write.

[RReta.1]

My platform is STM32H735G-DK and I am trying to test access to

the MX25LM51245G Octo SPI flash. I am using the BSP_OSPI_NOR API that comes with the STM32CubeH7_SDK (version 1.8.0)

Test steps:

1. At boot, initialize the controller and configure it for memoryMapped mode, then read a few bytes like this:

volatile uint8_t *flashDataPtr = (volatile uint8_t *)(OCTOSPI1_BASE);
    for (uint8_t idx =0; idx < 4; idx++) {
        LOG_INFO("[1] = 0x%X", *flashDataPtr);
        flashDataPtr++;
    }

The code was able to get the expected data (e.g. 0x0, 0xE7, 0x8E, x0).

2. Disable memory mapped mode using BSP_OSPI_NOR_DisableMemoryMappedMode()

3. Erase a 4K block using BSP_OSPI_NOR_Erase_Block()

4. Read the data using BSP_OSPI_NOR_Read() and validate that it is all 0xFF

5. Write test data using BSP_OSPI_NOR_Write()

6. Re read test data using BSP_OSPI_NOR_Read() and validate it matches data from step 5 (which it does)

7. Re-enable memory mapped mode and read the data using the method in step 1.

Issue:

- Expecting data from step 7 and step 6 to match. Instead the data from step7 matches step 1. I suspect there is some sort of cache-ing? I tried adding __DSB() to sync the data cache but it has no effect.

Questions:

Q1. What is the missing step to make the data matches what we expect in memory mapped mode?

Q2. Does all OctoSPI flash need to have memoryMapped mode disabled to be written, or is that a specific limitation to the Macronix MX25LM51245G?

How about a HyperFlash SPI? App note AN5050 seems to indicate

that there are devices out there that can be written in memoryMapped mode.

Q3. If there are flashes out there that can be written in memoryMapped mode, what command/features must it support?

Thanks for everyone's time...

[Tesla DeLorean · Accepted solution]

>>I tried adding __DSB() to sync the data cache but it has no effect.

Yeah, I'm pretty sure that doesn't do anything you think it does.

Try

SCB_InvalidateDCache_by_Addr((uint32_t*)0x90000000, 0x4000000);

[Tesla DeLorean]

Q2. Does all OctoSPI flash need to have memoryMapped mode disabled to be written, or is that a specific limitation to the Macronix MX25LM51245G?

YES

Q3. If there are flashes out there that can be written in memoryMapped mode, what command/features must it support?

NO

The primary problem here is that the controller uses the same configuration parameters for all interactions, for Memory Mapped mode you basically preset the configuration to use the correct read command, with the correct command, address and data settings, dummy clocks etc. When you touch the 0x90000000 memory space it stuffs actual the address into the OSPI/QSPI command template, and initiates an operation on the memory device, the returning data is then fed into the MCU

There really isn't this concept of direct/indirect operating concurrently/independently, and the flash memory device has no concept of contexts, access to the device needs to be managed and serialized.

[RReta.1]

Yep. Adding this before the memory mapped re-read in step 7 works! Thanks.

[RReta.1]

Thanks very much for the explanation. I have other use case questions, but I'll open a separate ticket to not scope creep this one.