imx rt 1024: validate speed of flash to be 30/60/133 MHz

[bp1979]

How can I proof that flash is operating on a certain frequency?

I am using an SDK example for the 1024 and wrote a simple for loop which executes a "nop" and using a stopwatch to measure the duration of that for-loop.

I am doing this in the SystemInit while the I-CACHE is disabled, assuming that this is when the cache of the CPU is disabled.

I run that test with two version of the bin file.

version1:

- DQS enabled in startup code

- sample freq source = kFLEXSPIReadSampleClk_LoopbackFromDqsPad

- FlexSPI clock = 133 Mhz

version2:

- DQS disabled in startup code

- sample freq source = kFLEXSPIReadSampleClk_LoopbackInternally

- FlexSPI clock = 60 MHz

The "test" code

    for (volatile int i=0; i<99999999; i++)
    {
    	__asm__ volatile ("nop");
    }

Measuring the duration of the test in both cases gives identical results. Roughly 17 seconds. Some noise on top of that because I am starting and stopping the stopwatch manually. But I would expect to see a difference in duration by factors when the instructions are read from flash while flash is running on a significant slower speed.

Is my test wrong? Is there another way I can actually see the "result" of executing from flash with a significant slower frequency?

[mjbcswitzerland]

Hi

Also the FlexSPI has caching and so, in your test case, it is very probably doing a single burst read of the code and then the instructions in the test loop never need to be taken of the QSPI flash any more - giving the same results, irrespective of the speed of the FlexSPI bus.

Try
FLEX_SPI_AHBCR = FLEX_SPI_AHBCR_READADDROPT;
That is write the value 0x00000040 in order to disable its local caching and then you should find that it has to keep fetching the instructions from the QSPI flash device in the loop and gives a difference in the measurement results.

Regards

Mark


For our discounted i.MX and Kinetis stock availability see https://www.utasker.com/Shop/semi.html

[bp1979]

Hi @mjbcswitzerland Mark,

My two tests still produce the same timings. Around 17+ seconds  (17.2 .. 17.6, I guess my gaming days are over, reaction isn't what it once was ;-)).

Added your suggestion in the main of the SDK example

    EXAMPLE_FLEXSPI->AHBCR |= 0x40;

    for (volatile int i=0; i<999999999; i++)
    {
    	__asm__ volatile ("nop");
    }

And controlling DQS, clock source and flash frequency in the SystemInit as shown before. Doesn't seem to care about this either.

Any ideas how big this cache is? I thought to be smart and duplicate the "nop" 2500 times inside the for-loop, forcing the CPU to fetch from flash. But that didn't work either.

Would you have any other suggestions? Or does this already prove the flash simply isn't running on a lower frequency?

[mjbcswitzerland]

Hi

 EXAMPLE_FLEXSPI->AHBCR |= 0x40;

should be

 EXAMPLE_FLEXSPI->AHBCR = 0x40;

Regards

Mark

[bp1979]

Sorry, tried both. After reading the comments in the header i thought maybe to only set that bit high and tried to xor it. But neither case gave any effect

[mjbcswitzerland]

Hi

You may need to ask NXP directly since I used that value in order to allow reading back the 'real' content of the QSPI Flash after it was modified (otherwise the cache tends to read back the old value) - that works for my case and I was assuming that it disables caching but it may not work exactly like that.

You could however also measure the clock speed itself on CCM_CLKO2 (GPIO_SD_B1_03). I do this with:

fnSetClock2Output(FLEXSPI_CLK_ROOT, 8); // connect the FLEXSPI_CLK_ROOT to the CLKO2 output (divided by

which equates to:

#define CCM_CCOSR_CLKO2_SEL_FLEXSPI_CLK_ROOT 0x001b0000 // selection of clock on CCM_CLKO2 - flexspi_clk_root
#define DIVIDE 8

1. select the clk2 source
CCM_CCOSR = ((CCM_CCOSR & ~(CCM_CCOSR_CLKO2_SEL_MASK | CCM_CCOSR_CLKO2_DIV8)) | CCM_CCOSR_CLKO2_EN | CCM_CCOSR_CLKO2_SEL_FLEXSPI_CLK_ROOT | (((DIVIDE - 1) & 0x7) << 21)); // select the CCM_CLKO2 source
2. connect CCM_CLKO2 to the pin
_CONFIG_PERIPHERAL(GPIO_SD_B1_03, CCM_CLKO2, (PORT_SRE_FAST | PORT_SPEED_MAX | PORT_DSE_MID)); // CCM_CLKO2 on GPIO3-23 - alt 6

which itself equates to

IOMUXC_SW_MUX_CTL_PAD_GPIO_SD_B1_03 = GPIO_SD_B1_03_CCM_CLKO2; // 0x06
IOMUXC_SW_PAD_CTL_PAD_GPIO_SD_B1_03 = (PORT_SRE_FAST | PORT_SPEED_MAX | PORT_DSE_MID) //  0x000000d9

The 'real' FlexSPI clock is then 8x higher than the frequency measured on the pin and therefore you can easily check that it is really set to what you expect it to be without needing to interpret it via code delays. You can also change the divide but it can be difficult to accurately measure the 133MHz case as the output may have difficulty following it.

Regards

Mark