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

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

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

問(wèn)題分析及測(cè)試

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

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

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

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

如上面代碼所示, 代碼運(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)問(wèn)題一點(diǎn)也不奇怪。

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

另外, 客戶反映, 這個(gè)最小化工程, 相同的代碼, 使用 IAR 時(shí)測(cè)試會(huì)出錯(cuò), 但使用 KEIL 時(shí)并沒(méi)有出錯(cuò). 這個(gè)很奇怪. 這就引出的另外一個(gè)問(wèn)題. 相同代碼, 不同編譯器運(yùn)行結(jié)果不一致的問(wèn)題。于是繼續(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)致問(wèn)題. 而 KEIL 調(diào)試環(huán)境并沒(méi)有進(jìn)入到 if 語(yǔ)句內(nèi)部, 因此并沒(méi)有觸發(fā)問(wèn)題. 那么為什么if 語(yǔ)句的判斷結(jié)果不一樣呢?

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

如上紅色代碼, 用它替換原來(lái)的 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 的值又是如何來(lái)的呢? 從如下代碼:

如上所示, flag_it 的值來(lái)自 hdma->DmaBaseAddress->ISR, 原來(lái)是 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 上的, 而此地址一般保存的是棧頂.。也就是說(shuō), 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。

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

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

至此，將問(wèn)題稍作小結(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ì)聽(tīng)到某某客戶反饋說(shuō), 在網(wǎng)絡(luò)上看到 STM32 某款 MCU 存在某某問(wèn)題, 然后問(wèn)是不是 ST 故意隱瞞 ?

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

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