Skip to main content
Gpeti
Senior
September 13, 2022
Solved

STM32H7 QSPI kernel frequency too slow leads to read errors ?

  • September 13, 2022
  • 2 replies
  • 2094 views

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 ?

This topic has been closed for replies.
Best answer by Gpeti

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

2 replies

Gpeti
GpetiAuthorBest answer
Senior
September 14, 2022

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

Amel NASRI
ST Technical Moderator
September 14, 2022

Hi @Gpeti​ ,

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

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
Gpeti
GpetiAuthor
Senior
September 14, 2022

yes it is, thanks for adding the link

Tesla DeLorean
Guru
September 14, 2022

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
Gpeti
GpetiAuthor
Senior
September 14, 2022

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