痞子衡嵌入式：在i.MXRT发动头FDCB里装备串行NOR Flash多个寄存器的注意事项

　　咱们好，我是痞子衡，是正派搞技能的痞子。今日痞子衡给咱们介绍的是在FDCB里装备串行NOR Flash多个寄存器的留意事项。

　　关于运用 i.MXRT 发动头 FDCB 来设置 Flash 内部寄存器，痞子衡写过如下两篇文章，在进入本文之前，主张咱们先阅览下这两篇文章，有个开始了解。

• 《在FDCB里设置Flash的Dummy Cycle》
• 《在FDCB里切换Flash形式至QPI/OPI》

　　咱们知道 Flash 内部常常有多个状况/装备寄存器，这些寄存器有些是易失性的，有些对错易失性的。当芯片被指定从 Flash 发动的时分，咱们假如期望 BootROM 能够依据不同运用需求来提早设置好这些 Flash 寄存器，那么在运用程序里就不必再额定装备了（触及 Flash 作业状况改变的装备，假如是 XIP 程序去操作，需求考虑代码重定向问题）。

　　关于运用 FDCB 来装备 Flash 一个寄存器的操作，信任咱们都很了解，在恩智浦 SDK 包里默许 FDCB 发动头里都有成功示例。最近痞子衡搭档测验运用 FDCB 去装备镁光 MT35X 的两个寄存器（地址为 0x000000 的寄存器切至 OPI DDR、地址为 0x000003 的寄存器设 Drive Strength）发现有一个寄存器设置没收效，这是怎么回事？今日咱们来聊一聊：

• Note: 本文适用于 i.MXRT500/600/1010/1020/1040/1050/1060/1160/1170

一、FDCB供给的Flash寄存器装备才能

　　咱们先来看一下 FDCB 结构里跟 Flash 装备相关的成员，痞子衡收拾如下，简略来说，便是有一条 deviceModeSeq 和三条 configCmdSeqs，所以最多能装备 Flash 里 4 个不同指令下对应的寄存器（有些 Flash 里一条装备指令能接连写入多个寄存器，这种状况下就能装备不止 4 个寄存器），这关于大部分运用场景都彻底够用了。

• Note 1: BootROM 履行这四个装备的次序分别是 deviceModeSeq、configCmdSeqs[0]、configCmdSeqs[1]、configCmdSeqs[2]，记住这个次序。
• Note 2: deviceModeSeq 与 configCmdSeq 完结的装备功用几乎没有差异，两者能做的作业是相同的，能够交换。

//!@brief FlexSPI Memory Configuration Block
typedef struct _FlexSPIConfig
{
    // ...

    //!< [0x010-0x010] Device Mode Configure enable flag, 1 - Enable, 0 - Disable
    uint8_t deviceModeCfgEnable;
    //!< [0x011-0x011] Specify the configuration command type:Quad Enable, DPI/QPI/OPI switch, Generic configuration, etc.
    uint8_t deviceModeType; 
    //!< [0x012-0x013] Wait time for all configuration commands, unit: 100us
    uint16_t waitTimeCfgCommands;
    //!< [0x014-0x017] Device mode sequence info, [7:0] - LUT sequence id, [15:8] - LUt sequence number, [31:16] Reserved
    flexspi_lut_seq_t deviceModeSeq;
    //!< [0x018-0x01b] Argument/Parameter for device configuration
    uint32_t deviceModeArg;

    //!< [0x01c-0x01c] Configure command Enable Flag, 1 - Enable, 0 - Disable 
    uint8_t configCmdEnable;
    //!< [0x01d-0x01f] Configure Mode Type, similar as deviceModeTpe 
    uint8_t configModeType[3];
    //!< [0x020-0x02b] Sequence info for Device Configuration command, similar as deviceModeSeq
    flexspi_lut_seq_t configCmdSeqs[3];
    //!< [0x030-0x03b] Arguments/Parameters for device Configuration commands
    uint32_t configCmdArgs[3];

    // ...

    //!< [0x07c-0x07d] Busy offset, valid value: 0-31
    uint16_t busyOffset;
    //!< [0x07e-0x07f] Busy flag polarity, 0 - busy flag is 1 when flash device is busy, 1 - busy flag is 0 when flash device is busy
    uint16_t busyBitPolarity;
    //!< [0x080-0x17f] Lookup table holds Flash command sequences
    uint32_t lookupTable[64];

    // ...

} flexspi_mem_config_t;

　　在 《在FDCB里设置Flash的Dummy Cycle》 一文最终，痞子衡现已共享了 BootROM 解析履行 configCmdSeq 的代码流程，在这个流程里咱们能看到和 deviceModeType/configModeType[]、waitTimeCfgCommands 成员相关的逻辑代码，这儿有必要进一步解释一下。

//!@brief Flash Configuration Command Type
enum
{
    kDeviceConfigCmdType_Generic,    //!< Generic command, for example: configure dummy cycles, drive strength, etc
    kDeviceConfigCmdType_QuadEnable, //!< Quad Enable command
    kDeviceConfigCmdType_Spi2Xpi,    //!< Switch from SPI to DPI/QPI/OPI mode
    kDeviceConfigCmdType_Xpi2Spi,    //!< Switch from DPI/QPI/OPI to SPI mode
    kDeviceConfigCmdType_Spi2NoCmd,  //!< Switch to 0-4-4/0-8-8 mode
    kDeviceConfigCmdType_Reset,      //!< Reset device command
};

