i.MXRT1176 QSPI on FLEXSPI2 2nd Pin Group can't boot?

[bthorne]

We have a board that has Micron QSPI (MT25Q group) on FlexSPI 2, Secondary Pin Group. The QSPI is routed to these pins:

• FLEXSPI2_A_SS0_B
• FLEXSPI2_A_SCLK
• FLEXSPI2_A_DATA0
• FLEXSPI2_A_DATA1
• FLEXSPI2_A_DATA2
• FLEXSPI2_A_DATA3

I can successfully run, from RAM, the SDK "evkmimxrt1170_flexspi_nor_polling_transfer_cm7" project, after adjusting pin muxing and memory interface settings on our board. One notable item must be set otherwise the flash is not correctly seen and that is the when FLEXSPI_Init(base, &config) is called, config.rxSampleClock must be set to kFLEXSPI_ReadSampleClkLoopbackInternally.

I can also program the flash using the flash loader from the "MCUXpresso Secure Provisioning Tool v3" but not directly via the GUI as it doesn't seem to support the FlexSPI 2 interface.

For programming via the MCUXpresso Secure Provision Tool I send down the following commands to prepare the ivt_flashloader for the proper configuration:

@echo ### Configure target memory using options on address 0x20202000 ###
call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202000 4 0xCF900002 word
if errorlevel 2 exit 2
call "%blhost%" %blhost_connect% -j -- configure-memory 9 0x20202000
if errorlevel 2 exit 2
call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202000 4 0xC1000057 word
if errorlevel 2 exit 2
call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202004 4 0x0001000A word
if errorlevel 2 exit 2
call "%blhost%" %blhost_connect% -j -- configure-memory 9 0x20202000
if errorlevel 2 exit 2

Afterwards I can send blhost commands to erase and program in the address range starting at 0x6000_0000.

I have verified that the flash is being properly programmed and my Flash Control block is getting programmed at offset 0x400 and that the IVT is at offset 0x1000.

I have burnt 2 fuse locations that should tell the bootloader to use FlexSPI2 Secondary Pin Group and those are:

• BOOT_CFG2[3] - FlexSpi Instance. I set this to a 1.
• 0x9A0[10] - FlexSpi Pin Group. I set this to a 1.

When resetting the CPU, it seems like the bootloader is attempting to boot but then fails and falls back to the internal bootloader.

Have I missed a Fuse that I need to set to boot from FlexSpi 2 Secondary Pin Group?

How does the bootloader know to set the memory interface to use "Internally Loop Backed" for the absent DQS Pin?

Is it possible to boot from a QSPI on FlexSPI 2 Secondary Pin Group?

Thanks.

[Stulinaz]

Check this:

https://community.nxp.com/t5/i-MX-Processors/Problem-with-flashloader-on-FLEXSPI2-Instance-B/td-p/16...

i was facing the same problem with my hardware design.

[danielberhe]

Hi bthorne,

I know it has been a while since you posted this, but though I would try reaching out anyway.

I'm currently using MT25QL256 on my custom i.MXRT1176 based board. There are no issues running applications from RAM but no luck with booting from flash or XIP. The flash chip is connected to flexspi primary pin group. I can communicate with the flash OK when I run a modified version of the flexspi SDK sample application.

Have you managed to get it working when you switched to the primary pin group?

Thanks,

Daniel

[nilsl]

You might need to set the non-volatile bit Quad Enable in the Status Register of the flash chip. I don't know if it applies to your chip. Some have it switched on per default, others not.

[nilsl]

We also target using FlexSPI2, Second Pin Group for our boot flash (IS25WP128 Serial NOR; same chip which is connected to FlexSPI1, Primary Pin Group on the evkmimxrt1170). We are using the i.MXRT1176 CPU on a custom board. Finally, we were successful, booting from FlexSPI2, secondary pingroup (GPIO_SD_B1_00 ... GPIO_SD_B1_05). Maybe this is useful for someone:

• We have burned the BT_FUSE_SEL fuse to boot from fuses rather than use GPIO overrides
• Specifically, to enable booting from FlexSPI2, two fuses need to be burned:
  FLEXSPI_INSTANCE (to select FlexSPI2)
  FLEXSPI_PIN_GROUP_SEL (to select Secondary Pin Group)
• Less obvious to us were the necessary changes to the FlexSPI Configuration Block inside the flash image (it is a XIP Execute in Place image). The configuration block is stored in flash at offset 0x400.The Configuration Block begins with the tag 'FCFB'. Refer to evkmimxrt1170_flexspi_nor_config.c to change the settings and to the RT1170 reference manual, especially the following two settings:
• controllerMiscOption: set "bit 8 - Second Pin Group" (the availability and necessity of this setting is not obvious at all from the MCUXpresso SDK source code and samples)
• serialClkFreq: reduce frequency from 133MHz to 60MHz, as DQS pin for high-speed reads is not available when using Secondary Pin Group

I hope this will help someone.

[bthorne]

Hi Victor,

I am still haven't been able to boot via FlexSPI 2 secondary pin mux and but wanted to provide some additional info.

