Auto Probe 功能体验

1. Auto Probe 功能

除了i.MX RT1064，i.MX RT MCU系列本身是不含有内部Flash的，所以需要外挂存储设备来存放代码程序，这样i.MX RT MCU就可以在启动阶段加载它后运行。
i.MX RT支持的外挂存储设备包括 QSPI Flash，HyperFlash，SDcard，eMMC，Nand Flash，甚至还有并行 NOR Flash等，其中 QSPI Flash运用场景的最多，官方板子也基本上都是使用 QSPI Flash作为外挂存储设备，但是有个问题，不同的QSPI Flash的厂商提供的产品在命令，存储大小及分区方面都不是完全兼容和一致的，那如何让i.MX RT MCU识别这些有差异的QSPI Flash呢？
NXP通过Bootable image的代码结构来实现，存储在外挂存储设备的i.MXRT Bootable image除了包含Application binary数据之外还包括其它额外的信息，这些额外的信息数据按功能可分有6类，但这6类信息数据并不都是必须的，其中有4类是可选的，因此一个Bootable image最多由7部分组成，最少由3部分组成。
其中Bootable image的第一个组成部分叫FDCB，是个可选组成部分，FDCB是从Flash的起始地址处开始存放的，也是Bootable image最开始部分。FDCB最大为4KB，其本身没有统一的与Flash无关的structure，具体structure根据启动Flash的接口类型（Serial/Parallel）而定，其一般是用来存储当前连接的Flash的具体特性参数，Boot ROM上电后会使用通用且可靠的Flash接口控制器配置（即Boot ROM中默认参数配置，一般是比较低速的配置）去访问外接Flash并获取FDCB，然后根据FDCB存储的参数去重新配置Flash接口控制器再去进一步访问Flash，所以如果外挂设备是Serial NOR Flash，则FDCB必须被包含在Bootable image内，但是Auto Probe 功能可以允许我们无需配置FDCB，直接无视“它”，
使能Auto Probe 功能后，在启动阶段，ROM 代码可自动识别出外挂的Serial NOR Flash，并随后配置Flash接口控制器，下面的结构体是Serial NOR Flash的FDCB原型。

typedef struct _flexspi_nor_config
{
    flexspi_mem_config_t memConfig; //!< Common memory configuration info via FlexSPI
    uint32_t pageSize;              //!< Page size of Serial NOR
    uint32_t sectorSize;            //!< Sector size of Serial NOR
    uint8_t ipcmdSerialClkFreq;     //!< Clock frequency for IP command
    uint8_t isUniformBlockSize;     //!< Sector/Block size is the same
    uint8_t reserved0[2];           //!< Reserved for future use
    uint8_t serialNorType;          //!< Serial NOR Flash type: 0/1/2/3
    uint8_t needExitNoCmdMode;      //!< Need to exit NoCmd mode before other IP command
    uint8_t halfClkForNonReadCmd;   //!< Half the Serial Clock for non-read command: true/false
    uint8_t needRestoreNoCmdMode;   //!< Need to Restore NoCmd mode after IP commmand execution
    uint32_t blockSize;             //!< Block size
    uint32_t reserve2[11];          //!< Reserved for future use
} flexspi_nor_config_t;

2. 实验过程

首先，Auto Probe功能是i.MX RT1060特有的，所以测试的硬件平台选为MIMXRT1060-EVK，而且为了增加实验的说服性，我除了使用板载的IS25WP064测试外，还会使用MX25U6435进行验证。测试步骤如下：

生成evkmimxrt1060_iled_blinky的application image文件

1.1 修改XIP_BOOT_HEADER_ENABLE为0

Fig 1

1.2 修改存储空间分配

Fig 2

1.3 重新编译工程，生成evkmimxrt1060_iled_blinky.s19文件

Fig 3

1.4 将开发板与NXP MCU BootUtility工具建立连接（Fig 4），随后烧录Bootable image 到QSPI Flash，烧录完成后就可看到FDCB就存储在QSPI Flash的起始位置（Fig 5）。

Fig 4

Fig 5

1.5 断开连接，重新配置SW7按键为从QSPI Flash启动，上电后，观察led_blinky工程是否运行成功
1.6 重新将开发板与NXP MCU BootUtility工具建立连接，然后删除FDCB部分（Fig 6），然后重复步骤5。

Fig 6

在板载的QSPI Flash换成MX25U6435（Fig 7），重复上述的4~6步骤。

Fig 7

实验结果

不管是IS25WP064还是MX25U6435，在完成步骤5和步骤6后，iled_blinky都能成功运行，有规律的点亮LED。