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?
