MIMXRT1166 FlexSPI driver stuck in FLEXSPI_UpdateDllValue

[rtborg]

I'm developing a custom driver for IS25LX064 in octal mode and I'm fairly certain the XIP flexspi_nor_config_t is working (confirmed by using in MCUXpresso). For using part no. IS25LX064, I've created a copy of the is25wp128 driver but with updated lookup table.

When flashing and running the resulting binary, the execution reaches FLEXSPI_UpdateDllValue, and is stuck in a forever loop at line while ((base->STS2 & statusValue) != statusValue).

What can I do to investigate the reason for that happening?

[rtborg]

Conext from GDB session:

0x00001e8e in FLEXSPI_UpdateDllValue (base=0x400cc000, config=0x800030d4 <z_main_stack+7956>, port=kFLEXSPI_PortA1) at /home/void/Documents/Projects/C4.3/firmware/modules/hal/nxp/mcux/mcux-sdk/drivers/flexspi/fsl_flexspi.c:473
473                 while ((base->STS2 & statusValue) != statusValue)
(gdb) print *config
$7 = {
  flexspiRootClk = 120000000,
  isSck2Enabled = false,
  flashSize = 8192,
  CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle,
  CSInterval = 0,
  CSHoldTime = 3 '\003',
  CSSetupTime = 3 '\003',
  dataValidTime = 0 '\000',
  columnspace = 0 '\000',
  enableWordAddress = false,
  AWRSeqIndex = 0 '\000',
  AWRSeqNumber = 0 '\000',
  ARDSeqIndex = 0 '\000',
  ARDSeqNumber = 1 '\001',
  AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle,
  AHBWriteWaitInterval = 0,
  enableWriteMask = false
}
(gdb) list
468     #if defined(FSL_FEATURE_FLEXSPI_HAS_ERRATA_051426) && (FSL_FEATURE_FLEXSPI_HAS_ERRATA_051426)
469             if (config->isFroClockSource == false)
470     #endif
471             {
472                 /* Wait slave delay line locked and slave reference delay line locked. */
473                 while ((base->STS2 & statusValue) != statusValue)
474                 {
475                     
476                 }
477             }
(gdb) print /x statusValue
$8 = 0x3
(gdb) print /x *base->STS2
$9 = 0xb082b580
(gdb) print /x *base->INTR
$10 = 0xfbfba4f0

INTR register shows:

• IP command security violation interrupt.
• ECC single bit error interrupt.
• OTFAD key blob processing error interrupt.
• AHB Bus timeout or AHB bus illegal access Flash during OTFAD key blob processing interrupt.
• IP TX FIFO watermark empty interrupt.
• IP RX FIFO watermark available interrupt.
• AHB triggered Command Sequences Error Detected interrupt.

[DerekSnell]

Hi @rtborg ,
Since the FlexSPI DLL is not giving a lock status, this seems like a FlexSPI configuration issue. I recommend you use the NXP Community forum at https://community.nxp.com/ for this hardware peripheral question. Specifically the i.MX RT Crossover MCUs forum, where you can search for similar FlexSPI posts and ask your question there. This GitHub forum is specific to Zephyr, and the NXP team monitoring is focused on Zephyr. But using the NXP Community has teams focused on the SOCs and hardware like the FlexSPI. If you post there, feel free to link these posts so everyone can follow the progress.

It's also possible there is an issue with the FlexSPI serial root clock. I would try to confirm that clock. The FlexSPI will drive that clock out to external flash, and you could measure it to confirm the frequency. You will need the FlexSPI to try to access the external memory, so you may want to hack the driver to skip the DLL status check. Or another potential option is to use the Clock Out pins CCM_CLKO1 and CCM_CLKO2 to confirm internal clocks. Some of the clock mux options overlap with the FlexSPI clock sources.

Best regards

[rtborg]

Hi @DerekSnell ,
The context of my problem is that I'm trying to run Zephyr on MIMXRT1166CVM5A with IS25LX064 octal memory, and I'm using the mx25um51345g Zephyr Flash driver as an example. I've traced the execution to the driver calling memc_flexspi_set_device_config, which ultimately leads to the lock I described in the first post.
I'm suspecting either FlexSPI clock (which I am not explicitly setting and is enabled in soc.c), or the particular flash chip settings. Unfortunately I can't easily measure the FlexSPI clock out at this moment.

I've tried skipping the DLL status check and I get hardware fault. Below are my flash chip settings from device tree:

    is25lx064: is25lx064@0 {
        compatible = "nxp,imx-flexspi-is25lx064";
        /* is25lx064 is 8MB, 64MBit flash part */
        size = <DT_SIZE_M(8 * 8)>;
        reg = <0>;
        spi-max-frequency = <20000000>;
        status = "okay";
        jedec-id = [ 9d 5a 17 ];
        erase-block-size = <4096>;
        write-block-size = <2>; /* FLASH_MCUX_FLEXSPI_IS25LX064_OPI_DTR set */

        partitions {
            compatible = "fixed-partitions";
            #address-cells = <1>;
            #size-cells = <1>;

            boot_partition: partition@0 {
                label = "mcuboot";
                reg = <0x00000000 DT_SIZE_K(128)>;
            };
            /* The MCUBoot swap-move algorithm uses the last 3 sectors
             * of the primary slot0 for swap status and move.
             */
            slot0_partition: partition@20000 {
                label = "image-0";
                reg = <0x00020000 (DT_SIZE_M(3) + DT_SIZE_K(3 * 4))>; 
            };
            slot1_partition: partition@323000 {
                label = "image-1";
                reg = <0x00323000 DT_SIZE_M(3)>;
            };
            storage_partition: partition@623000 {
                label = "storage";
                reg = <0x00623000 (DT_SIZE_M(2) - DT_SIZE_K(140))>;
            };
        };
    };   

