擦寫Flash時一定不能開啟系統(tǒng)全局中斷嗎？

大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家介紹的是i.MXRT下FlexSPI driver實現(xiàn)Flash編程時對于中斷支持問題。

前段時間有客戶在官方社區(qū)反映 i.MXRT1170 下使用官方 SDK 里 FlexSPI 驅動去擦寫 Flash 時不能很好地支持全局中斷?？蛻繇椖坷镉昧藘蓧K NOR Flash，分別掛在不同的 FlexSPI 上，一塊 Flash 用于存儲 XIP 代碼（FlexSPI1），另一塊 Flash 用于存儲項目資源數(shù)據(jù)（FlexSPI2），顯然這樣的設計原理上是沒有問題的，那為什么使能了中斷會出問題呢？今天痞子衡來分析下這個問題：

Note: 客戶測試的 SDK 版本為 2.12.1，對應的 FlexSPI driver 版本為 2.3.6

一、為什么擦寫Flash時經常需要關全局中斷？

在具體分析客戶問題之前，我們先來聊聊嵌入式應用里應對 NOR Flash 的擦寫為何大部分情況下都是要關閉全局中斷（這里假設執(zhí)行代碼空間與擦寫操作空間在同一個 Flash 上，當然是在不同區(qū)域），這其實跟如下兩個特性有關：

1.1 RWW特性（Read-While-Write）

RWW 特性的意思是在 Flash 執(zhí)行擦寫命令進入 Busy 狀態(tài)期間（Flash 內部狀態(tài)寄存器 WIP 位變狀態(tài) 1）還能否繼續(xù)響應非操作區(qū)域的讀訪問。如果 SR[WIP] = 1 時還能夠支持讀訪問，則該 Flash 支持 RWW，反之則不支持 RWW。

絕大部分 Flash 都是不支持 RWW 特性的，這就是為什么 Flash 擦寫操作代碼本身是需要重定向到 RAM 里去執(zhí)行（尤其是回讀 SR[WIP] 狀態(tài)的代碼）。對于支持 RWW 特性的 Flash，一般是以 Block 為單位，F(xiàn)lash 擦寫操作代碼放在 BlockX 里執(zhí)行，則可以操作 BlockX 以外的其它 Block 區(qū)域，且不需要做代碼重定向。

現(xiàn)在你應該知道對于不支持 RWW 的 Flash 為什么擦寫時需要關閉全局中斷了，因為無法保證中斷響應相關代碼全都重定向到 RAM 里了，所以干脆在 Flash 擦寫期間不響應任何中斷。

1.2 SCLK Stop特性

SCLK Stop 特性的意思是在 Flash 執(zhí)行寫入命令接受主設備傳輸過來的 Page 數(shù)據(jù)期間，如果總線上 SCLK 停止（一般情況是 FlexSPI 這一端的 TXFIFO 為空或者觸發(fā)空條件），則 Flash 能否也暫停接受當前 Page 數(shù)據(jù)直到 SCLK 繼續(xù)輸出從而繼續(xù)處理剩下的 Page 數(shù)據(jù)。

絕大部分 Flash 是不支持 SCLK Stop 特性的，因此在 MCU 端如果傳輸 Page 數(shù)據(jù)，需要一次性連續(xù)傳輸完成，一旦中途被打斷，則兩次不連續(xù)的 Page 數(shù)據(jù)傳輸可能無法得到想要的 Page 寫入結果。這也是為何 Flash 寫入期間我們需要關閉中斷。

二、FlexSPI外設寫操作設計

關于 i.MXRT 上的 FlexSPI 外設基本情況，痞子衡有兩篇舊文 《FlexSPI支持在Flash XIP原理》、《FlexSPI支持AHB方式寫入Flash》，大家先讀一下有個初步了解。這里痞子衡想重點說一下 FlexSPI 關于 IPG 方式寫操作的設計，下圖為 FlexSPI 外設的模塊框圖，痞子衡用綠色線標出了 IPG 方式寫入的通路，這里大家可以看出其中 IP_TX_FIFO 模塊起了重要的數(shù)據(jù)緩沖作用，驅動里往 FLEXSPI->TFDRx 寄存器寫入的 Page 數(shù)據(jù)會先被裝載進 IP_TX_FIFO 里，然后再傳輸出去。

