用戶使用的 MCU 型號是 STM32H750VB。

在客戶的代碼中有多個條件語句，在條件里面的變量數值沒有變化的情況下執行了條件里面的邏輯。有點類似如下 C 語句 :

即變量 A 在明明沒有變化且條件不滿足的情況下, 程序運行時偏偏執行了條件內部的代碼. 很奇怪的現象。一時很難判斷是編譯器的問題還是芯片問題.

了解到客戶的代碼中使用了第三方庫, xx.o 文件, 像這樣的條件有 80 多個, 每次出現問題的具體變量并不是固定哪一個, 但是在大概 10 分鐘內肯定會有其中一個出現執行邏輯問題。隨意動一下代碼問題就不出現, 或者出現的位置發生變化 ; 用 KEIL 編譯器去設置斷點, 想看該變量信息, 也會導致問題不再出現。

一開始查看 errta sheet, 看到以下相關內容 :

即懷疑問題跟 AXI SRAM 相關. 查看客戶的這些變量, 確實是存放在 AXI SRAM 中. 由于任何修改代碼都可能導致問題不再出現, 因此所有嘗試須建立在不修改代碼的基礎上, 不然無法說明問題。

于是讓客戶用 STM32CubeProgrammer 以 hot plug 模式連接 MCU, 按照勘誤手冊中 2.2.9 節所描述的 workaround 方式將 AXI_TARG7_FN_MOD 寄存器的 READ_ISS_OVERRIDE 位通過地址的方式直接修改 :

結果發現并沒什么效果. 于是排除了這種可能性.

一開始也懷疑問題可能跟 Cache 有關, 于是測試下關閉 Cahce 會怎么樣. 通過 KEIL 調試模式下,暫停住 CPU 運行, 然后手動關閉 D-Cache :

結果發現問題消失不見 ! 說明問題肯定跟 Cache 有關.

但客戶的代碼最終肯定是不能關閉 Cache 的, 想到內核中有一個寄存器可以打開全局 Cache 的write throght 模式, 如下編程手冊中的 CACR 寄存器的 FORCEWT 位 :

結果發現, 客戶的代碼本身就已經打開 :

看樣子此模式與此問題無關. 得換個思路.

考慮到問題跟內存數據有關, 代碼又不能動. 但是得想辦法讓內存中數據的位置動動, 看看會有什么效果 ?

通過修改 KEIL 的鏈接配置文件.sct 文件, 將變量隨意動動, 結果發現問題也會消失不見 ! 這說明,數據的地址跟問題絕對有關聯.那么具體是哪些數據呢 ?

為了精確定位到與哪些變量有關, 查看 KEIL 生成的 map 文件, 按地址倒序將每個程序中所用到的.o 的對應變量逐個挪移動 DTCM RAM 中.

為什么要倒序呢? 主要是因為, 假如先挪低地址的變量, 肯定會導致高地址的變量向低地址移動.這好比, 如果先抽掉下面的磚頭, 那么上面的磚頭會自動移動下面去. 假如先抽掉上面的磚頭情況就不一樣了, 下面的磚頭還會保持不動. 這就是為什么先挪移上面的磚頭的意義, 也就是所謂的倒序.

通過這種方式, 最終定位到問題跟 heap_4.o 文件以及用戶使用到的第三方提供的 xx.o 文件中的ZI 數據有關. 只要保持這兩種數據位置不變, 那么問題就可以穩定觸發, 一旦其中任何一個位置有所變動, 問題就消失不見.

現在我們知道規律了, 那么只要固定好這兩種 ZI 數據位置不變的情況下, 再去嘗試修改代碼, 結果發現, 此時修改代碼不再會對結果產生影響! 換句話說, 現在可以自由修改代碼了.

考慮到此問題與 Cache 有關, 于是接下來通過 MPU 設置將 heap_4.o 所在區域的 Cache 功能關閉, 結果發現問題消失.

Heap_4.o 的 ZI 數據是存放在 SRAM2 中的 0x3002 E050 位置.

現在的現象是,Heap_4.o 的 ZI 數據只需要固定在這個位置, 問題就能穩定重現,只不過將其對應的cache 關閉, 問題則消失.

那么此區域默認的 Cache 屬性是怎么樣的呢? 這個在 AN4839 中可以找到其默認屬性:

于是我們通過代碼, 將其 MPU 屬性再次配置其默認屬性:

結果問題可以重現. 這再次說明, cache 屬性對結果有影響.

但是此時還無法對其產生的過程細節進行解釋.

與此同時, 嘗試關閉客戶使用第三方庫 xx.o 文件中的數據 cache, 問題也同樣會消失。這說明, 此問題跟客戶所使用的第三方庫是有關系的, 其數據在 cache 中產生了一致性問題.

于是詢問客戶這個第三方庫是如何來的? 他們回復是一家歐洲公司提供的, 且是以 M4 內核編譯的.

很明顯, 在使用原則上, M4 編譯出來的.o 文件, 就不應該用在 H7 工程上.

以 M4 為內核編譯的.o 文件放到 M7 工程中會產生什么樣的影響? 雖然理論上, M7 內核的指令集是向下兼容的, 但是也需要考慮 M7 內核相關的一些特性, 比如 Cache, memory barrier 等等. 不能完全確保不會出問題, 最保險就是重新以 M7 內核編譯這個.o 文件.

由于這個第三方.o 文件客戶自己也是無法知道其內部是如何實現的, 因此, 問題的具體產生過程是沒辦法進一步調查了. 但定位到這個.o 文件已經是當前能得到的最終結果.

本文最終問題的真相雖有點匪夷所思, 但這正反映了當前國內軟件應用上的混亂情況. 本文所描述的問題根本原因雖然很另類, 但所涉及到的方法卻對開發者有一定的參考意義, 在不能動代碼的情況下, 需要挪動數據的位置, 這就必須對編譯器有一定的了解. 雖也不至于太難, 但對很多開發都來說, 對編譯器的了解未必很深, 因此, 一開始很多人就會卡住。另外, 對 MPU 的了解也是一大門檻. 因此, 特奉上此文, 以供參考.