关于Segger J-Flash在Micron Flash固定区域下载校验失败的故事

痞子衡最近在支持一个 i.MXRT1170 欧美客户，客户项目里选用了来自 Micron 的四线 NOR Flash - MT25QL256ABA8E12-0AAT 作为启动设备，一般读写倒是没有问题，但是在 Segger J-Flash 下烧写遇到了特定区域内校验失败的问题。

从痞子衡过往丰富的 Flash 支持经验来看，亚太区客户一般选用 ISSI(芯成)/Winbond(华邦)/MXIC(旺宏)/GigaDevices(兆易创新) 的 Flash 比较多，痞子衡对这些厂商 Flash 可以说是门清了。这个欧美客户选用的是痞子衡不太熟的 Micron(镁光) 产品，借着这个问题，痞子衡带大家一起稍微深入地了解下 Micron Flash 产品：

一、引出客户问题

首先是复现下客户的问题，痞子衡找了块 MIMXRT1170-EVK 开发板，将板载其他厂商 Flash 换成这颗 MT25QL256ABA8E12-0AAT（因为是 T-PBGA24 封装，所以需要放到原来的 OctalFlash 位置 - U21），然后将 SDK_2.11.1_MIMXRT1170-EVKoardsevkmimxrt1170driver_examplesflexspi orpolling_transfer 例程稍作适配性修改，主要是将 customLUT 里的命令表按 Micron 数据手册命令表做调整（全用了四字节地址命令），然后跑了一下例程发现基本的 Flash 读写擦操作没有问题（默认操作的是 0x14000 处的 Sector），这表明硬件修改没有问题。

constuint32_tcustomLUT[CUSTOM_LUT_LENGTH]={
/*Fastreadquadmode-SDR*/
[4*NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR,kFLEXSPI_1PAD,0xEC,kFLEXSPI_Command_RADDR_SDR,kFLEXSPI_4PAD,0x20),
[4*NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD+1]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_DUMMY_SDR,kFLEXSPI_4PAD,0x0a,kFLEXSPI_Command_READ_SDR,kFLEXSPI_4PAD,0x04),

/*EraseSector*/
[4*NOR_CMD_LUT_SEQ_IDX_ERASESECTOR]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR,kFLEXSPI_1PAD,0xDC,kFLEXSPI_Command_RADDR_SDR,kFLEXSPI_1PAD,0x20),

/*PageProgram-quadmode*/
[4*NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_QUAD]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR,kFLEXSPI_1PAD,0x34,kFLEXSPI_Command_RADDR_SDR,kFLEXSPI_1PAD,0x20),
[4*NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_QUAD+1]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_WRITE_SDR,kFLEXSPI_4PAD,0x04,kFLEXSPI_Command_STOP,kFLEXSPI_1PAD,0x00),
};

接下来就是按客户操作流程来复现 Segger J-Flash 烧写校验失败问题，客户其实是尝试烧写全部 32MB 数据来查看 J-Flash 及其配套下载算法能否适用这颗 Flash，这里痞子衡就用 《超级下载算法RT-UFL v1.0》，经过测试，确实复现了客户的问题。

经过反复测试，定位了问题是这颗 Micron 32MB 的 Flash 前 3/4 区域（0x0 - 0x17FFFFF）是没问题的，但是在后 1/4 区域（0x1800000 - 1FFFFFF）均会出现校验错误（J-Flash软件里看擦写操作是能进行的，但后面发现其实根本没有正常擦写）。

二、Micron QuadSPI NOR Flash有什么不同？

在分析客户问题之前，我们先来简单认识一下这颗 Micron NOR Flash，痞子衡浏览了 Micron 的官网以及这颗 Flash 的数据手册，发现它确实跟其他厂商的 NOR Flash 设计有点区别。

首先是 Flash 容量，其他厂商一般都是能够提供从 512Kb 到 2Gb 全范围的 Flash 产品，但是 Micron 串行 NOR Flash 最小容量就是 128Mb，果然是国际 Memory 大厂，设计就是豪横。但是从 Flash 作为 XIP 启动设备角度而言，128Mb 其实挺多的，普通的嵌入式项目没有这么大的代码存储需求。

其次是 NOR Flash 里的高频问题 《QE bit 设计》，一般 Flash 的 IO2/3 引脚复用功能都是通过内部状态寄存器里的 QE 位来控制，QE 关闭则 IO2/3 是 RESET#/HOLD#/WP# 功能：如果 QE 开启则 IO2/3 用于数据传输（这种情况下才可以用 Quad I/O 相关命令）。

然而 Micron Flash 根本就没有 QE 位控制，IO2/3 功能主要靠当前命令类型来决定：如果是 Single SPI 或者 Dual I/O SPI 命令，则 IO2/3 是 RESET#/HOLD#/WP# 功能；如果是 Quad I/O SPI 命令，则 IO2/3 用于传输数据。

其它设计上的区别就不再详细展开了，等用到具体功能查看数据手册再去了解对比。

三、找到问题原因

现在来分析客户问题，Flash 后 1/4 区域在 J-Flash 下校验错误，那我们先修改 polling_transfer 例程去操作 0x1800000 之后的 Sector，发现确实跑不过。如果不是 Flash 介质问题，也不是读写擦命令问题，那只能有一种解释，那就是 Flash 里这个区域被保护了，Flash 里是有非易失寄存器可以设置软件保护的，但是默认应该是全部区域不保护，而第一小节里我们先跑了 polling_transfer 例程验证 Flash 读写，那大概率这个例程里有修改 Flash 内部寄存器操作，经过排查痞子衡定位到了 flexspi_nor_enable_quad_mode() 函数。

#defineFLASH_QUAD_ENABLE0x40U

constuint32_tcustomLUT[CUSTOM_LUT_LENGTH]={
/*EnableQuadmode*/
[4*NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG]=
FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR,kFLEXSPI_1PAD,0x01,kFLEXSPI_Command_WRITE_SDR,kFLEXSPI_1PAD,0x04),
};

intmain(void)
{
//代码省略

/*Enterquadmode.*/
status=flexspi_nor_enable_quad_mode(EXAMPLE_FLEXSPI);
if(status!=kStatus_Success)
{
returnstatus;
}

//代码省略
}

第二小节介绍里我们知道 Micron Flash 是没有 QE 位设计的，因此 flexspi_nor_enable_quad_mode() 函数在这里是多余的，这个函数是将 0x40 写入到了命令标号为 0x01 的 Status Register（这个操作适用于 ISSI Flash），我们在数据手册里找到这个寄存器定义，发现被置位的 bit 6 是块保护控制位 BP[3:0] 里的最高位，并且 BP[3:0] 设置是非易失性的（断电不丢失）。

再进一步往下找 BP[3:0] 设置与 Flash 空间对应关系，发现 4'b1000 设置就是保护后 1/4 区域里的所有 block，至今似乎真相大白了。为了验证发现，我们需要将 Status Register 重设为 0x00，然后再用 J-Flash 烧写一次，这时候校验失败问题消失了，一切恢复正常。

回顾这个故事，如果痞子衡事先不用 polling_transfer 例程去操作一次 Flash，或者即使跑了例程但事先意识到了 Micron Flash 没有 QE 设计而删除 flexspi_nor_enable_quad_mode() 函数，也就无法复现客户问题了，这也是本次故事里最神奇的地方，客户和痞子衡犯了同样的失误，也许这就是缘分？

审核编辑：刘清