不同 i.MXRT 型號上 IP_TX_FIFO 大小不一樣，目前有三種大小：128/256/1024 Bytes。對于 QuadSPI/OctalSPI NOR Flash 來說，Page 大小一般是 256 Bytes；對于 HyperBus Flash，Page 大小一般是 512 Bytes。所以在 i.MXRT10xx 上 IP_TX_FIFO 是不足以緩沖整個 Page 的，i.MXRT117x 上可以緩沖 QuadSPI/OctalSPI NOR 類型的 Page，i.MXRT118x/5xx/6xx 上則可以緩沖全部 NOR Flash 類型的 Page。對于 Page 數(shù)據(jù)不能全部緩沖的情況，則需要一邊傳輸一邊緩沖。

在具體裝載數(shù)據(jù)進 IP_TX_FIFO 時，主要涉及如下三個 FLEXSPI 寄存器，IP_TX_FIFO 一次只能被填入 watermark level 大小的數(shù)據(jù)，想要把全部 Page 數(shù)據(jù)填進 IP_TX_FIFO，需要分多次裝載。只要 FLEXSPI->INTR[IPTXWE] 標志為 0， 即代表 IP_TX_FIFO 剩余空間大于等于 watermark level，那么就可以繼續(xù)裝載。

FLEXSPI->IPTXFCR[TXWMRK]  -- 設置一次裝載進 IP_TX_FIFO 的數(shù)據(jù)長度（即 watermark level），8 Bytes為單位
FLEXSPI->TFDRx            -- 按 watermark level 長度填入 IP_TX_FIFO 裝載數(shù)據(jù)
FLEXSPI->INTR[IPTXWE]     -- 觸發(fā) IP_TX_FIFO 的一次裝載

三、客戶問題及FlexSPI driver寫操作流程

前面鋪墊了這么多，終于來到客戶遇到的 FlexSPI 驅動對于中斷不支持的問題了。因為客戶使用了兩片 Flash，所以不存在 RWW 限制問題，那剩下的原因就跟 SCLK Stop 特性有關，即 IP_TX_FIFO 并沒有緩沖全部的 Page，導致 Page 傳輸過程被中斷打斷了，然后 IP_TX_FIFO 因為緩沖數(shù)據(jù)全部發(fā)完而使 FlexSPI 模塊進入了 SCLK Stop 狀態(tài)。

我們直接打開 fsl_flexspi.c 驅動文件，找到跟寫操作相關的 FLEXSPI_TransferBlocking() 函數(shù)，在函數(shù)實現(xiàn)里可以發(fā)現(xiàn)，啟動寫傳輸時序的控制位 FLEXSPI->IPCMD[TRG] 是在 IP_TX_FIFO 填充動作 FLEXSPI_WriteBlocking() 函數(shù)之前被開啟的，那這樣的實現(xiàn)確實是不能夠很好地支持中斷的。

四、如何改進FlexSPI driver支持中斷？

知道了原因所在，改起來也很簡單。如果是 QuadSPI/OctalSPI NOR Flash 類型（Page=256 Bytes），在 i.MXRT117x 上，其 IP_TX_FIFO 大小為 256 Bytes，能夠緩沖全部的 Page 大小，則可以先調用 FLEXSPI_WriteBlocking() 裝載全部的 Page 數(shù)據(jù)，然后再開啟 FLEXSPI->IPCMD[TRG] 去觸發(fā)寫傳輸時序，這時候就不怕被中斷打斷了，如下代碼所示。

當然下面代碼只是一個 workaround 式的實現(xiàn)示例，不是一個完整的解決方案，畢竟 FlexSPI 驅動要適配全部 i.MXRT 型號以及全部類型的 NOR Flash，此外還適用 NAND 型 Flash（Page 一般是 2KB），這時候需要根據(jù)情況拆分調用多次 FLEXSPI_WriteBlocking() 函數(shù)（不管怎樣要保證啟動寫傳輸時序前，把 IP_TX_FIFO 先裝滿）。

status_tFLEXSPI_TransferBlocking(FLEXSPI_Type*base,flexspi_transfer_t*xfer)
{
//代碼略去

/*StartTransfer.*/
if((xfer->cmdType==kFLEXSPI_Write)||(xfer->cmdType==kFLEXSPI_Config))
{
result=FLEXSPI_WriteBlocking(base,xfer->data,xfer->dataSize);
base->IPCMD|=FLEXSPI_IPCMD_TRG_MASK;
}
elseif(xfer->cmdType==kFLEXSPI_Read)
{
base->IPCMD|=FLEXSPI_IPCMD_TRG_MASK;
result=FLEXSPI_ReadBlocking(base,xfer->data,xfer->dataSize);
}
else
{
base->IPCMD|=FLEXSPI_IPCMD_TRG_MASK;
}

//代碼略去
}

至此，i.MXRT下FlexSPI driver實現(xiàn)Flash編程時對于中斷支持問題痞子衡便介紹完畢了，掌聲在哪里~~~

審核編輯：湯梓紅