客戶項目中使用的 MCU 型號是 STM32G0B1, 他們反饋在代碼中嘗試擦除并編程 FLASH時, 發現 FLASH 的狀態寄存器顯示編程錯誤(如圖 1 所示). 問題是當前代碼還沒有開始擦除和編程, 怎么就有了編程錯誤標志了呢 ? 如果不將此錯誤標志清除, 后續的編程操作無法繼續.客戶對于每次想要操作 FLASH 之前這個清除動作既感覺多余也感覺別扭, 且還不得不做, 且做了也不知對整個產品的穩定性會有什么樣的影響 ?

圖1.Flash 編程錯誤標志

訪問客戶時, 客戶也曾私下里反饋, 經常在網絡論壇上獲取類似這種問題, 客戶懷疑是不是STM32 本身就存在某些未曾公開的問題 ? 其實, STM32 的所有問題都已公開在勘誤手冊中, 如果客戶的問題在勘誤手冊中沒找到, 那么極有可能是自己代碼哪里出了問題。

問題分析及測試

查看客戶的工程, 由于客戶的工程相當龐大, 各個模塊和任務相互交叉, 一時半刻是很難從如此龐大的工程中找出問題, 更麻煩地是, 客戶的電腦是有加密系統的, 導致在工程內查找任何字符和函數都相當痛苦. 好在是, 問題能夠穩定地復現。

于是盡量精簡客戶的代碼, 將所有不相關的任務,模塊統統移除掉, 并且保持問題能夠重現. 并使其能夠在 ST 官方的 NUCLEO 板上重現. 這樣一來, 就完全可以脫離客戶原來的硬件環境進行測試. 由于客戶的環境非常不利于查找問題, 效率事倍功半. 于是, 將客戶的最小化工程提取出來(與軟件泄密無關), 并拿到辦公室進行測試. 很快就找到了問題所在。

原來客戶的工程中有用到兩個串口, 串口 2 和串口 3, 都是使用的 DMA 模式。客戶不同的軟件人員負責不同的模塊, 最終在整合代碼時, 串口 2 并沒有使用, 所以串口 2 對應的初始化代碼是刪除掉的, 但由于串口 2 和串口 3 的 DMA 中斷是共用一條中斷線, 是相同的中斷入口, 在中斷處理時,串口 2 的 DMA 處理函數和串口 3 的處理函數都會一起處理. 問題就出在串口 2 的 DMA 中斷處理并沒有移除 。如 stm32g0xx_it.c 文件 :

如上圖,DMA 的通道 4~7 以及 DAM2 的通道 1~5 都是共用一個中斷入口的。在這個中斷處理函數內, 串口 2 并沒有使用到, 但其對應處理代碼由于疏忽仍然保留了下來。句柄hdma_usart2_rx, 和 hdma_usart2_tx 內的數據成員很多都是不定內容或為 0. 當代碼運行到函數內部, 如下圖所示出問題的代碼行：

如上面代碼所示, 代碼運行到上圖 866 行代碼 hdma->DmaBaseAddress->IFCR = (DMA_ISR_GIF1 << (hdma->ChannelIndex & 0x1CU));時, 實際上是給錯誤地址 0x0800 4109 賦值了, 此地址是內部 FLASH 地址, 這樣相當于直接寫 FLASH, 肯定會出錯, 這也是為什么FLASH->SR.PGSERR 置位的原因. 我們都知道, 寫內部 FLASH, 必須先擦除, 才可以寫入, 而且寫也是調用對應的 HAL API 函數, 且還需要先寫 key 解鎖 FLASH 等操作, 有一套寫操作流程. 并不是直接用賦值語句, 這樣操作出現問題一點也不奇怪。

當在中斷中將串口 2 的 DMA 對應處理函數移除掉后功能就恢復正常, 這也佐證了結論的準確性。