[DerekSnell]

Hi @rtborg ,

I also suspect the FlexSPI clock here. Your STS2 register read above of 0xb082b580 shows both the AREFLOCK and ASLVLOCK bits are clear. You mentioned you are "not explicitly setting" the clock. But it sounds like you have an MCUXpresso project without Zephyr working with this flash, which is likely using a different clock configuration.

Confirming the FlexSPI hardware clock at the pins is ideal. But the fsl_flexspi driver does provide the CLOCK_GetRootClockFreq() API the app can use to read the frequency. I tested this on the MIMXRT1160-EVK board with Zephyr, and it confirmed this EVK clocks the QSPI flash at 132 MHz, which also matched what I measured at the pin.

#include <fsl_clock.h>
 
printf("kCLOCK_Flexspi1 root clock frequency is %d Hz\n", CLOCK_GetRootClockFreq(kCLOCK_Root_Flexspi1));

Are you booting from FlexSPI1 and XIPing from this flash? It seems you might not be doing that yet. You refer to the memc_flexspi driver in Zephyr. Typically the i.MX RT boards enabled in Zephyr boot from the FlexSPI flash, and the ROM bootloader configures the FlexSPI. When I did a quick test on the MIMXRT1160-EVK board, it boots from the external QSPI flash. The memc_flexspi driver is not even included unless CONFIG_FLASH=y, and then it does not reconfigure the FlexSPI if XIPing from that flash.

If booting from FlexSPI, the ROM bootloader will configure the FlexSPI clock, and then configure the FlexSPI based on the Flash Configuration Block (FCB) stored in the external flash. When running Zephyr on the EVK, I found the ROM bootloader configures the FlexSPI clock for 132 MHz based on the setting below in the FCB in evkmimxrt1160_flexspi_nor_config.c.

            .serialClkFreq        = kFlexSpiSerialClk_133MHz,

I also see in Zephyr's clock_init() in soc.c, if the app does not boot from the FlexSPI flash but the FlexSPI node is enabled, then the FlexSPI clock source is a very low frequency. I expect that is not what you want for your flash.

Comparing your flash IS25LX064 to the QSPI flash used on the MIMXRT1160-EVK, there are some differences related to the FlexSPI clock you should be aware of. First, the QSPI flash is Single Data Rate (SDR), while your flash supports double DDR. The FlexSPI serial root clock is the input clock to the FlexSPI peripheral provided by the SOC. The output clock SCLK is driven externally by FlexSPI to the memory. With SDR, these 2 clocks are the same frequency, 132 MHz configured by the ROM bootloader. With DDR, the output SCLK will be half the serial root clock frequency. So you will want to configure the serial root clock to be 2x the frequency you want driven to your flash.

Another difference is the DQS signal. The QSPI flash on the EVK does not have a DQS pin, and this limits the SCLK frequency to 133 MHz on the RT1160, see datasheet snippet below. The ROM bootloader configures the FlexSPI for DQS loopback setting with FlexSPI1_MCR0[RXCLKSRC] = 0x1. The FCB configures this with .readSampleClkSrc = kFlexSPIReadSampleClk_LoopbackFromDqsPad.

But your flash does support the DQS pin, and potentially can clock at higher frequencies using FlexSPI1_MCR0[RXCLKSRC] = 0x3. If using the ROM bootloader to configure this option, the FCB uses kFlexSPIReadSampleClk_ExternalInputFromDqsPad.

Let us know what you find, best regards

[rtborg]

Hi @DerekSnell,

Thank you for the extensive response. I used the CLOCK_GetRootClockFreq to check what the FlexSPI clock frequency is in the beginning of the Flash driver initialization, and it turns out it's 24 MHz. In my FCB I've specified frequency of 133 MHz, so I expected to see much higher peripheral clock.

I'm using Zephyr v3.7.0 LTS, and I tracked the reason to this line in clock_init() function. Compare with the same line in Zephyr v4.0.0 sources - the 4.0.0 version checks if the parent of the flash has an nxp,imx-flexspi compatible.

When I modify the v3.7.0 source to use the same statement as the v4.0.0 source:
#if !(DT_NODE_HAS_COMPAT(DT_PARENT(DT_CHOSEN(zephyr_flash)), nxp_imx_flexspi)) && \
the flexspi clock is initialized correctly (or rather not re-initialized to 24 MHz), and my flash driver works.