I altered the blhost commands to tell the ivt_flashloader code to use a slower clock rate; however, even at the higher clock rate I seem to be able to erase and flash the QSPI. 

I altered this command:

call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202000 4 0xC1000057 word

to

call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202000 4 0xC1000053 word 

My Flash Configuration block at offset 0x400 is composed from this data:

const flexspi_nor_config_t qspiflash_config = {
.memConfig =
{
     .tag = FLEXSPI_CFG_BLK_TAG,
     .version = FLEXSPI_CFG_BLK_VERSION,
     .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackInternally,
     .csHoldTime = 4u,
     .csSetupTime = 4u,
     // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock
     .controllerMiscOption = 0x110,
     .deviceType = kFlexSpiDeviceType_SerialNOR,
     .sflashPadType = kSerialFlash_4Pads,
     .serialClkFreq = kFlexSpiSerialClk_50MHz,
     .sflashA1Size = 64u * 1024u * 1024u,
     //See 30.6.2.8 table 30-24 in reference manual
     //Quad Input Fast Read = 0xEB (3 byte address mode)
     //Quad Input Fast Read = 0xEC (4 byte address mode)
     //Following seems to be a Fast Read QSPI sequence that specifies the
     // Command (CMD_SDR) 0xEc, Quad I/O Fast Read with # address bits RADDR_SDR=0x20 (4 byte)
     // followed by
     // MODE8_SDR of 0 to specify PAD 4X dummy cycles of 10 (wait time?) Micron sheet seems to fix this
     // followed by
     // Read command (READ_SDR), with Pad 4x, 4 BYTES.
     // finally followed by
     // Stop sequence 0, 0, 0
     .lookupTable =
     {
          // Read LUTs
          FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEC, RADDR_SDR, FLEXSPI_4PAD, 0x20),
          FLEXSPI_LUT_SEQ(MODE8_SDR, FLEXSPI_4PAD, 0x00, DUMMY_SDR, FLEXSPI_4PAD, 0x0A),
          FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_4PAD, 0x04, 0, 0, 0),
          },
     },
     .pageSize = 256u,
     .sectorSize = 4u * 1024u,
     .ipcmdSerialClkFreq = 0x1,
     .blockSize = 256u * 1024u,
     .isUniformBlockSize = true,
};

For XIP does the bootloader read the configuration data at offset 0x400 to configure the FlexSPI interface? Does the bootloader know to set internally loopback on the MCR0 register or does it default to this setting? I have noticed that when I test with the SDK nor_polling_transfer code and I don't set internal loopback on the FlexSPI interface that even when I have the serial clock at a very slow speed of 30MHz I will get bad read when accessing the region at 0x6000_0000. Is it possible the bootloader presumes a hardware configuration like the EVK board and a floating DQS line? I am setting kFlexSPIReadSampleClk_LoopbackInternally in the readSampleClkSrc field.

There is not a lot of documentation describing the controllerMiscOption field. By looking at the evt_flashloader source code I extracted that 0x100 needs to be set to have the interface use the secondary pin group (kFlexSpiMiscOffset_SecondPinMux = 8). Is this incorrect for the bootloader?

Thanks,

Brian

[victorjimenez]

Hello Brian, 

Do you mean I should burn the efuse at 0xC80[2:0], that is defaulted to 100MHz, to a lower rate of say 60Mhz? Or do you mean I should lower the FlexSPI 2 bus frequency used in the XIP code that is being loaded by the bootloader?

Modifying the frequency in the flash configuration block should be enough. 

For XIP does the bootloader read the configuration data at offset 0x400 to configure the FlexSPI interface?

Yes, this is correct. The ROM bootloader will read the flash configuration block and configure the FlexSPI based on this. 

Does the bootloader know to set internally loopback on the MCR0 register or does it default to this setting? 

The ROM bootloader will take this configuration from your flash configuration block as well.

Just to confirm, the  nor_polling_transfer SDK project works fine on your end, correct? This way we can discard a hardware problem. When you execute this example, are you doing XiP from this memory? 

In the past, I have seen this type of behavior. Most of the time, this was because the customer forgot to set the QE bit in their memory, did you set this bit? 

Regards,
Victor 

[bthorne]

Hi Victor,

Yes the nor_polling_transfer code from the SDK works on my NOR flash at 0x6000_0000 on FlexSPI 2 Secondary Pin Group after I adjust the code to use the proper FlexSPI and LUT sequences. I am able to erase and program the flash with the code that is running from RAM.

The nor_polling_transfer SDK code is loaded via J-LINK to RAM and then executed out of RAM. 

So I believe the hardware is functioning correctly as the NOR flash can be erased and written to with the nor_polling_transfer code.

By default this part (MICRON MT25QL512ABB) seems to be in Quad Enable mode by default. For the other time's you've seen this behavior, how did the customer set the QE bit? Was this via the LUT commands in the Flash Configuration block or prior to that?

Thanks,

Brian 

[victorjimenez]

Hello Brian, 

You mentioned that you are executing the application from RAM. By default, the example project loads the image into the external memory, and it just moves to RAM the functions that interact with the memory. Did you make the proper modifications to load the example directly to RAM? 

I reviewed the memory's datasheet, I don't think that the QE bit is set by default. 

