Skip to main content
JGuy1
Associate II
March 30, 2026
Question

STM32F769NI QUADSPI - Extra data written in the FIFO at the end of a read transfer

  • March 30, 2026
  • 2 replies
  • 218 views

Greetings!

 

There's an errata for the STM32F6/STM32F5 chips that goes like this:

 

2.4.1 Extra data written in the FIFO at the end of a read transfer
Description
When all the conditions listed below are gathered:
• QUADSPI is used in indirect mode.
• QUADSPI clock is AHB/2 (PRESCALER = 0x01 in the QUADSPI_CR).
• QUADSPI is in quad mode (DMODE = 0b11 in the QUADSPI_CCR).
• QUADSPI is in DDR mode (DDRM = 0b1 in the QUADSPI_CCR).
• A data is read in the instant when the FIFO buffer gets full at the end of a read transfer, an extra data is unduly written in the FIFO buffer.
Workarounds
Apply one of the following measures:
• Read out the extra data until the BUSY flag goes low, then discard the extra data.
• After reading out all the expected received data, set the ABORT bit of the QUADSPI_CR register to flush FIFO and keep the BUSY flag low. The last register configuration is kept.

 

I believe this is also present on the STM32F769NI chip. I have done extensive research on this.

 

It was first noticed for the STM32F749 in 2019: https://github.com/ARMmbed/mbed-os/issues/10049

Then temporarily fixed by mbed: https://github.com/ARMmbed/mbed-os/commit/5c872a4c0669f9d2ef70a9401bbaa469b9881f57

This was then fixed in the BSP: https://github.com/STMicroelectronics/STM32CubeF7/issues/6

 

In 2021 I noticed the fix solves a problem on my F769: https://github.com/ARMmbed/mbed-os/issues/15108

I opened an issue in the BSP but it was closed incorrectly: https://github.com/STMicroelectronics/STM32CubeF7/issues/52

In 2023 I re-opened the issue and provided a lot of debugging information showing this is likely an errata: https://github.com/STMicroelectronics/STM32CubeF7/issues/82

Today it was closed, so here I am.

 

I don't know what machinery this needs to go through to get fixed, but please release a fix for this. I suspect it's just adding a #define to one of the files like with the other chips. I understand it's harder than that as you have to spend time verifying an errata. But maybe something could be done as a temporary solution?

2 replies

Technical Moderator
March 31, 2026

Hello @JGuy1 


@JGuy1 wrote:

Greetings!

 

There's an errata for the STM32F6/STM32F5 chips that goes like this:


What do you mean by STM32F6/STM32F5 chips?  There is no STM32F6/STM32F5 MCU.

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
JGuy1
JGuy1Author
Associate II
March 31, 2026

Hello there, sorry for the typo- I mean STM32F74x and STM32F75x. Specifically ES0290 https://www.st.com/resource/en/errata_sheet/es0290-stm32f74xxx-and-stm32f75xxx-device-limitations-stmicroelectronics.pdf page 11 'Extra data written in the FIFO at the end of a read transfer'

Technical Moderator
March 31, 2026

Hello @JGuy1 

To apply the workaround, you can activate the QSPI1_V1_0 flag in your environment.

"To give better visibility on the answered topics, please click on ""Accept as Solution"" on the reply which solved your issue or answered your question.Saket_Om"
JGuy1
JGuy1Author
Associate II
March 31, 2026

Yes, this is one solution I found. Could this be added for the F76x to the BSP so others don't have to experience this issue?