i.MX RT FlexSPI clock frequency

[MulattoKid]

Hi,

I've got a question regarding the setup of the FlexSPI for i.MX RT.

In the i.MX RT HAL there's this definition

wolfBoot/hal/imx_rt.c

Line 331 in 3801b49

#define CONFIG_SERIAL_CLK_FREQ kFlexSpiSerialClk_100MHz

which is used to generate the FCB (Flash Configuration Block) that goes into the first 4KiB of flash to be read by the BootROM.

Later, in hal_flash_init() if USE_GET_CONFIG is defined, the FlexSPI configuration is read and then used to initialize the FlexSPI again.

wolfBoot/hal/imx_rt.c

Lines 887 to 894 in 3801b49

	ret = g_bootloaderTree->flexSpiNorDriver->get_config(
	CONFIG_FLASH_FLEXSPI_INSTANCE,
	&flexspi_config,
	&flexspi_cfg_option);
	if (ret == kStatus_Success) {
	ret = g_bootloaderTree->flexSpiNorDriver->init(
	CONFIG_FLASH_FLEXSPI_INSTANCE,
	&flexspi_config);

However, the flexspi_cfg_option is set to a value that specifies a max frequency (0x7 = 7d = 120MHz) when getting the configuration.

wolfBoot/hal/imx_rt.c

Line 881 in 3801b49

flexspi_cfg_option.option0.U = 0xC0000007; /* QuadSPI-NOR, f = default */

From testing it seems that when getting the FlexSPI configuration the returned configuration has its frequency set to 0x7 even though the frequency specified in the FCB is 100MHz = 6d = 0x6. Thus, when initializing the FlexSPI afterwards the frequency won't match what was specified in the FCB.

I'm not sure if this is intentional, but it doesn't seem like it is as the FCB is populated with a specific value that's then "discarded" later while initializing the platform?

Some additional resources:

Frequency mapping from reference manual for i.MX RT 1060

Capture of QSPI interface traffic between our i.MX RT1061 and our flash chip (note that I changed the frequency in the FCB to 30MHz and the value in flexspi_cfg_option.option0.U = 0xC0000002 to instead go from 30MHz to 50Mhz to be able to capture the frequency with a Saleae Logic 8 Pro)

• Before g_bootloaderTree->flexSpiNorDriver->init()

• After g_bootloaderTree->flexSpiNorDriver->init()

Kind regards,
Daniel

[danielinux]

Hey Daniel,
Thanks for reporting this.

[MulattoKid]

I now also noticed that in clock_init() the FLEXSPI_PODF is hardcoded to 7, which equals a divide-by-8. I'm not sure how this fits into the above observations?

[bigbrett]

Hi @MulattoKid ,

Thanks for pointing this out. We are reviewing this internally and trying to untangle the NXP docs. Perhaps this could have been an oversight, as the docs do not make it clear whether you should even specify a max frequency in the config structure before calling get_config() and whether or not it will not be overridden or clamped to a lower value on return, however they do it just like we do in their example.

Either way, Is the way it works right now an issue for you? If so, could you comment on what you see as "correct" behavior? I imagine that is just not updating the frequency to differ from that specified in the FCB (CONFIG_SERIAL_CLK_FREQ)?

[MulattoKid]

Hi @bigbrett,

Sorry for the delayed response.

No, this isn't an issue for us. I was doing some unrelated debugging and noticed the FlexSPI frequency being different than what we had configured through NXP's MCUXpresso Config tool, and then started digging. I then found the frequency came from wolfBoot, but was puzzeled that it didn't match CONFIG_SERIAL_CLK_FREQ and continued digging. I think it would make sense to have the FlexSPI frequency match CONFIG_SERIAL_CLK_FREQ when control is passed to the user application (as you suggest).

[bigbrett]

@MulattoKid sounds good. We will address this in a subsequent release. Thanks for pointing it out.