實(shí)戰(zhàn)經(jīng)驗(yàn) | 一個(gè) Flash 編程錯(cuò)誤標(biāo)志的探析

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

圖1.Flash 編程錯(cuò)誤標(biāo)志

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

問題分析及測(cè)試

查看客戶的工程, 由于客戶的工程相當(dāng)龐大, 各個(gè)模塊和任務(wù)相互交叉, 一時(shí)半刻是很難從如此龐大的工程中找出問題, 更麻煩地是, 客戶的電腦是有加密系統(tǒng)的, 導(dǎo)致在工程內(nèi)查找任何字符和函數(shù)都相當(dāng)痛苦. 好在是, 問題能夠穩(wěn)定地復(fù)現(xiàn)。

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

原來客戶的工程中有用到兩個(gè)串口, 串口 2 和串口 3, 都是使用的 DMA 模式?？蛻舨煌能浖藛T負(fù)責(zé)不同的模塊, 最終在整合代碼時(shí), 串口 2 并沒有使用, 所以串口 2 對(duì)應(yīng)的初始化代碼是刪除掉的, 但由于串口 2 和串口 3 的 DMA 中斷是共用一條中斷線, 是相同的中斷入口, 在中斷處理時(shí),串口 2 的 DMA 處理函數(shù)和串口 3 的處理函數(shù)都會(huì)一起處理. 問題就出在串口 2 的 DMA 中斷處理并沒有移除 。如 stm32g0xx_it.c 文件 :

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

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

當(dāng)在中斷中將串口 2 的 DMA 對(duì)應(yīng)處理函數(shù)移除掉后功能就恢復(fù)正常, 這也佐證了結(jié)論的準(zhǔn)確性。

另外, 客戶反映, 這個(gè)最小化工程, 相同的代碼, 使用 IAR 時(shí)測(cè)試會(huì)出錯(cuò), 但使用 KEIL 時(shí)并沒有出錯(cuò). 這個(gè)很奇怪. 這就引出的另外一個(gè)問題. 相同代碼, 不同編譯器運(yùn)行結(jié)果不一致的問題。于是繼續(xù)找原因, 對(duì)比 IAR 和 KEIL 的調(diào)試情況, 發(fā)現(xiàn)當(dāng)代碼運(yùn)行到圖 2 中 857 行代碼 if 語(yǔ)句時(shí)其判斷結(jié)果不相同. IAR 調(diào)試環(huán)境會(huì)進(jìn)入到 if 語(yǔ)句內(nèi)容, 從而導(dǎo)致錯(cuò)誤的給內(nèi)部 FLASH 地址賦值, 進(jìn)行導(dǎo)致問題. 而 KEIL 調(diào)試環(huán)境并沒有進(jìn)入到 if 語(yǔ)句內(nèi)部, 因此并沒有觸發(fā)問題. 那么為什么if 語(yǔ)句的判斷結(jié)果不一樣呢?

為了方便并避免不同編譯器對(duì)長(zhǎng)語(yǔ)句的執(zhí)行順序的差異, 將這個(gè) if 長(zhǎng)語(yǔ)句拆開:

如上紅色代碼, 用它替換原來的 if 判斷語(yǔ)句. 結(jié)果發(fā)現(xiàn) tmp1 在 IAR 和 KEIL 兩個(gè)編譯器環(huán)境中的值是一樣的, 但是 tmp2 的值卻不一樣, 正是由于 tmp2 值的不一樣, 導(dǎo)致 if 語(yǔ)句的最終判斷結(jié)果不同。進(jìn)一步發(fā)現(xiàn), tmp2 的值主要是由于 flag_it 的值在兩種編譯器環(huán)境不一樣所致。

如上 IAR 編譯器環(huán)境, flag_it 的值為 0x2000 10f8。

如上 KEIL 編譯器環(huán)境, flag_it 的值卻是 0x2000 14F0。

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

如上所示, flag_it 的值來自 hdma->DmaBaseAddress->ISR, 原來是 DMA 相關(guān) ISR 寄存器的值, 但實(shí)際調(diào)試如下:

如上 IAR 調(diào)試環(huán)境下, 出錯(cuò)時(shí), hdma->DmaBaseAddress 實(shí)際指向的是地址 0, 其成員 ISR為其第一個(gè)成員, 實(shí)際也就是地址 0 上的數(shù)據(jù). 我們都知道, 在默認(rèn)情況下, MCU 的地址 0 默認(rèn)是映射到內(nèi)部 FLASH 的首地址 0x0800 0000 上的, 而此地址一般保存的是棧頂.。也就是說, IAR 編譯環(huán)境下, 地址 0 指向棧頂?shù)刂?0x2000 10f8。

對(duì)應(yīng)地, 在 KEIL 調(diào)試環(huán)境下:

如上 KEIL 調(diào)試環(huán)境, hdma->DmaBaseAddress 同樣地實(shí)際指向的是地址 0, 而地址 0 的上對(duì)應(yīng)的數(shù)據(jù)為棧頂?shù)刂? 0x2000 14F0。

也就是說, 在不同的 編譯器 IAR 和 KEIL 環(huán)境下, 地址 0 指向棧頂?shù)刂肥俏幢叵嗤? 進(jìn)而導(dǎo)致兩種編譯環(huán)境下運(yùn)行相同的代碼結(jié)果不一樣。

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

至此，將問題稍作小結(jié)。給變量 flag_it 實(shí)際賦值棧頂?shù)刂? 不同的編譯器環(huán)境下, 此棧頂?shù)刂返牟灰恢聦?dǎo)致變量 flag_it 的值不一致, 進(jìn)而導(dǎo)致 if 語(yǔ)句的判斷結(jié)果不同, 最終導(dǎo)致 IAR 和 KEIL 這兩個(gè)編譯器環(huán)境下運(yùn)行相同代碼而結(jié)果不一樣的情形。

有時(shí)會(huì)聽到某某客戶反饋說, 在網(wǎng)絡(luò)上看到 STM32 某款 MCU 存在某某問題, 然后問是不是 ST 故意隱瞞 ?

不存在故意隱瞞的說法，芯片終究是要經(jīng)過終端驗(yàn)證的。

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