I just checked the speed of the QSPI Flash clock when booting from it.
Initially it was 31.25MHz and then switched up to 166MHz.
I presume the ROM bootloader programs a fairly slow speed to read the configuration and then, once it has read in the configuration data from the boot configuration, switches to the advertised frequency.
In the configuration of the program loaded I found
.serialClkFreq = kFlexSpiSerialClk_100MHz,
and changed it to
.serialClkFreq = kFlexSpiSerialClk_30MHz,
and loaded again.
However the QSPI flash clock speed stays at 166MHz.
I checked that the correct value is programmed at location 0x60000046. From user's manual:
1 or 6 both gave 166MHz, as reported above.
Does this mean that this entry is ignored by the ROM boot loader and it always sets the highest speed? I see that it has the FLEX_SPI_CLK_ROOT sourced from SEMC_CLK_ROOT with no further dividers. SEMC_CLK_ROOT is connected to PERIPH_CLK with its pre-scale divider still at 3. Presumably the ROM loader also also switching PERIPH_CLK to 500MHz when it runs(?)
FLEXSPI_CLK_ROOT can sourced from SEMC_CLK_ROOT_PRE depends on the clock tree. and has dividers via FLEXSPI_PODF. For the detail information one may refer to the document
https://community.nxp.com/docs/DOC-340813 , it is similar with FLEXSPI_CLK_ROOT.
I understand how to control the FLEXSPI clock from code but the question is about why the ROM loader looks to ignore the setting in the configuration 'before' the user code takes control. It seems the speed is stuck at 166MHz and if one's HW design couldn't run at this rate it looks impossible to control the ROM loader to use a slower speed.
I have performed more tests and now can confirm that the FlexSPI clock speed does indeed follow the configuration value.
Results when connected to the debugger and when not are not the same and so I presume that the debugger had an influence on initial test results!