Abstract
It has been almost 6 years since the earliest RT1050 series was launched. There are already a lot of discussions and articles on how to configure FlexSPI to boot from SPI FLASH in the NXP community. But there are still so many questions about how to configure FlexSPI and how to start from Quad/Octal/Hyper SPI Flash. The difficulty of getting started with i.MX RT is the same for all embedded engineers around the world.
Novice players often don't know where to start when they get chip and SDKs. Although the i.MX RT is claimed to be an MCU, unlike the vast majority of MCUs, it does not have its own built-in Flash, but requires Flash to be installed externally on FLEXSPI. The FLEXSPI interface is very flexible and can be used to plug in various serial Flash devices. Commonly used include four wire (QUAD), eight wire (Octal), and HyperFlash. Due to the different brands, capacity, connection, and bus of external flash devices, it is necessary to modify the configuration of the FLEXSPI interface to adapt to them. In addition, it is necessary to modify the download algorithm to adapt to various debug probes and IDEs. Faced with these difficulties, beginners need to explore for a long time and read a lot of materials to gradually understand. This clearly reduces the speed of project development, especially compared to the SoC with embedded FLASH.
The purpose of this article is not to go through all the knowledge in detail, but to provide a complete process framework, so that newcomers can follow the map and complete it step by step, without having to search for information everywhere and spend a considerable amount of time in their minds piecing together puzzles.
The following diagram is the flowchart of the entire flash enablement process. In addition to the early hardware design, there are mainly two parts. One is the flash download algorithm for IDE; The second is the flash configuration header FCB in the application. Once these two are completed, one can officially enter the application development process of the project. As for flash encryption, multi-image startup, and so on, they are all very later matters and have nothing to do with this article.
The serial numbers in the flowchart represent annotation and data index.
- FLEXSPI can support various SPI bus from 1-bit to 8-bit. And through the FLEXSPI interface, bootROM can start application from NOR SPI Flash and NAND SPI Flash. But so far, most of the RT projects use NOR Flash. Because NOR Flash supports running directly on Flash (XIP), while NAND flash doesn’t. The program must be copied to RAM before it can run. The read and write speed of FLEXSPI is influenced by various factors, including but not limited to the type of Flash interface, maximum speed, interface width, cabling, cache, and so on. The application below is about the performance checking.
https://www.nxp.com/docs/en/application-note/AN12437.pdf
- The FLEXSPI startup configuration is very flexible, but there are also limitations, and each RT devices are different. If it is not the default connection like EVK, it is still necessary to check RM. Besides RM, the article written by Jay Heng is very worth reading. Although they are in Chinese, the tables and figures in these articles are useful to reader.
恩智浦i.MX RTxxx系列MCU启动那些事(6.B)- FlexSPI NOR连接方式大全(RT600)
恩智浦i.MX RTxxx系列MCU启动那些事(6.B)- FlexSPI NOR连接方式大全(RT500)
恩智浦i.MX RT1xxx系列MCU启动那些事(11.B)- FlexSPI NOR连接方式大全(RT1015/1020/1050)
恩智浦i.MX RT1xxx系列MCU启动那些事(11.B)- FlexSPI NOR连接方式大全(RT1060/1064(SIP))
恩智浦i.MX RT1xxx系列MCU启动那些事(11.B)- FlexSPI NOR连接方式大全(RT1010)
恩智浦i.MX RT1xxx系列MCU启动那些事(11.B)- FlexSPI NOR连接方式大全(RT1160/1170)
It is important to note that if the speed of QUAD SPI exceeds 60M, FLEXSPI's DQS pin must be suspended. This has been mentioned in both RM and hardware design guide, but it is not very noticeable.
- The way to tell the bootROM/flashloader how flash is connected is setting BOOT_CFG pin or burning eFUSE. Thus bootROM/flashloader can know where to read the FCB before the user program starts. FCB refers to Flash Configuration Block. The FCB position of each RT chip may vary. The FCB position in RT10xx is generally at the 0 address of Flash, while the FCB position in RT11xx and RTxxx is at 0x400. In short, the startup process is to first read eFUSE or BOOT_CFG pins by bootROM/flashloader to get where the flash is, then reads the configuration information of the Flash from the FCB using 30MHz single line SPI mode, and then configures the Flash. After that high-speed execution of user program in Flash is supported. BTW, bootROM and flashloader are different things. In RT10xx, bootROM connect with sdphost.exe to download flashloader to SRAM, and then flashloader connect wtih blhost.exe to do other works. This is called serial download mode. In RT1xxx and RTxxx, bootROM connect with blhost.exe directly. But flashloader is still needed.
- To download the program to Flash for debugging and execution, you need to download flash algorithm first. The download algorithm for different flash devices are likely to be different.
- RT1024 and RT1064 have already embedded a third-party flash die, so their algorithms are ready-made and already available in the demo in SDK. Additionally, they cannot be started from other external flash connected.
- Multilink supports all RT series devices. You can read these two articles
https://www.nxpic.org.cn/module/forum/thread-617191-1-1.html
https://www.nxpic.org.cn/module/forum/thread-617508-1-1.html
Sometimes there will be new algorithm or new device supported, please download from here:
https://www.pemicro.com/arm/device_support/NXP_iMX/iMX/index.cfm
- SFDP is a standard proposed by the JEDEC organization for serial interface flash, also known as JESD216. It provides a set of registers to represent the characteristics of flash. Flash algorithms can learn how to burn flash through this data.
https://www.jedec.org/document_search?search_api_views_fulltext=JESD216
- When using the MCUXpresso IDE, Segger Jlink's debugger only uses the flash download algorithm from its own installation package and does not accept the algorithm specified by the IDE. Keil and IAR can enable JLINK to use both the IDE's built-in download algorithm and the algorithm in the JLINK driver package. RT-UFL is a universal download algorithm designed by Jay Heng for JLINK. The supported devices include QSPI, Octal SPI, and HyperFlash. Even if a Flash does not support SFDP, it can still support it. It is really useful. And since this project is open source, users can also port its code to download algorithms for other debug probe.
https://github.com/JayHeng/RT-UFL
- In MCUXpresso, right-click on the project ->properties ->MCU Settings ->Memory with type flash to select driver. There are candidates like MIMXRT1170_QSPI_SFDP.cfx, or MIMXRT1060_SFDP_HYPERFLASH.cfx. As long as the flash used supports SFDP, you can give it a try.
- If the above steps cannot find a suitable download algorithm, then you can only create one by yourself (of course, you can also search the community first, or ask to NXP support people via a ticket in NXP support. But most probability there isn’t). There are templates in the installation directory of MCUXpresso, which can be modified to fit your case. The modified parameters come from the test result of flexspi_nor_polling demo in SDK.
MCUXpressoIDE_11.7.1_9221\ide\Examples\Flashdrivers\NXP\iMXRT
- Keil also has templete, it is at Keil_v5\ARM\Flash\MiMXRT105x_ATXP032
- This is for IAR.
https://updates.iar.com/filestore/standard/001/001/123/arm/doc/FlashLoaderGuide.ENU.pdf
- NXP officially recommends the Secure Provisioning Tool (SPT). In addition, the NXP-MCUBootUtility, which was born earlier, has almost the same functionality and is also constantly being updated.
Secure Provisioning Tool:
https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-s...
NXP-MCUBootUtility:
https://github.com/JayHeng/NXP-MCUBootUtility
- If SFDP is not supported, you can only use the FLEXSPI test program in the SDK package to explore the configuration parameters. Please refer to the NOR or the hyper project.
SDK_2_13_0_EVK-MIMXRTxxxx\boards\evkmimxrtxxxx\driver_examples\flexspi\nor
- If SFDP is supported, it would be easier to handle. I.MX RT's bootROM supports simplified configuration of flash. By input one or two word configuration words, the bootROM can automatically configure with flash. The meaning of configuration words can be found in the system boot chapter of RM.
Both SPT and MCUBootUtility configure FLEXSPI in this way. Users can select similar models in the menu and modify some parameters. These parameters will eventually become option0/option1 and be passed to the bootROM.
- Click on the Test button in the figure above and pray it can pass. If it doesn't pass, modify the parameters and try again. Sometimes it's really can’t configure the flash by simplified way, so you can only use the "User FCB file" option and specify one for it.
- Click the "Convert to FCB" button to export the binary file of FCB. This bin file can be used in the future to create complete images for download. There is also a great use here to reverse to flexspi_nor_config_t structure.
- In RT1xxx SDK demo, it is flexspi_nor_config_t structure in \xip\evkmimxrt1xxx_flexspi_nor_configure.c. In RTxxx SDK demo, it is in \flash_config\flash_config.c. It will be compiled at allocate to FCB position. The content of this structure is similar to the configuration in flexspi_nor_polling project. Passing that project can also provide a complete reference for this structure. Completing this structure is the goal of this branch (see (3)).
The binary file exported can be referred as this picture.
If you feel it is boring, the attachment fcbconverter.py is a python tool which can convert the .bin to flexspi_nor_config_t.
After you finished this work, here is a good article which may guide you to the next step. It is because the LUT table generated here is very concise. Users can fill in a complete table as needed.
https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT10xx-image-reserve-the-APP-FCB-methods/ta-p/15...
- QE bit is very important to Quad Flash. The point here is that if you use option0/option1 to configure flash, the bootROM or flashloader will automatically configure the QE bit. Since QE bits are nonvolatile, there is no need to worry about the QE bit of this board in the future. But if you don't plan to use option0/option1 to configure flash, you have to write this bit by yourself. You can use flexspi_nor_polling demo, which writes QE after initialization.
- If Octal FLASH is used, here is another article which can guide the entire process.
https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT1170-Octal-flash-enablement/ta-p/1498369
- If a project initiated from FLEXSPI FLASH, it must include header information such as FCB and IVT. DCD is optional. Please refer to the system boot section of RM for specific content. The following AN explains it more clearly.
https://www.nxp.com/docs/en/application-note/AN12108.pdf
https://www.nxp.com/docs/en/application-note/AN12107.pdf
Conclusion:
I.MX RT can support the vast majority of Quad Flash, Octal Flash, or HyperFlash on the market. Following this guide, FLASH problem will not hold you much time.
Finally, no matter what kind of difficulties you encounter, you can ask questions on NXP's community or create support ticket on the official website. NXP will have dedicated person to answer these questions.