另外, 客戶反映, 這個最小化工程, 相同的代碼, 使用 IAR 時測試會出錯, 但使用 KEIL 時并沒有出錯. 這個很奇怪. 這就引出的另外一個問題. 相同代碼, 不同編譯器運行結果不一致的問題。于是繼續找原因, 對比 IAR 和 KEIL 的調試情況, 發現當代碼運行到圖 2 中 857 行代碼 if 語句時其判斷結果不相同. IAR 調試環境會進入到 if 語句內容, 從而導致錯誤的給內部 FLASH 地址賦值, 進行導致問題. 而 KEIL 調試環境并沒有進入到 if 語句內部, 因此并沒有觸發問題. 那么為什么if 語句的判斷結果不一樣呢?

為了方便并避免不同編譯器對長語句的執行順序的差異, 將這個 if 長語句拆開:

如上紅色代碼, 用它替換原來的 if 判斷語句. 結果發現 tmp1 在 IAR 和 KEIL 兩個編譯器環境中的值是一樣的, 但是 tmp2 的值卻不一樣, 正是由于 tmp2 值的不一樣, 導致 if 語句的最終判斷結果不同。進一步發現, tmp2 的值主要是由于 flag_it 的值在兩種編譯器環境不一樣所致。

如上 IAR 編譯器環境, flag_it 的值為 0x2000 10f8。

如上 KEIL 編譯器環境, flag_it 的值卻是 0x2000 14F0。

那么 flag_it 的值又是如何來的呢? 從如下代碼:

如上所示, flag_it 的值來自 hdma->DmaBaseAddress->ISR, 原來是 DMA 相關 ISR 寄存器的值, 但實際調試如下:

如上 IAR 調試環境下, 出錯時, hdma->DmaBaseAddress 實際指向的是地址 0, 其成員 ISR為其第一個成員, 實際也就是地址 0 上的數據. 我們都知道, 在默認情況下, MCU 的地址 0 默認是映射到內部 FLASH 的首地址 0x0800 0000 上的, 而此地址一般保存的是棧頂.。也就是說, IAR 編譯環境下, 地址 0 指向棧頂地址 0x2000 10f8。

對應地, 在 KEIL 調試環境下:

如上 KEIL 調試環境, hdma->DmaBaseAddress 同樣地實際指向的是地址 0, 而地址 0 的上對應的數據為棧頂地址: 0x2000 14F0。

也就是說, 在不同的 編譯器 IAR 和 KEIL 環境下, 地址 0 指向棧頂地址是未必相同的, 進而導致兩種編譯環境下運行相同的代碼結果不一樣。

我們知道, 通常棧地址是由編譯器來指定的, 在默認情況下, IAR 和 KEIL 都會將棧放在內存的所有靜態變量之后來分配. 其具體的分配地址這兩個編譯器都會默認按自動填充地方式來. 實際分配的地址具有不確定性, 當然, 我們也可以通過鏈接配置文件(IAR 的.icf 文件, KEIL 的.sct 文件)來將棧地址指定某一固定地址, 但我們通常不會這么做, 且完全沒有必要.

至此，將問題稍作小結。給變量 flag_it 實際賦值棧頂地址, 不同的編譯器環境下, 此棧頂地址的不一致導致變量 flag_it 的值不一致, 進而導致 if 語句的判斷結果不同, 最終導致 IAR 和 KEIL 這兩個編譯器環境下運行相同代碼而結果不一樣的情形。

有時會聽到某某客戶反饋說, 在網絡上看到 STM32 某款 MCU 存在某某問題, 然后問是不是 ST 故意隱瞞 ?

不存在故意隱瞞的說法，芯片終究是要經過終端驗證的。

正常來講， 任何芯片存在應用局限是正常的。對于 ST,一方面會正式地將所有已知 bug或應用局限放入到勘誤手冊中公示, 大家需要注意使用最新版勘誤手冊；另一方面,對于 ST 量產芯片，因本身缺陷導致的問題的概率非常低。事實上，絕大多數問題都來自我們自身的應用，遇到問題若簡單的基于芯片品質來回猜疑非常不利于開發者靜下心來查找問題原因。其實，面對問題時，我們很多人欠缺的并不是多么高深的水平，而是一顆冷靜、自信并富有條理的心。