STM32H7 QSPI kernel frequency too slow leads to read errors ?

[Gpeti]

I am developping a driver for a QSPI memory mapped memory on STM32H753.

In SPI mode it works fine.

When I switch to "quad io" mode (ie. 4 data signals) I read corrupted data. Adding some delays between reads improve the results (but doesn't completely solve the issue)

Right now the CPU frequency is 400Mhz, HCLK is 200MHz and the QSPI kernel clock (SCK signal) is 12.5MHz.

Is it possible that the QSPI freq is too slow compared the CPU freq ? I assume a slow SPI freq is just stalling the CPU for a longer time ?

[Gpeti · Accepted solution]

Apparently it is not a frequency issue. I will post another more detailed question

[Amel NASRI]

Hi @Gpeti​ ,

I assume that detailed question is Problems accessing QSI Flash with consecutive reads.

-Amel

[Gpeti]

yes it is, thanks for adding the link

[Tesla DeLorean]

There is a time-out associated with memory-mapped mode.

I don't know how it decomposes reads, or burst/prefetch lengths. Perhaps look at NCS on a scope.

At 4-bit the bandwidth it up at 50 mbps

What's the full part number of the memory? Infineon / Cypress has 3 or 4 generations of parts out in the wild.

https://community.st.com/s/question/0D53W00001nlpeTSAQ/problems-accessing-qsi-flash-with-consecutive-reads

[Gpeti]

From the STM32H7 user manual there is no timeout by default:

By default, the QUADSPI never stops its prefetch operation, keeping the previous read

operation active with nCS maintained low, even if no access to the Flash memory occurs for a long time. Since Flash memories tend to consume more when nCS is held low, the

application might want to activate the timeout counter (TCEN = 1, bit 3 of QUADSPI_CR) so that nCS is released after a period of TIMEOUT[15:0] (QUADSPI_LPTR) cycles have

elapsed without any access since when the FIFO becomes full with prefetch data.

From my understanding setting the timeout would not change anything as long as the CPU needs to access the memory

From what I see on the scope, when I do a 4KB memcpy, the STM32 sends a single read command. nCS remains active (ie. low) as expected.

The part is S25FL064L.

thank you