RT1176 FlexSPI2 NOR Flash Configuration Boot Issue

[mckaylund]

Using the RT1176, we are trying to configure an external NOR flash device as a primary boot memory attached to FlexSPI2 (PortA).  The external flash NOR device we are using (IS25WP128-JBLE) is identical to the one on the i.MX RT1170 Evaluation Kit.  Using the Secure Provisioning Tool (SPT), we can partially initialize the NOR flash using blhost and flashloader which appears to read the NOR flash, but its actually not fully functioning.  We can successfully run the SPT “Test the configuration” utility, but that doesn’t seem to indicate the NOR is fully functioning.  In other words, the tool fails to erase the NOR flash due to the erase block size being unknown and the FCB "tag" value doesn't match.  We’ve spent many weeks reading documentation and forums but cannot get the RT1176 to boot and run our application.  It appears the boot memory configuration parameters aren’t correct although we think we  have followed all the documentation.

We have however figured out a hack that allows us to read, write, erase, and program an image to our external NOR flash (screenshots attached).  The hack involves using the EVK board to generate an fcb.bin file using the Secure Provisioning Tool’s “Convert to FCB” utility, which we then write to our electronics implementation.  We then tweak the boot memory configuration parameters to match our memory configuration and then re-generate another fcb.bin using our electronics implementation(see attached schematic).  After this, we then can successfully read, write, erase, and program an image onto our external flash NOR installed on our electronic implementation.  However, after a power cycle, the RT1176 is unable to boot our application.  It appears that the configuration is still incorrect; the bootloader can’t find the image, or the FlexSPI2 to external flash configuration is incorrect.

Here are some notable configurations for our setup:

• We have blown the “FLEXSPI_INSTANCE” e-fuse so that the FLEXSPI2 is selected.
• We have blown the “FLEXSPI_PIN_GROUP_SEL” e-fuse so that the secondary pins are used.
• We have blown the "BT_FUSE_SEL" e-fuse so that we boot from fuse options
• All configuration override GPIO pins are disconnected.
• We have placed our application image at address offset 0x3000.

[mckaylund]

We have discovered a workaround and the RT1176 can now load our application from external flash into RAM.

As described previously, we first must write the EVK's .fcb file to our electronics implementation.  If we attempt to convert the fcb file without first writing the EVK's .fcb file into our electronics, it produces an error (see attached).  We then modify the memory configuration parameters for a flash NOR device connected to FlexSPI2, portA (configuration image attached).  We then re-generate the .fcb file with these parameters using the "Convert to FCB" utility within the "Boot Memory Configuration" window.  After following these steps we can read, write and erase the flash.

The last remaining issue is that the "readSampleClkSrc" parameter generated by the "Boot Memory Configuration" utility is incorrect.  Nowhere in the official documentation did we come across what the specific requirement for "readSampleClkSrc" is supposed to be.  It turns out that the Secure Provisioning Tool actually incorrectly sets it to "loopback from DQS pad", or 0x01.  We found the correct setting in a statement found in the following blog: https://www.cnblogs.com/henjay724/p/15139381.html .  Our configuration, which uses FlexSPI2 on portA, doesn't support a DQS signal.  Within Step 2 of the above mentioned blog it states " the four-wire Flash connected to this pin can only run at the SDR 60MHz low speed (DQS signal is configured in internal loopback mode)".  This was the critical piece that allowed our application to boot.  After following the aforementioned steps and using the "Convert to FCB" utility to write the FCB to our external memory, we had to modify the "readSampleClkSrc" byte within our external flash to the value of: 0x00, internal loopback mode (see attached).

Still not sure why we can't initially communicate with our external flash using the Secure Provisioning Tool without the hack. Would be helpful to know why we must perform the workaround outlined above to get the RT1176 to communicate with our external flash.