LAT1151 程序運行在 STM32H750 的外擴 FLASH 上兩小時后死機

問題現(xiàn)象

客戶使用 STM32H750VBT6，通過 QSPI 外擴了一個 4M 的 NOR FLASH，采用memory map 模式。當程序跳轉(zhuǎn)運行到外設(shè) FLASH 后，大約兩個小時后程序死機?？蛻羰褂玫?IDE 是 KEIL，此問題可以固定重現(xiàn)。 在 KEIL 調(diào)試模式下重現(xiàn)問題時，通過多次觀察發(fā)現(xiàn)，程序死的位置總體上會停在兩個位置，并不是同一個位置。一個是 TIM15函數(shù)的入口；另一個是進入中斷函數(shù)后的一個賦值語句。

問題分析及測試

通過拜訪客戶，觀察到死機位置處于即將進入 TIM15 中斷入口處，但還未進入之時。查看客戶的原理圖，發(fā)現(xiàn)兩個 VCAP 并未從外部相連，于是要求客戶直接從外部將此兩個引腳飛線短連。 但是，后來經(jīng)測試問題仍然重現(xiàn)。

又觀察到 PC13 連接為 GPIO 輸出引腳，用于驅(qū)動一外部組件。 考慮到備份域相關(guān)的一些引腳其驅(qū)動能力相對弱一些，于是讓客戶將 PC13 引腳斷開后再測試，結(jié)果問題仍然重現(xiàn)。

上面是一些硬件相關(guān)的懷疑點，經(jīng)測試結(jié)果來看，與此問題無關(guān)。 看來主要可能還是軟件方面的問題。

在軟件上確定客戶已經(jīng)打開了 IO 補償功能，但 IO 速度設(shè)置的是 HIGH，于是讓客戶修改成 “VERY_HIGH”，經(jīng)測試問題仍然存在。

由于之前發(fā)生過一個從低功耗喚醒后死機的問題，是與 Cache 相關(guān)的問題，于是要測試下將 CACHE 關(guān)閉的情況。 這次經(jīng)測試客戶反饋問題沒現(xiàn)重現(xiàn) ! 但客戶同時也反饋,之前的代碼也存在稍微修改一處代碼，問題就不再重現(xiàn)的現(xiàn)象，沒有找到具體規(guī)律。 這次代碼修改也沒排除這種可能性。

為了讓關(guān)閉 Cache 的方法更具效力，于是讓客戶在調(diào)試模式下通過手動關(guān)閉 CACHE的方式，代碼仍然保持為原先可以重現(xiàn)問題的代碼。

后記

有些人可能會問，NOR FLASH 的最后一個字節(jié) CPU 真的會去訪問嗎 ? 客戶的程序占滿了整個 FLASH 空間了嗎 ? 若那個地址沒有代碼那還會不會有這個問題。

其實勘誤手冊 2.4.4 節(jié)也提到了，不管 FSIZE 定義的空間最后的一個字節(jié)內(nèi)容是什么，均會有此問題。 那么 CPU 為什么會去訪問此地址呢 ? 其實這是 M7 內(nèi)核的指令預(yù)取和分支預(yù)測的特性導(dǎo)致的。