關(guān)鍵字：Octo-SPI, Quad Serial Flash

目錄預(yù)覽

1 引言2 問題分析3 問題解決

4 小結(jié)

1. 引言

客戶反應(yīng)STM32L4R9 同QSPI Flash 通訊，測出來的讀取速率為10MB/s， 和理論值相差較大。

2.問題分析

按照客戶的時鐘配置和STM32L4R9 的數(shù)據(jù)手冊中的數(shù)據(jù)，OSPI 讀數(shù)速率為10MB/s肯定存在問題。同時我們也可以在AN4760 應(yīng)用手冊中看到如下說明：

在客戶系統(tǒng)中，IO0~IO3的4線通訊模式下信號波形如下圖，可以看出每經(jīng)過8 個CLK周期就有很長一段時間的延時。如果提高CPU的主頻，這個延時會縮短，但客戶測到最短的延時也有200ns，并且一直存在：

3.問題解決

從客戶測試波形上看，由于是4條數(shù)據(jù)線，因此8個clock正好是4bytes，也就是32bits數(shù)據(jù)。懷疑STM32L4R9 QSPI在DMA通訊中，讀到一個word（32bits）數(shù)據(jù)后需要在內(nèi)部做一定的數(shù)據(jù)處理，造成時間延遲。

分析代碼發(fā)現(xiàn)，DMA設(shè)置的是byte傳輸模式，如下面代碼：

#define BUFFERSIZE (COUNTOF(aTxBuffer) - 1)

hdma.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;

hdma.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;

STM32L4R9是Cortex-M4 內(nèi)核，系統(tǒng)總線是32bits的，懷疑是在32bit總線上傳輸byte數(shù)據(jù)會降低效率，造成延遲，于是修改代碼如下：

示例代碼在下面路徑，需要使用附件中的main.c文件替換掉下面文件中的main.c：

…STM32Cube_FW_L4_VxxProjects32L4R9IDISCOVERYExamplesOSPIOSPI_NOR_ReadWrite_DMAEWARM

另外程序中做如下改動：

#define BUFFERSIZE 1024 // (COUNTOF(aTxBuffer) - 1)

hdma.Init.PeriphDataAlignment = DMA_PDATAALIGN_WORD;

hdma.Init.MemDataAlignment = DMA_PDATAALIGN_WORD;

配置時請留意OSPIHandle.Init.FifoThreshold = 4; //也需要4的倍數(shù)。

修改代碼后進(jìn)行測試，代碼讀 4096bytes的圖像（1026 words），發(fā)現(xiàn)每個word數(shù)據(jù)中間的延遲已經(jīng)沒有了。之前速度提不上去的問題是DMA byte設(shè)置引起，因為STM32L4R9是32bits系統(tǒng)，使用8bits傳輸會降低效率，需要改為DMA 32bits配置就OK了。圖形數(shù)據(jù)傳輸?shù)目傋止?jié)數(shù)也要設(shè)置為4的倍數(shù)，不足的需要補齊。

DMA改為word設(shè)置后數(shù)據(jù)傳輸時沒有延遲

4. 小結(jié)

對32位系統(tǒng)來說，使用byte的數(shù)據(jù)傳輸在一些情況下會降低效率，建議對32bits系統(tǒng)使用32bits的數(shù)據(jù)傳輸方式。

完整內(nèi)容請點擊“閱讀原文”下載原文檔。

長按掃碼關(guān)注公眾號

更多資訊，盡在STM32

▽點擊“閱讀原文”，可下載原文檔