This has been discussed in two other threads, one brought up by someone else and another by myself when I thought I found a solution but it ended up being a fake solution.
https://community.st.com/s/question/0D50X00009XkgwcSAB/stm32f7-quadspi-and-the-data-cache-odd-behaviour
https://community.st.com/s/question/0D70X0000068Xn8/do-interrupt-priorities-have-to-start-at-zero
I can now reproduce this on a discover board with no private IP in the project, so I'll post the project publicly. It is a heavily stripped down project that has the USB driver, our company's public communications API, and a few random functions here and there that shouldn't matter but somehow do. At this point, if I remove just about anything else, even functions that never get called or interrupt handlers for interrupts that aren't even enabled, the problem goes away. Changing to anything below -O3 also makes the problem go away, but I need root cause before I can move on from this bug.
Here is the Keil uVision project: https://www.dropbox.com/s/1mv29boljscgnms/QSPI_Bug.zip?dl=0
This can be run directly on an STM32F746G-DISCO board. You do have to remove R64 jumper and move it to R63 to activate VBUS sense on the USB FS line.
To reproduce the problem:
- Move R64 to R63 on the discover board.
- Load the program with the Keil debugger running. Monitor the QUADSPI->AR register in a watch window or the peripheral viewer. Notice that it is not 0 (it's changed at the beginning of main()).
- Connect a USB micro cable to your computer to the USB FS port.
- Wait two seconds, and then unplug that cable.
- Plug the cable back in.
- Observe that QUADSPI->AR just changed to 0.
What changed it? I just cannot figure it out. If you set a memory write watch on the QUADSPI->AR register (0xA0001018) it never trips despite watching the register change.
I'll open a support ticket with ST to get this looked at, but figured I'd make the post public so that everyone can see the results and maybe a community member will be able to contribute to figuring this one out!
