I have the same experience with application loaded by bootloader.
For FMICLK=96MHz the FMI_ReadWaitState must =FMI_READ_WAIT_STATE_3
and FMI_WriteWaitState must =FMI_WRITE_WAIT_STATE_1.

This is set by FMI_Config function prior to switching the MCLK
to PLL at 96MHz.

Problem is, that the ST's Software Library has a bug in 91x_fmi.c right
in FMI_Config.
So originally the processor stucks just in moment of executing the FMI_Config(......) in newly downloaded application in Bank0.

I apologize to ST, the reason for not functioning the FMI_Config was due to wrong configuration of my ST library, not the bug in the library itself.
I'm using RIDE and have selected the using of ST libraries (STRx-LIB).
The library is probably compiled for booting from Bank0 and when booting from Bank1 the FMI_Config hangs.

My programs perfectly work on 96 MHz without disabling EMI check box in Keil startup both in the loader and in an application.
I have written the loading program using an example from ST but without use of their libraries.
However procedures of work with FLASH in my program are executed from RAM

Hi AlexandrY,
Please answer me.
I also think that this is the exactly the problem.
But in my aplication that must be downloaded via bootloader
i disable the Flash Memory Interface (FMI) option because i use
software remaping before jump to aplication. That is why
this line : LDR R0, =FMI_BBADR_Val ;
not compatible
i prefer to use it in such way. Is there any way not to disable
Flash Memory Interface (FMI) option ? And to use it exactly
as you wrote.