最近在支持一個i.MX RT1170歐美客戶，客戶項目里選用了來自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），這表明硬件修改沒有問題。

const uint32_t customLUT[CUSTOM_LUT_LENGTH] = {
    /* Fast read quad mode - 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),

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

    /* Page Program - quad mode */
    [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》，經過測試，確實復現了客戶的問題。

經過反復測試，定位了問題是這顆Micron32MB的Flash前3/4 區域（0x0 - 0x17FFFFF）是沒問題的，但是在后1/4區域（0x1800000 - 1FFFFFF）均會出現校驗錯誤（J-Flash軟件里看擦寫操作是能進行的，但后面發現其實根本沒有正常擦寫）。

二、Micron 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() 函數。

#define FLASH_QUAD_ENABLE            0x40U

const uint32_t customLUT[CUSTOM_LUT_LENGTH] = {
    /* Enable Quad mode */
    [4 * NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG] =
        FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x01, kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04),
};

int main(void)
{
    // 代碼省略

    /* Enter quad mode. */
    status = flexspi_nor_enable_quad_mode(EXAMPLE_FLEXSPI);
    if (status != kStatus_Success)
    {
        return status;
    }

    // 代碼省略

第二小節介紹里我們知道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，至今似乎真相大白了。

為了驗證這個發現，我們需要將StatusRegister重設為0x00，然后再用J-Flash燒寫一次，這時候校驗失敗問題消失了，一切恢復正常。

一點小體會

回顧這個故事，如果事先不用polling_transfer例程去操作一次Flash，或者即使跑了例程但事先意識到了Micron Flash沒有QE設計而刪除flexspi_nor_enable_quad_mode() 函數，也就無法復現客戶問題了，這也是本次故事里最神奇的地方，我和客戶犯了同樣的失誤，也許這就是緣分？