應(yīng)用筆記 | STM32L4R9 的QuadSPI Flash 通訊速率不理想

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

目錄預(yù)覽

4 小結(jié)

1. 引言

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

2.問(wèn)題分析

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

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

3.問(wèn)題解決

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

分析代碼發(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ù)會(huì)降低效率，造成延遲，于是修改代碼如下：

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

…STM32Cube_FW_L4_VxxProjects32L4R9IDISCOVERYExamplesOSPIOSPI_NOR_ReadWrite_DMAEWARM

另外程序中做如下改動(dòng)：

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

hdma.Init.PeriphDataAlignment = DMA_PDATAALIGN_WORD;

hdma.Init.MemDataAlignment = DMA_PDATAALIGN_WORD;

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

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

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

4. 小結(jié)

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

長(zhǎng)按掃碼關(guān)注公眾號(hào)

更多資訊，盡在STM32

▽點(diǎn)擊“閱讀原文”，可下載原文檔