We had:
- An STM32H7Sx with an external flash on one XSPI port, and an external RAM on the other;
- Both external devices memory mapped;
- The core clock running at 380 MHz.
- XPI1 mapped to port 2, and vice versa.
- XSPI clock running at 200 MHz.
Using our adapted version of ST's secure bootloader, we erased sectors of the external flash, but found that this consistently caused corruption in the external RAM, and it also looked like the erases weren't fully successful either.
The driver code which carried out the erases removed the flash from the memory map before each operation, and added it back afterwards.
We found that to avoid the RAM corruption, it was necessary to also remove the RAM from the memory map before the flash erase operation, and add it back afterwards.
We had assumed that the two buses were independent (despite meeting in the XSPIM), so this result was unexpected; and it's still not clear to us why an erase operation in the flash would cause corruption in the RAM.
Also, this problem does not occur if the core clock is 600 MHz.
Is this a hardware bug? If so, could you add it to the errata document?
Thank you.
(PS: for details of how we fixed this in software, see this post.)
