stm32f7: Ethernet traffic generating unexpected QSPI transaction

[icsys-omh]

Describe the bug
It seems that a speculative read by the CPU from the QSPI bus makes the next application generated transaction time out, and the QSPI HAL driver afterwards being stuck in the BUSY state.

This is seen in an application running on the NUCLEO-F767ZI board with a connected QSPI flash and receiving data over Ethernet, but I believe it can happen in almost any circumstance when using a QSPI flash on an STM32F7. Zephyr RTOS in use is v3.3.0.

Based on a thread in STs forums, it seems that the root cause is that the CPU may do a speculative read from the QSPI flash. To avoid this, it is suggested to configure the MPU to make the QSPI memory region Strongly ordered. This is also mentioned in ST's QSPI application note:

Doing so seems to avoid these reads, and hence fix the problem, and I'll create a PR shortly with that code change.

I am however unsure if the QSPI HAL driver should also be improved so that it doesn't time out or get stuck in the BUSY state when this extra transaction occurs.

To Reproduce
Steps to reproduce the behavior:

1. Connect a QSPI flash to a NUCLEO-F767ZI board, or likely any other board with an STM32F7.
2. Build and flash an application with FLASH_SHELL and a web server (this could likely be almost any application activity)
3. Start the application
4. Perform a QSPI flash read from the shell, so that the QSPI flash is enabled and registers are non-zero.
5. Perform multiple HTTP requests to the web server.
6. Watch the QSPI status register with code, and the QSPI lines with a logic analyzer.

Expected behavior
The HTTP requests should succeed, and the QSPI status register remain constant (e.g. 0).

Actual behavior
At a certain point, a QSPI read transaction occurs on the QSPI bus, reading the number of bytes that is currently in the DLR register.

Impact
The first application read after this issue will cause a QSPI timeout, and any further reads will fail, since the HAL QSPI module will remain stuck in the BUSY state.

Logs and console output

Environment (please complete the following information):

• OS: Windows 11
• Toolchain: Zephyr SDK 0.15.0
• Commit SHA or Version used: 3.3.0-rc2

Additional context
A watchpoint on the QSPI peripheral address space does not trigger when the error occurs, which supports the theory that the read is somehow generated internally in the chip.

[erwango]

Closing, since #57467 is now merged