問題現(xiàn)象與分析
客戶項目中使用的 MCU 型號是 STM32G0B1, 他們反饋在代碼中嘗試擦除并編程 FLASH時, 發(fā)現(xiàn) FLASH 的狀態(tài)寄存器顯示編程錯誤(如圖 1 所示). 問題是當前代碼還沒有開始擦除和編程, 怎么就有了編程錯誤標志了呢 ? 如果不將此錯誤標志清除, 后續(xù)的編程操作無法繼續(xù).客戶對于每次想要操作 FLASH 之前這個清除動作既感覺多余也感覺別扭, 且還不得不做, 且做了也不知對整個產(chǎn)品的穩(wěn)定性會有什么樣的影響 ?
小結(jié)
至此,將問題稍作小結(jié)。給變量 flag_it 實際賦值棧頂?shù)刂? 不同的編譯器環(huán)境下, 此棧頂?shù)刂返牟灰恢聦е伦兞?flag_it 的值不一致, 進而導致 if 語句的判斷結(jié)果不同, 最終導致 IAR 和 KEIL 這兩個編譯器環(huán)境下運行相同代碼而結(jié)果不一樣的情形。
后記
有時會聽到某某客戶反饋說, 在網(wǎng)絡上看到 STM32 某款 MCU 存在某某問題, 然后問是不是 ST 故意隱瞞 ?不存在故意隱瞞的說法,芯片終究是要經(jīng)過終端驗證的。
正常來講, 任何芯片存在應用局限是正常的。對于 ST,一方面會正式地將所有已知 bug或應用局限放入到勘誤手冊中公示, 大家需要注意使用最新版勘誤手冊;另一方面,對于 ST 量產(chǎn)芯片,因本身缺陷導致的問題的概率非常低。事實上,絕大多數(shù)問題都來自我們自身的應用,遇到問題若簡單的基于芯片品質(zhì)來回猜疑非常不利于開發(fā)者靜下心來查找問題原因。 其實,面對問題時,我們很多人欠缺的并不是多么高深的水平,而是一顆冷靜、自信并富有條理的心。