問題現象

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

問題分析及測試

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

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

上面是一些硬件相關的懷疑點，經測試結果來看，與此問題無關。 看來主要可能還是軟件方面的問題。

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

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

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

后記

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

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