?在我們的單片機(jī)調(diào)試過程中，經(jīng)常會(huì)遇到類似如下因第3只眼而導(dǎo)致的問題。何謂第3只眼呢？不妨先看看幾個(gè)實(shí)例就知道了。

第一個(gè)案例，與ADC轉(zhuǎn)換標(biāo)志位有關(guān)的問題。遇到該問題是一種較為頻繁的情形。

經(jīng)常有人在做STM32 ADC應(yīng)用，進(jìn)行代碼單步調(diào)試時(shí)發(fā)現(xiàn)，明明啟動(dòng)了ADC轉(zhuǎn)換就是等不到轉(zhuǎn)換結(jié)束的那一刻，即總是檢測(cè)不到EOC等于1的時(shí)候。有時(shí)讓人直急得冒汗！比方類似下面的情形，開啟了ADC轉(zhuǎn)換指令，然后等待ADC轉(zhuǎn)換結(jié)束。

在那藍(lán)色圓圈的代碼處，查詢等待EOC等于1,可就是等不到它為1的時(shí)候。是怎么回事呢？

原來，STM32芯片ADC的轉(zhuǎn)換結(jié)束標(biāo)志EOC位，具有讀清零的特性。當(dāng)你調(diào)試時(shí)打開外設(shè)寄存器顯示欄時(shí)，那調(diào)試組件在不停的讀取它。當(dāng)你單步操作去讀取該標(biāo)志位時(shí)往往先被調(diào)試組件讀過了。即使它之前被置位過，但因調(diào)試組件的讀取后又被清零。當(dāng)你單步慢悠悠去讀它時(shí)，結(jié)果讀到的往往是0，你就查不到為1的那一刻，此時(shí)我們可能會(huì)傻傻的等和著急。

?當(dāng)然，如果你將右邊ADC外設(shè)寄存器顯示欄關(guān)閉就不會(huì)出現(xiàn)上述問題了。

第二個(gè)案例??，與UART狀態(tài)寄存器標(biāo)志位有關(guān)的問題。遇到該問題也是較為頻繁的情形。

某STM32用戶使用STM32F2系列芯片的UART外設(shè)及相關(guān)功能。他發(fā)現(xiàn)明明接收完畢，發(fā)送標(biāo)志TC位也置位了，可就是不進(jìn)IDLE空閑中斷。當(dāng)然，相關(guān)中斷使能都已正常使能無誤。實(shí)際情形是這樣的：

STM32F205的UART5發(fā)送指令（循環(huán)發(fā)送一個(gè)字節(jié)一個(gè)字節(jié)地發(fā)）給wifi芯片，WiFi芯片會(huì)返回相應(yīng)數(shù)據(jù)過來，所以，正常來講uart5會(huì)收到一幀數(shù)據(jù)之后應(yīng)該進(jìn)入串口接收IDLE中斷.這是客戶所期望的。

他將斷點(diǎn)打在UART中斷服務(wù)程序的檢查到IDLE中斷請(qǐng)求位等于1后的入口處。就像下面截圖的樣子。他甚至在右邊的UART寄存器顯示欄都看到IDLE被置位過的痕跡了，可就是進(jìn)不到相關(guān)代碼里去，怎么回事呢？

?因?yàn)樗_啟了UART寄存器顯示窗口，意味著調(diào)試組件在不停幫他讀了UART相關(guān)寄存器，其中包括DR和SR寄存器。當(dāng)他在中斷代碼里再去讀SR寄存器里的IDLE標(biāo)志位時(shí)，讀回來的結(jié)果總是0，所以中斷程序沒法進(jìn)一步走下去。對(duì)于他這里，嚴(yán)格地說是響應(yīng)了中斷，只是沒法進(jìn)一步進(jìn)入相關(guān)中斷服務(wù)代碼區(qū)。

其實(shí)，對(duì)于stm32f2芯片UART的IDLE中斷請(qǐng)求標(biāo)志位的清零會(huì)遵循一個(gè)訪問序列，即讀DR寄存器，然后讀SR寄存器就可將IDLE位清零。

當(dāng)然，解決上面問題的辦法也很簡(jiǎn)單，調(diào)試跟蹤時(shí)，將右邊UART的外設(shè)寄存器顯示欄關(guān)閉就好。

第三個(gè)案例，與讀取RTC日歷有關(guān)的問題。一個(gè)較為隱蔽而容易誤導(dǎo)人的問題。

曾有人反饋說STM32F4和STM32L4的RTC脫機(jī)運(yùn)行跑不起來，不運(yùn)行。具體表現(xiàn)就是日歷時(shí)間不動(dòng)、不更新。奇怪的是，調(diào)試時(shí)候不論單步還是全速運(yùn)行，查看日歷寄存器都顯示正常運(yùn)行，數(shù)據(jù)也正確。

可當(dāng)燒錄代碼到芯片后，通過調(diào)試助手查看日歷的數(shù)據(jù)則原地不動(dòng)了，感覺RTC沒有運(yùn)行。客戶用STM32F4和STM32L4的板都測(cè)試過，出現(xiàn)同樣問題。懷疑STM32F4和L4芯片的RTC是否有BUG【反正找不到原因了就想芯片bug?】。

查看其測(cè)試代碼，就是讀RTC的日歷，很簡(jiǎn)單。如下?：

while(1){

HAL_RTC_GetTime(&hrtc,&rtcTime,RTC_FORMAT_BIN);?printf( ...... );HAL_Delay(1000);}

?從上面代碼不難看出就是不停地去讀當(dāng)前的時(shí)、分、秒時(shí)間。STM32參考手冊(cè)在關(guān)于RTC日歷讀取操作部分有相關(guān)描述。為了讀取時(shí)間的一致性，讀取日歷操作要求先讀時(shí)分秒然后還得讀日期，這樣做為一個(gè)完整的操作。所以在讀取TIME【時(shí)分秒】后，硬件會(huì)將當(dāng)前日歷值鎖住，直到讀取了日期寄存器。否則當(dāng)你讀了TIME而不讀DATE的話，再去讀TIME時(shí)還是原來的值維持不變。顯然，客戶這里的代碼只有讀取TIME時(shí)間的語句，沒有讀取DATE日期的代碼。這是問題?根本原因之所在。

但是，為什么同樣代碼在調(diào)試情況下又能正常運(yùn)行呢？?那是因?yàn)樗谡{(diào)試時(shí)打開著RTC寄存器外設(shè)顯示窗口，雖然用戶代碼沒去讀DATE，但調(diào)試組件幫忙讀了DATE寄存器，所以感覺上一切風(fēng)調(diào)雨順，也就沒能及時(shí)發(fā)現(xiàn)問題，一直到程序燒進(jìn)芯片后才發(fā)現(xiàn)異常癥狀。

到此，結(jié)合上述3個(gè)案例的分享介紹，我們應(yīng)該明白了那個(gè)第3只眼了，即調(diào)試組件。個(gè)別寄存器或寄存器位具有“讀則變”或“讀有效”的特性。我們?cè)谡{(diào)試時(shí)候要注意類似細(xì)節(jié)，調(diào)試時(shí)也不必時(shí)刻將那個(gè)外設(shè)寄存器顯示欄開啟掛在那里。其實(shí)，除了這個(gè)寄存器顯示欄外，我們還可以利用其它輸出，比方示波器、printf，或者WATCH窗口等來輔助觀察運(yùn)行狀態(tài)或結(jié)果。

既然這里把調(diào)試組件稱之為第3只眼，那另外兩只眼呢？這個(gè)不難想到CPU和DMA。