　　当 deviceModeType/configModeType 成员被设置为 kDeviceConfigCmdType_Spi2Xpi 时；假如 FDCB 自身被获取时 BootROM 用得是 DPI/QPI/OPI 指令（依据 efuse 装备决议），那么此条 Flash 寄存器装备会被直接疏忽；假如 BootROM 用得是一般一线 SPI 形式读取的 FDCB，那么这个 Flash 寄存器装备依然收效。

　　kDeviceConfigCmdType_Spi2Xpi 等三个跟 Flash 指令形式切换相关的装备类型，望文生义便是告知 BootROM 这三种装备会导致 Flash 作业形式改变，而一旦 Flash 作业形式发生改变，用于判别装备是否完结的 READ_STATUS 指令也随之变得不行用（由于 SPI 形式下与 DPI/QPI/OPI 形式下的指令序列不同），这种状况下就需求凭借 waitTimeCfgCommands 成员来完结软件延时以等候对 Flash 的装备真实收效（假如不等收效就直接进入后续流程，可能会导致发动问题）。

　　kDeviceConfigCmdType_Generic 装备类型，则是用于跟作业形式切换无关的 Flash 寄存器装备，这种状况下 BootROM 能够运用 READ_STATUS 指令来判别对 Flash 寄存器装备是否现已收效，那么就不需求 waitTimeCfgCommands 完结的延时等候（需求查 Flash 数据手册作相应设置，比较费事，并且手册里是给了典型值和最大值，取最大值会导致发动时刻变长，典型值不能保证适用一切状况）。

二、装备Flash多个寄存器留意点

　　Flash 装备寄存器的写入流程一般分三步：一、WRITE_ENABLE 使能写操作；二、详细的 CONFIG_REG 操作；三、READ_STATUS 或许软件延时保证装备已完结。这些指令序列悉数存储在 FDCB 里的 lookupTable[64] 成员里。

　　关于 Flash 寄存器的装备操作，从寄存器特点上来看，分为易失性和非易失性两种，前者的操作一般是当即收效的，后者的操作不是当即收效（Flash 状况寄存器 WIP 位会反映进展）。从指令形式视点来看，分为非形式切换操作（比方设置 Dummy Cycle、Drive Strength）以及切换 SPI 与 DPI/QPI/OPI 形式操作两种，相同前者操作是当即收效，后者操作不是当即收效。

　　现在回到文章最初痞子衡搭档遇到的问题，假如 deviceModeSeq 用于切换至 OPI DDR 形式，configCmdSeqs[0] 用于设 Drive Strength，请问哪一个操作没有收效？这儿就不卖关子了，设 Drive Strength 没有收效，由于第一个装备是切换至 OPI DDR 形式，当 Flash 切换到该形式时，用于第二/三/四个装备的 WRITE_ENABLE 指令变得不行用了（仍是由于 SPI 形式下与 DPI/QPI/OPI 形式下的指令序列不同），当然对应 Flash 寄存器设置就无效了。

　　那么怎么防止这个问题？有一个一了百了的办法，那便是永久用 configCmdSeqs[2] 去做 SPI 与 DPI/QPI/OPI 形式切换操作，这样就不会影响前面三个装备。前面讲了，此刻判别指令形式是否切换完结不能用 READ_STATUS 指令，那么就必定需求 waitTimeCfgCommands 来做软延时，假如延时时刻不行，并且后续 BootROM 履行到验证 IVT 头时形式切换仍未完结，这会导致 IVT 发动头无法正确获取然后导致发动失利。

　　假定 waitTimeCfgCommands 延时设置关于指令形式切换已满足，这样问题就必定处理了吗？其实还不必定，假如此刻已将 deviceModeSeq 用于设 Drive Strength，可是挑选得是写入 Flash 非易失性存储器，这需求保证 waitTimeCfgCommands 延时关于写入非易失性寄存器也满足。翻看 MT35X 的数据手册能够发现，写入非易失性寄存器 cycle time 典型值是 0.2s，最大值是 1s。

　　再比照看看旺宏以及华邦家的 OctalFlash 非易失性寄存器写入时刻，发现旺宏最短(<=60us)，华邦其次(<=15ms)，镁光有点略长了（<=1s）。越短的写入时刻，发动时刻也越短。

　　假如此刻 waitTimeCfgCommands 设置对写入非易失性寄存器来说不行，即没比及 Drive Strength 装备完结就去做切换 OPI 形式操作，这会导致形式切换失利（Flash 在 Busy 期间不能承受任何写入指令），当然也就无法正常发动了。

　　以上介绍得都是比较复杂的 Flash 寄存器装备场景，假如是单纯的易失性寄存器装备操作且不触及形式切换，那么 FDCB 里这四个装备次序也就不重要了，并且也不需求启用 waitTimeCfgCommands，这样也不需求过多考虑了。

　　至此，在FDCB里装备串行NOR Flash多个寄存器的留意事项痞子衡便介绍结束了，掌声在哪里~~~

欢迎订阅

文章会一起发布到我的 博客园主页、CSDN主页、知乎主页、微信大众号 平台上。

微信查找"痞子衡嵌入式"或许扫描下面二维码，就能够在手机上第一时刻看了哦。