The easiest way to set the QE bit is through the application that you are currently using. The nor_polling_transfer example project sets the QE bit by calling the function flexspi_nor_enable_quad_mode. Normally this bit is a non-volatile field, but as far as I can see in the case of the memory that you are using, this is not the case. This means that when you reset the board, you will go back to the Dual protocol. So if my understanding is correct, you'd need to enable the quad bit in the FCB.

Regards,
Victor 

[bthorne]

Hi Victor,

I have tried setting the Quad I/O enable bit (bit 7) in the Volatile Configuration register of the Micron device, the register you listed. Since this is Volatile I need to do this in a LUT in the Flash Configuration block as it needs to be set in every bootup. This did not seem to help.

I've also set the Quad I/O Enable bit in the Non-Volatile configuration register of the Micron device (0xB1). I've confirmed that this value persists during power cycles. This is similar to what the flash loader does by setting the Non-Volatile QE bit in the Status register of the ISSI device. This however also doesn't seem to allow the device to boot from flash.

On initial boot, I observe one chip select pulse going out on FlexSPI 2 second pin group probably to read the FCB, but the nothing afterwards. 

Regards,

Brian 

[victorjimenez]

Hello Brian, 

I'm checking internally if there are any other requirements when booting from the second pin group. I will give you an update as soon as possible. 

Regards,
Victor 

[victorjimenez]

Hello Brian, 

Can you try to flash the board with the MCUBootUtility tool? The tool can generate proper FDCB automatically. Let me know the results. 

Regards,
Victor 

[bthorne]

Hi Victor,

When attempting to use the GUI based tools (Secure Programming Tool), I faced the issue that it didn't support the FlexSPI 2 region. If I try to load my code (elf file) into the tool that is built at address region 0x6000_0000 it won't recognize it as a valid address.

The other issue I faced is that the proper BLT command is not sent to set the flash loader to the proper FlexSPI 2 region. I had to manually add this command for getting the flash loader code to be configured properly:

call "%blhost%" %blhost_connect% -j -- fill-memory 0x20202000 4 0xCF900002 word

The NXP MCUBootUtility tool that I tried (v3.2.0 at the time) had the same issue with not recognizing FlexSPI 2 region and unable to generate the above command to configure the flash loader to the proper FlexSPI regison. I did not check to see if the image generation also faced the same issue as the Secure Programming Tool. Since the MCUBootUtility documentation is much harder to understand and since it seems to be an unsupported tool, I only put effort into the Secure Provisioning Tool.

It really seems like the FlexSPI 2 second pin group just doesn't support  booting and XIP operation. With the fuses burnt we see just one chip select access to the 0x6000_0000 region on FlexSPI 2 and then nothing afterwards until the watchdog seems to expire and try over again. 

I keep coming back to the DQS setting in the FlexSPI Bus Init. If the DQS setting is not set to internally looped back then nothing can be read properly from FlexSPI 2 second pin group. By using the NOR flash test code that loads directly into RAM I can exercise this region but only if I set the internal loopback in the FlexSPI Bus init. All NXP code seems to default to setting "loopback from DQS pad" rather than "internal loopback". Does the bootloader code inside the NXP 117x automatically set the FlexSPI interface to "loopback from DQS pad" when it attempts to read the FCB? If it does then it won't be able to read the flash contents properly and there is really no hope.  

[victorjimenez]

Hello Brian,

Thanks for your patience with this thread. When using the MCUBootUtiliy, if you go to the Tools menu, you'll find an option named FlexSPI XIP Region. This option is to select the FlexSPI interface from which you want to boot. To select FlexSPI2, you need to select the 1. 

Are you able to get this working if you select this option? 

Regards,
Victor 

[bthorne]

Hi Victor,

Unfortunately no. We have also abandoned trying to get this configuration to work. We are re-spinning to the board to put it on a FlexSPI 1 interface.

Regards,

Brian

[victorjimenez]

Hello Brian, 

I'm aware that you decided to move one with the first pin option. However, I wanted to share an update with you. The author of the MCUBootUtility tool mentioned that you also need some other changes. You still need to set 2nd pinmux group in MCUBootUtility tool as below:

Regards,
Victor 

[victorjimenez]

Hello, 

It is possible to boot from the second pin group on FlexSPI2. However, with this pin group, you won't have a DQS pin. Due to this, only low-speed read is supported. This will leave you with a very low performance while doing XiP. If speed is key for your application, I would suggest using a different pin option. 

What is the serialClkFreq? Is it set up to 133MHz? If yes, then the problem can be related to this. That is also why the erase and program commands are working, as these are done at a lower clock frequency. I suggest lowering the serialClkFreq, for example, 50MHz. Does this solve the problem that you were facing? 

Regards,
Victor 

[bthorne]

Hi Victor,

I'd like to clarify what you mean by lowering the serial clock frequency. Do you mean I should burn the efuse at 0xC80[2:0], that is defaulted to 100MHz, to a lower rate of say 60Mhz? Or do you mean I should lower the FlexSPI 2 bus frequency used in the XIP code that is being loaded by the bootloader?

Thanks,

Brian