有人使用STM32H7系列的ADC模塊，定時器觸發ADC，數據通過DMA傳輸到內存。對某通道連續轉換幾次后求個平均值。他卻發現ADC結果雖沒有什么問題，但一批數據出來后就紋絲不動了。DMA傳輸本來設計成的Circular模式，感覺好像工作在Normal模式，結果顯然有點不合理。

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

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

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

我們使用STM32CubeMx進行配置。重點看下ADC的配置：[注：ADC是16位的]

生成初始化代碼后，添加用戶代碼。我把數組AdcDataViaDMA【】指定在片內RAM2區域。

__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);

然后編譯調試。同樣出現數據紋絲不動的現象。我每次在傳輸完成中斷回調函數里做數據處理。相關處理代碼如下圖所示：

TIMER不停觸發ADC，DMA傳輸也是循環的，按理數據應該動態改變。即使變化不大，也不至于紋絲不動。【除AdcDataViaDMA [5]外，其它均為AD轉換值?！?/p>

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

現在數據的大致流程就是，ADC轉換結果出來后，DMA將數據寫入SRAM，然后CPU讀取SRAM里的數據。因為開啟了D-Cache，當CPU針對SRAM做讀操作時發生讀Allocate，相應內存地址的數據被拷貝一份到Cache里。下次CPU再去相應SRAM地址去讀取時，因D-Cache里已經有了一份有效數據，即發生Cache命中事件，CPU就直接從Cache讀數據，而不讀取SRAM了。

所以，盡管后面時間里ADC因TIMER不停觸發而產生新數據并被DMA傳輸到SRAM，但CPU除了第一次外總是從D-Cache取數據，導致該數據永遠就是第一次讀到的數據而不變。

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

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

然后進行測試，立即可以看到不斷實時變化的數據了。【下圖我隨機截取的幾個結果】

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

另外，除了上面的解決辦法外，還有就是將上面內存數組所在區域做MPU設置，關閉那部分區域的Cacheable屬性。

當這樣配置后，之前那句針對Cache無效化的代碼就不需要了。生成代碼進行測試，結果跟預期一致，數據保持實時動態變化，結果也正常。

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

　　審核編輯：湯梓紅