有人使用STM32H7系列的ADC模塊，定時器觸發(fā)ADC，數(shù)據(jù)通過DMA傳輸?shù)絻?nèi)存。對某通道連續(xù)轉(zhuǎn)換幾次后求個平均值。他卻發(fā)現(xiàn)ADC結(jié)果雖沒有什么問題，但一批數(shù)據(jù)出來后就紋絲不動了。DMA傳輸本來設(shè)計成的Circular模式，感覺好像工作在Normal模式，結(jié)果顯然有點(diǎn)不合理。

鑒于這個現(xiàn)象和所用芯片，估計是因?yàn)镃ache使用方面的原因,客戶也的確使能了Cache。具體怎么回事呢？我們一起來看看。

我這邊使用H743Nucleo板和ST免費(fèi)的STM32CubeIDE。STM32H743片內(nèi)有個Vrefint信號，電壓一般在1.2v左右，用它做ADC的輸入信號來測試。用LPTIM觸發(fā)ADC轉(zhuǎn)換，每讀到5個數(shù)據(jù)就求個平均值。

我這里定義了一個6字大小的數(shù)組，uint32_t ?AdcDataViaDMA [6];前5個位置放實(shí)時ADC數(shù)據(jù)，第6個位置即AdcDataViaDMA [5]存放換算后的最終Vrefint電壓平均值，單位是mv。

我們使用STM32CubeMx進(jìn)行配置。重點(diǎn)看下ADC的配置：[注：ADC是16位的]

生成初始化代碼后，添加用戶代碼。我把數(shù)組AdcDataViaDMA【】指定在片內(nèi)RAM2區(qū)域。

__attribute__((section(".AdcDataViaDMA")))? ?uint32_t AdcDataViaDMA [6];

HAL_ADCEx_Calibration_Start(&hadc3, ADC_CALIB_OFFSET, ADC_SINGLE_ENDED );

HAL_ADC_Start_DMA(&hadc3,(uint32_t*)&AdcDataViaDMA [0], 5);

HAL_LPTIM_PWM_Start(&hlptim2, Period,?Pulse);

然后編譯調(diào)試。同樣出現(xiàn)數(shù)據(jù)紋絲不動的現(xiàn)象。我每次在傳輸完成中斷回調(diào)函數(shù)里做數(shù)據(jù)處理。相關(guān)處理代碼如下圖所示：

TIMER不停觸發(fā)ADC，DMA傳輸也是循環(huán)的，按理數(shù)據(jù)應(yīng)該動態(tài)改變。即使變化不大，也不至于紋絲不動。【除AdcDataViaDMA [5]外，其它均為AD轉(zhuǎn)換值。】

那是什么原因呢？目前我們是開啟了Cache的。

現(xiàn)在數(shù)據(jù)的大致流程就是，ADC轉(zhuǎn)換結(jié)果出來后，DMA將數(shù)據(jù)寫入SRAM，然后CPU讀取SRAM里的數(shù)據(jù)。因?yàn)殚_啟了D-Cache，當(dāng)CPU針對SRAM做讀操作時發(fā)生讀Allocate，相應(yīng)內(nèi)存地址的數(shù)據(jù)被拷貝一份到Cache里。下次CPU再去相應(yīng)SRAM地址去讀取時，因D-Cache里已經(jīng)有了一份有效數(shù)據(jù)，即發(fā)生Cache命中事件，CPU就直接從Cache讀數(shù)據(jù)，而不讀取SRAM了。

所以，盡管后面時間里ADC因TIMER不停觸發(fā)而產(chǎn)生新數(shù)據(jù)并被DMA傳輸?shù)絊RAM，但CPU除了第一次外總是從D-Cache取數(shù)據(jù)，導(dǎo)致該數(shù)據(jù)永遠(yuǎn)就是第一次讀到的數(shù)據(jù)而不變。

既然這樣，我們可以在CPU每次針對SRAM做了讀操作后，對D-Cache相應(yīng)內(nèi)容做無效處理，迫使CPU每次要取數(shù)據(jù)時因Cache Miss而發(fā)生讀Allocate操作并更新Cache數(shù)據(jù)，進(jìn)而保證CPU讀到跟內(nèi)存SRAM里一致的Cache數(shù)據(jù)。

我在DMA完成中斷回調(diào)函數(shù)里加上一句針對D-Cache作無效操作的代碼。如下圖紅線標(biāo)注的代碼。

然后進(jìn)行測試，立即可以看到不斷實(shí)時變化的數(shù)據(jù)了。【下圖我隨機(jī)截取的幾個結(jié)果】

不過，請注意這里針對D-Cache相應(yīng)地址做了無效化處理的代碼要放在最前面。你可以將該句試著放在對AdcDataViaDMA [5]賦0語句的后面驗(yàn)證下，看看會有什么現(xiàn)象，要看細(xì)致點(diǎn)，不然發(fā)現(xiàn)不了問題。順便提醒，目前所用SRAM區(qū)域在沒有做MPU配置的情況下，默認(rèn)為write back加write allocate Cache屬性，我在前面貼圖時已經(jīng)圈出來了。有興趣的話，可以基于上述代碼自行進(jìn)一步探究下，此處就不延伸了。

另外，除了上面的解決辦法外，還有就是將上面內(nèi)存數(shù)組所在區(qū)域做MPU設(shè)置，關(guān)閉那部分區(qū)域的Cacheable屬性。

當(dāng)這樣配置后，之前那句針對Cache無效化的代碼就不需要了。生成代碼進(jìn)行測試，結(jié)果跟預(yù)期一致，數(shù)據(jù)保持實(shí)時動態(tài)變化，結(jié)果也正常。

上面主要就開啟D-Cache后，發(fā)生了主設(shè)備數(shù)據(jù)讀取不一致的問題給出了些解決辦法及思路，同時也算是給出些應(yīng)用提醒，以后碰到類似問題時可以參考。當(dāng)然，有人或許會說，完全不開啟芯片的D-Cache功能也可以解決問題。誠然，但我們需要綜合考慮開發(fā)便利性和芯片的性能發(fā)揮，盡量就問題做些針對性的處理以充分發(fā)揮芯片性能。

　　審核編輯：湯梓紅