Boot from external memory

The i.MX RT MCU does not have any internal flash memory for storing the application. It must be stored in an external memory. The i.MX RT1064 is no exception, but NXP has packaged a QSPI flash chip inside the same package as the microcontroller itself, so it looks like the flash memory is internal. From a program development and memory layout point of view, all i.MX RT microcontrollers are designed the same.

On the iMX RT1064 uCOM board, the flash memory is inside the package (as mentioned above) and is a 4MByte QSPI memory.

On the iMX RT1166/RT1176 uCOM boards, the flash memory is an external 16Mbyte QSPI memory.

The i.MX RT MCU always boots (i.e., starts executing) from these respective QSPI flash memories.

First, let's investigate the three use-cases when executing an application. The picture below illustrates the first main use-case when executing an application.

1. The application is stored in the external flash and the bootloader (inside the i.MX RT) copies it into internal SRAM and then run from there.
   1. The execution performance will be the highest in this setup.
   2. During program development the application is just downloaded to internal SRAM by the debugger. There is no need to first download the application to the external flash memory. The address (in SRAM) where the application is downloaded is the same that it will be copied to by the on-chip bootloader in a final deployed system.

The second use-case is illustrated below. It is the default option supported when compiling and building the Xip targets

Note that on the i.MX RT1064 microcontroller, the external flash is inside the same package, but the overall architecture is still the same.

2. The application is stored in the external flash and executed from there. In this case, the internal SRAM is probably too small for the application or is simply used for other things like data storage.
   1. The execution performance will be considerably lower than the performance when executing from internal SRAM.
   2. During program development the application must be downloaded/flashed to the external flash memory before debugging starts. This is normally handled automatically by the IDE (Integrated Development Environment).

The third use-case is just a mixture of the two main ones. Two, or more memories, are used for storing executable code.

3. The third setup is a mixture of the two above. Part of the application is copied into SRAM and/or SDRAM and part is executed directly from the external flash. A reason for placing part of an application in SRAM can be a need for highest performance for a data processing algorithm or a time critical interrupt service routine.
   1. Note that this is a more complicated system architecture. The application must implement a dynamic loader that can copy code from the external flash to SRAM, either on-demand or in a pre-scheduled way. The linker script can be much more complicated because of this. There is no general solution for this system solution. Every system must be individually investigated in order to select and implement the best solution.