用戶使用的 MCU 型號(hào)是 STM32H750VB。

在客戶的代碼中有多個(gè)條件語(yǔ)句，在條件里面的變量數(shù)值沒(méi)有變化的情況下執(zhí)行了條件里面的邏輯。有點(diǎn)類似如下 C 語(yǔ)句 :

即變量 A 在明明沒(méi)有變化且條件不滿足的情況下, 程序運(yùn)行時(shí)偏偏執(zhí)行了條件內(nèi)部的代碼. 很奇怪的現(xiàn)象。一時(shí)很難判斷是編譯器的問(wèn)題還是芯片問(wèn)題.

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

一開(kāi)始查看 errta sheet, 看到以下相關(guān)內(nèi)容 :

即懷疑問(wèn)題跟 AXI SRAM 相關(guān). 查看客戶的這些變量, 確實(shí)是存放在 AXI SRAM 中. 由于任何修改代碼都可能導(dǎo)致問(wèn)題不再出現(xiàn), 因此所有嘗試須建立在不修改代碼的基礎(chǔ)上, 不然無(wú)法說(shuō)明問(wèn)題。

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

結(jié)果發(fā)現(xiàn)并沒(méi)什么效果. 于是排除了這種可能性.

一開(kāi)始也懷疑問(wèn)題可能跟 Cache 有關(guān), 于是測(cè)試下關(guān)閉 Cahce 會(huì)怎么樣. 通過(guò) KEIL 調(diào)試模式下,暫停住 CPU 運(yùn)行, 然后手動(dòng)關(guān)閉 D-Cache :

結(jié)果發(fā)現(xiàn)問(wèn)題消失不見(jiàn) ! 說(shuō)明問(wèn)題肯定跟 Cache 有關(guān).

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

結(jié)果發(fā)現(xiàn), 客戶的代碼本身就已經(jīng)打開(kāi) :

看樣子此模式與此問(wèn)題無(wú)關(guān). 得換個(gè)思路.

考慮到問(wèn)題跟內(nèi)存數(shù)據(jù)有關(guān), 代碼又不能動(dòng). 但是得想辦法讓內(nèi)存中數(shù)據(jù)的位置動(dòng)動(dòng), 看看會(huì)有什么效果 ?

通過(guò)修改 KEIL 的鏈接配置文件.sct 文件, 將變量隨意動(dòng)動(dòng), 結(jié)果發(fā)現(xiàn)問(wèn)題也會(huì)消失不見(jiàn) ! 這說(shuō)明,數(shù)據(jù)的地址跟問(wèn)題絕對(duì)有關(guān)聯(lián).那么具體是哪些數(shù)據(jù)呢 ?

為了精確定位到與哪些變量有關(guān), 查看 KEIL 生成的 map 文件, 按地址倒序?qū)⒚總€(gè)程序中所用到的.o 的對(duì)應(yīng)變量逐個(gè)挪移動(dòng) DTCM RAM 中.

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

通過(guò)這種方式, 最終定位到問(wèn)題跟 heap_4.o 文件以及用戶使用到的第三方提供的 xx.o 文件中的ZI 數(shù)據(jù)有關(guān). 只要保持這兩種數(shù)據(jù)位置不變, 那么問(wèn)題就可以穩(wěn)定觸發(fā), 一旦其中任何一個(gè)位置有所變動(dòng), 問(wèn)題就消失不見(jiàn).

現(xiàn)在我們知道規(guī)律了, 那么只要固定好這兩種 ZI 數(shù)據(jù)位置不變的情況下, 再去嘗試修改代碼, 結(jié)果發(fā)現(xiàn), 此時(shí)修改代碼不再會(huì)對(duì)結(jié)果產(chǎn)生影響! 換句話說(shuō), 現(xiàn)在可以自由修改代碼了.

考慮到此問(wèn)題與 Cache 有關(guān), 于是接下來(lái)通過(guò) MPU 設(shè)置將 heap_4.o 所在區(qū)域的 Cache 功能關(guān)閉, 結(jié)果發(fā)現(xiàn)問(wèn)題消失.

Heap_4.o 的 ZI 數(shù)據(jù)是存放在 SRAM2 中的 0x3002 E050 位置.

現(xiàn)在的現(xiàn)象是,Heap_4.o 的 ZI 數(shù)據(jù)只需要固定在這個(gè)位置, 問(wèn)題就能穩(wěn)定重現(xiàn),只不過(guò)將其對(duì)應(yīng)的cache 關(guān)閉, 問(wèn)題則消失.

那么此區(qū)域默認(rèn)的 Cache 屬性是怎么樣的呢? 這個(gè)在 AN4839 中可以找到其默認(rèn)屬性:

于是我們通過(guò)代碼, 將其 MPU 屬性再次配置其默認(rèn)屬性:

結(jié)果問(wèn)題可以重現(xiàn). 這再次說(shuō)明, cache 屬性對(duì)結(jié)果有影響.

但是此時(shí)還無(wú)法對(duì)其產(chǎn)生的過(guò)程細(xì)節(jié)進(jìn)行解釋.

與此同時(shí), 嘗試關(guān)閉客戶使用第三方庫(kù) xx.o 文件中的數(shù)據(jù) cache, 問(wèn)題也同樣會(huì)消失。這說(shuō)明, 此問(wèn)題跟客戶所使用的第三方庫(kù)是有關(guān)系的, 其數(shù)據(jù)在 cache 中產(chǎn)生了一致性問(wèn)題.

于是詢問(wèn)客戶這個(gè)第三方庫(kù)是如何來(lái)的? 他們回復(fù)是一家歐洲公司提供的, 且是以 M4 內(nèi)核編譯的.

很明顯, 在使用原則上, M4 編譯出來(lái)的.o 文件, 就不應(yīng)該用在 H7 工程上.

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

由于這個(gè)第三方.o 文件客戶自己也是無(wú)法知道其內(nèi)部是如何實(shí)現(xiàn)的, 因此, 問(wèn)題的具體產(chǎn)生過(guò)程是沒(méi)辦法進(jìn)一步調(diào)查了. 但定位到這個(gè).o 文件已經(jīng)是當(dāng)前能得到的最終結(jié)果.

本文最終問(wèn)題的真相雖有點(diǎn)匪夷所思, 但這正反映了當(dāng)前國(guó)內(nèi)軟件應(yīng)用上的混亂情況. 本文所描述的問(wèn)題根本原因雖然很另類, 但所涉及到的方法卻對(duì)開(kāi)發(fā)者有一定的參考意義, 在不能動(dòng)代碼的情況下, 需要挪動(dòng)數(shù)據(jù)的位置, 這就必須對(duì)編譯器有一定的了解. 雖也不至于太難, 但對(duì)很多開(kāi)發(fā)都來(lái)說(shuō), 對(duì)編譯器的了解未必很深, 因此, 一開(kāi)始很多人就會(huì)卡住。另外, 對(duì) MPU 的了解也是一大門(mén)檻. 因此, 特奉上此文, 以供參考.