KEIL 調(diào)試方法經(jīng)驗總結(jié)

我們已經(jīng)了解了很多的 KEIL 調(diào)試方法，但是到底該怎么使用這些方法呢？這篇文章將介紹個人的調(diào)試經(jīng)驗。 虛擬串口

首先是虛擬串口，為什么要虛擬串口，這里的虛擬串口又是什么意思？

在線仿真的時候我們根本不需要虛擬串口，因為單片機一般來說都有串口，所以不需要虛擬的串口，但是在軟件仿真情況下又該如何呢？

有些時候我們可能沒有開發(fā)板，但項目很急，需要提前做，該怎么辦？KEIL 的軟件仿真可以幫你解決大部分問題，它可以幫你驗證程序邏輯問題，也能驗證硬件配置是否正確，相當不錯的功能。比如你的串口配置是否有問題，進入仿真模式：

從上面的仿真圖你可以了解到在軟件仿真模式下，你可以正常使用 printf（），scanf（）函數(shù)，輸入輸出操作由串口窗口進行，所以還是很方便的，但是需要注意的是：

即使是軟件仿真，它的發(fā)送時間和你的設(shè)定波特率也是有關(guān)系的，即發(fā)送完一個字節(jié)后，必須延時后才能在串口窗口看到數(shù)據(jù)，這個時間和現(xiàn)實時間可能不匹配（即 115200 不一定是 1 秒就發(fā)送115200 個 bit，可能更多，也可能更少），但道理是一樣，因為它對串口的工作過程進行了完全模擬。在這里你還可以選擇顯示方式。

這里看到我之前寫的一個注釋：

但實際測試發(fā)現(xiàn)并不會丟失最后一個字符，不知道當時咋測試的。繼續(xù)正題。有一個問題，如果說你想把這個數(shù)據(jù)傳給其他上位機呢？比如你想把串口數(shù)據(jù)傳輸?shù)揭粋€虛擬示波器顯示（事實上 KEIL 也能顯示波形，但是功能比較簡單），又該怎么辦？這個時候你可以虛擬一個 COM 口，將串口數(shù)據(jù)綁定到 COM 中：

在命令行中輸入紅色方框中的內(nèi)容，既可達到目的。當然你可以將其保存為.ini 文件，具體使用方法請看魚鷹相關(guān)筆記。上面的命令參考鏈接：http://www.keil.com/support/man/docs/uv4cl/uv4cl_cm_assign.htm？_ga=2.225757210.1084600666.1557148734-475076243.1554469739完成綁定后。

KEIL 軟件的串口 1 數(shù)據(jù)除了會發(fā)送到 KEIL 串口窗口中（【View】【Serial Windows】），也會發(fā)送到 COM1 口中（當然數(shù)據(jù)輸入也是從 COM1 中進行輸入的）。但是因為 KEIL 對 COM1 進行了綁定，也就是你的 KEIL 正在使用 COM1 口，那么其他軟件肯定是無法打開這個 COM1 口的，那么這樣又該怎么查看 COM1 的數(shù)據(jù)呢？

此時你可以使用一個軟件虛擬兩個串口，這里我用 vspd.exe 軟件虛擬 COM1 和 COM2，并且將 COM1 和 COM2 進行了連接，這里就是說 COM1 發(fā)送的數(shù)據(jù)會被 COM2 接收，接收同理，這樣一來，KEIL 中的串口數(shù)據(jù)就能發(fā)送到 COM2 中了，因為 COM2 并沒有被任何軟件所使用，所以你可以使用串口助手打開（其他串口軟件類似）。

因為在這里是虛擬的串口，所以說你的波特率參數(shù)并沒有用處，即你的串口配置成 115200，你的上位機以 9600 接收也是可以的。但是你會發(fā)現(xiàn)，這個中文支持不如 KEIL 自帶的窗口好用，但通過將串口綁定到其他 COM 口的方法能擴展它的串口仿真功能，還是相當不錯的。事實上，KEIL 除了仿真串口，也能仿真 I2C、CAN，比如下面的：

對此感興趣的可以參考鏈接：http://www.keil.com/support/man/docs/uv4/uv4_sm_can_communication.htm變量使用在前面公布的文章中，魚鷹曾經(jīng)說過一個詞，顛覆認知：打了多年的單片機調(diào)試斷點到底應(yīng)該怎么設(shè)置？| 顛覆認知也說過一個串口通訊的問題：

KEIL 調(diào)試的 ini 文件有什么用？通過運用上面的知識，總算是解決了項目串口通信的問題，測試多天，不再出現(xiàn)這個問題了。那么魚鷹是如何解決的呢？且聽魚鷹道來。這個通信錯誤的現(xiàn)象是，前一個數(shù)據(jù)幀尚未發(fā)送完成，后面又來一個數(shù)據(jù)幀，導(dǎo)致傳輸數(shù)據(jù)錯亂了，這種現(xiàn)象在多任務(wù)中很常見，所以魚鷹很早就對它進行了研究：

信號量保護之禁止中斷

因為魚鷹知道，資源互斥的現(xiàn)象很平常，只有深刻理解了其中的原理，你才能更好的掌握它。而這個通信過程的互斥資源有兩個，第一個是發(fā)送緩存數(shù)組的資源，另一個就是串口。在這里因為沒有采用隊列的方式發(fā)送數(shù)據(jù)，所以緩存數(shù)組和串口是綁定在一起的。

也就是說，一旦數(shù)組中含有發(fā)送數(shù)據(jù)，那么馬上就開始進行發(fā)送，中間不應(yīng)該斷開，所以可以把數(shù)組和串口當成一個資源使用（特別需要注意的是，一定要在對數(shù)組賦值之前獲得互斥鎖，而不是在串口發(fā)送前獲取，因為只要這樣，才能保證你發(fā)出的數(shù)組數(shù)據(jù)不會被其他程序修改）。

很明顯，這個資源是互斥的，所以可以使用一個變量作為訪問該資源的鎖，每次訪問之前看資源是否被使用，如果被使用了就等待。而鎖的釋放是由發(fā)送完成中斷完成的，即只有將全部數(shù)據(jù)發(fā)送完成之后這把鎖才能釋放，進而由其他任務(wù)使用。

那么如何利用上面提到的技能查找這類問題呢？

這里的關(guān)鍵點還是在鎖，因為如果這把鎖被正確使用的話，是不應(yīng)該出現(xiàn)兩個數(shù)據(jù)幀混亂的情況的，需要對這把鎖重點關(guān)注，那么該如何關(guān)注呢？

就是用前面的斷點窗口，對這個變量（鎖）設(shè)置寫入訪問斷點，如下：

這里要說明一點，單片機所有的全局變量都是可以在命令行直接獲取數(shù)據(jù)的（事實上如果你將斷點設(shè)置在函數(shù)內(nèi)部，也可以獲取局部變量的值），比如你在命令行直接輸入 lock

0x00000001 就是這個全局變量 lock 的值。

回到剛才鎖的話題。在斷點窗口設(shè)置之后，你就會在 Command 命令窗口中得到如下消息：

正常的 lock 數(shù)據(jù)流程應(yīng)該是這樣，1~0~1~0~1……也就是上鎖、釋放鎖交替進行的，但是魚鷹在觀察有錯誤通信的代碼發(fā)現(xiàn)，出現(xiàn)了 1~0~0 這種情況，也就是說一次上鎖之后，出現(xiàn)了兩次釋放鎖的過程，那這是怎么回事？

魚鷹前面說過，釋放鎖的位置在串口發(fā)送完成中斷中（此處是 DMA 傳輸完成中斷），難道有其他位置對它進行了清零操作？為了確定這個位置繼續(xù)增加調(diào)試信息（注意如果重新設(shè)置了一個新斷點，需要把之前的斷點刪除）：

這次將寫入時的 PC 指針打印出來（需要注意，ST-LINK 不能實時更新這個 PC 數(shù)據(jù)，但 CMSIS-DAP 可以，暫時未找到解決辦法），你會發(fā)現(xiàn)清零的位置是一樣的（沒有實際環(huán)境，模擬的情況）：

可以看到，清零操作時的 PC 指針都是一樣的，也就是說，釋放鎖的過程確實只有一處，那么為什么會出現(xiàn)兩次釋放呢？那肯定是啟動了兩次 DMA 傳輸，導(dǎo)致兩次進入傳輸完成中斷，從而釋放了兩次鎖。

這里再說一點，怎么通過 PC 指針找到對應(yīng)源代碼的位置：

之后輸入你的 PC 指針即可：

但是按理來說，如果上鎖操作正常的話，應(yīng)該不會出現(xiàn)兩次啟動 DMA 傳輸?shù)倪^程才是，所以由此可以判斷出，肯定有至少一處地方?jīng)]有上鎖而直接使用了互斥資源，才最終導(dǎo)致了異常情況。

通過對互斥資源在整個系統(tǒng)的使用情況，發(fā)現(xiàn)確實有一個地方使用了互斥資源，但是卻沒有對互斥資源上鎖（當時由于某種原因，只對鎖是否可用進行了判斷，但判斷完成后，并沒有對它加鎖）。當加上了這把鎖之后，通信就此正常了（實際情況要比這個更復(fù)雜一些）。

為什么說顛覆認知，就是因為掌握了這個技能后，很多問題可以迎刃而解。就比如項目中有一個變量莫名奇妙的變化了，通過對每一次寫入操作的監(jiān)控，發(fā)現(xiàn)了數(shù)據(jù)變化順序出現(xiàn)了問題，不該出現(xiàn)的變化卻出現(xiàn)了，從而深入下去找到變化的原因，并最終解決了這個項目問題?？梢哉f掌握了這個技能，魚鷹用它解決了很多以前難以解決的問題，所以我才會對它推崇備至！

從前面講述的內(nèi)容可以知道，原來 printf 函數(shù)不僅可以打印一些字符串，還能獲取運行在單片機上所有的數(shù)據(jù)（包括你定義的全局變量、靜態(tài)變量、外設(shè)寄存器、CPU 寄存器），了解了這個，你再也不用在你原來的代碼中添加調(diào)試代碼后再刪除了，使用這個方法有以下幾點好處：

1、命令行中的 printf 函數(shù)打印數(shù)據(jù)比串口打印速度更快，極大地減少了調(diào)試語句對原本代碼的影響。

2、再也不會忘記刪除代碼了，因為這些語句根本就沒有下載到單片機中，只要退出調(diào)試模式，就不會對程序造成任何影響。

3、只要你使用 KEIL，有一個可以設(shè)置斷點的調(diào)試器（不管是 ST-LINK、CMSIS-DAP、還是 J-LINK）都可以采用這種方式調(diào)試，極大的方便了開發(fā)。

說到程序的變量，事實上我們也可以在 KEIL 內(nèi)部定義一個變量，即使用 DEFINE 命令定義一個變量名，這個變量不存在于單片機中，而只存在 KEIL 軟件中，所以不用擔心存儲空間不夠的問題，但是因為單片機和 KEIL 共用同一套符號系統(tǒng)，所以，你定義的變量名不能和單片機的全局變量名相同。至于你定義的這個變量用來干什么，那完全就是你自己的事情了。

數(shù)組輸出

前面的內(nèi)容說了程序中的變量都可以通過 printf 函數(shù)打印出來，但在公眾號公布的文章說過，它畢竟不是標準的 C 語言函數(shù)，所以它不支持指針，所以也不支持數(shù)組，那么我們該如何輸出數(shù)組呢？

這個時候其實要用到公眾號公布的另一篇關(guān)于 ini 的使用問題的文章。

看完那篇文章之后，在 ini 文件中輸入以下代碼，并編譯執(zhí)行：

然后，在你的程序中添加如下代碼：

這里的 OspreyARR 數(shù)組是我們準備輸出的數(shù)據(jù)，OspreyPointer 這個數(shù)據(jù)用于保存數(shù)組的地址。因為不支持指針，只能換種方式來達到相同的效果了。

然后對上面的斷點設(shè)置如下：

事實上我們也可以設(shè)置成這樣：

這里的 0x2000 004E 就是數(shù)組的地址，但是因為每次編譯之后，數(shù)組的地址可能都不一樣，所以使用一個變量 OspreyPointe 實時保存這個地址，這樣你需要顯示什么數(shù)據(jù)，只要修改這個變量的值即可，不需要修改斷點窗口的值。

全速運行之后，你就可以獲得如下結(jié)果：

可以看到，數(shù)組中的所有數(shù)據(jù)都打印出來了，同時將當前打印的地址、長度信息也打印出來了。

數(shù)組查看這個技能有什么好處？下位機和上位機通信是很正常的是，而通信錯誤再正常不過了，那么怎么實時獲取通信過程的數(shù)據(jù)呢，以前靠串口 printf，現(xiàn)在靠更高級的 KEIL printf，就是這么簡單，串口助手都省了。

除此之外，我們還可以對接收或者發(fā)送的數(shù)據(jù)進行解析，方便閱讀，比如下面的是我在工作中根據(jù)自己的通信協(xié)議做的一個簡單解析：

時間獲取

上面介紹了獲取數(shù)據(jù)的方法，但是很多時候，我們不僅需要數(shù)據(jù)進行分析，還需要獲取數(shù)據(jù)時間，有時候時間是很關(guān)鍵的一環(huán)。

那么該如何獲取時間呢？

以前一般使用 SysTick 獲取時間，但是當你使用操作系統(tǒng)的時候，你會發(fā)現(xiàn)這個時鐘被操作系統(tǒng)占用了，那么怎么辦？搶嗎？肯定不行，那么只能找替代方案了，那么找誰，普通定時器？高級定時器？都不是，這里魚鷹推薦 DWT。

為什么推薦它呢？

1、很多 STM32 單片機都集成了這個模塊

2、它的精度是 CPU 運行周期，即它是由 CPU 系統(tǒng)時鐘驅(qū)動的，即你的內(nèi)核時鐘頻率是 72 M，那么它的頻率也是如此，所以精度很高。

當我們使用定時器中斷的時候，如果需要看你的定時中斷是否及時處理了（如果沒有及時處理，那么兩次進入定時中斷的時間肯定是不同的），那么使用 DWT 是不二人選，因為即使你的中斷延遲了一個指令的執(zhí)行時間，它也能發(fā)現(xiàn)，因為多運行一條指令，那么 DWT 的計數(shù)器必然會增加，所以如果時間要求高的話，可以直接獲取計數(shù)器的值。

但很多時候，可能并不需要那么精準的時間，而只需要大概的實際時間，而且為了方便使用，魚鷹使用相對時間（即上次和這次執(zhí)行時間之差），所以可以使用下面的這個函數(shù)（上面這個函數(shù)用于直接獲取計數(shù)器的值，0xE0001004 為 DWT 計數(shù)器的地址，事實上 DWT 使用是需要初始化配置的，但 KEIL 在進入 Debug 模式后會自行配置，不需要你操心）：

并且為了和正常時間匹配，對 DWT 時間進行了換算，單片機系統(tǒng)時間設(shè)置為 72M，所以我這里除以 72 用于換算成 us 時間，另外為了更加精確，使用了浮點型數(shù)據(jù)（關(guān)于為什么加 0xFFFF FFFF 請看公眾號相關(guān)文章，魚鷹就不在此詳述了）。

那么該怎么使用呢？我在公眾號的視頻中其實已經(jīng)展示了這個方法，現(xiàn)在詳細介紹這個方法：

首先設(shè)置一個你需要的斷點，然后在 Command 里面輸入你的 printf（）調(diào)試信息：

這樣就可以了（前提是你已經(jīng)使用 ini 文件包含了上述內(nèi)容）。

其實單純獲取時間信息是用處不大的，你還可以結(jié)合前面的變量和數(shù)組數(shù)據(jù)顯示，一起輸出到命令窗口，這樣你就能獲得這個斷點的執(zhí)行頻率和變量的數(shù)據(jù)，但是這里需要說明一點的就是，魚鷹在 KEIL V5.14 下用調(diào)試器 CMSIS-DAP 可以同時在 Watch 窗口和命令窗口中實時刷新數(shù)據(jù)，但是使用 ST-LINK 時發(fā)現(xiàn)命令窗口的數(shù)據(jù)變量值是不能實時刷新，也就是說這個變量始終是一個數(shù)據(jù)，并沒有改變。

但是后來在使用 V5.25 版本時，CMSIS-DAP 調(diào)試下，命令窗口能刷新，Watch 窗口卻不能刷新了，所以各種情況需要道友自行分析，不能認為數(shù)據(jù)不變就是真的不變了，很可能是軟件或調(diào)試器的問題，但能確定的一點就是，當你將程序暫停時，Watch 還是會刷新數(shù)據(jù)的，這個時候的數(shù)據(jù)是可以信任的。

（關(guān)于這個還有一篇文章KEIL 下如何準確測量代碼執(zhí)行時間？）

LOG 輸出

不知道你是否羨慕別人的上位機程序能夠?qū)崟r的打印 LOG 數(shù)據(jù)，是否夢想著自己的嵌入式程序有一天也能實現(xiàn)？事實上真的可以。

在嵌入式開發(fā)時，受單片機資源的限制，很多時候都是用串口打印數(shù)據(jù)，高級一點的用 J-Scope 之類的工具，但是用串口有比較多限制：

1. 需要實現(xiàn)串口驅(qū)動程序，并占用為數(shù)不多的串口資源

2. 串口速度比較慢

3. 需要一個類似串口助手的上位機

4. 數(shù)據(jù)接收后需要自己保存這些數(shù)據(jù)

5. 不能設(shè)置斷點，調(diào)試受到很大的限制

6. 調(diào)試代碼在調(diào)試完之后得刪除，萬一忘記了，就會影響性能

但是用了 KEIL 自帶的 LOG 打印功能，就不存在這些問題，它的輸出速度就是調(diào)試器的速度，調(diào)試器多快，你的打印就有多塊（但是打印數(shù)據(jù)也別太多，需要針對性的打印，后面會說原因），而調(diào)試器速度一般都是 M 級別的，對于一般情況完全夠用了。

現(xiàn)在看怎么使用，使用的話，其實很簡單，就是幾條指令的事情，在你的 ini 文件最后輸入以下命令：

這樣從這條命令以下的所有內(nèi)容都會保存在 DEBUG_LOG_OUT.txt 中（所以如果你不想把 ini 文件的其他內(nèi)容保存在 LOG 中的話，那么就把這條命令放在 ini 文件最后即可）。

現(xiàn)在解釋一下這幾條命令，LOG OFF 表示將 LOG 文件關(guān)閉，即使你沒有打開一個 LOG 文件，執(zhí)行該命令也不會出錯，這條命令主要是防止一個 LOG 文件重復(fù)打開的錯誤，加上這條命令就不會了。

第二條命令，即將 Command 窗口的數(shù)據(jù)保存在 DEBUG_LOG_OUT.txt 中，注意這里有個 》 ，而 DEBUG_LOG_OUT 這個文件名就隨你意了，但是實驗的時候按這個來，等你確定會了之后就可以隨便取你喜歡的名字了，出了問題自己對比一下就知道了。

然后再說一點，這里使用的是相對路徑，即你的工程文件下的路徑，如果你想往上一層，你可以使用 。./ 表示在這個工程上的一個文件夾下輸出 LOG 文件。

當退出調(diào)試模式之后，KEIL 將自動保存 Command 數(shù)據(jù)到文件中（也就是說在此之前你是看不到這些調(diào)試數(shù)據(jù)的），現(xiàn)在看看我的調(diào)試 LOG：

一次設(shè)定之后，LOG 打印就不需要你操心了，即使調(diào)試器通信錯誤，它也會把之前輸出的數(shù)據(jù)保存下來的。

看到這里，你應(yīng)該知道 ini 文件到底有多重要了吧，你的所有調(diào)試命令都可以用它保存并在進入調(diào)試模式后自動執(zhí)行，比如說你有一個斷點，很復(fù)雜，不想每次設(shè)置，那么你可以在設(shè)置完一次后，從命令窗口將這個命令復(fù)制到 ini 文件中，比如像這樣：

這樣你每次進入調(diào)試模式后，那些斷點就會被自動設(shè)置了，根本不用你操心，而且如果需要修改的話，也是直接在編輯器中修改后重新編譯就行，馬上就能生效，不再需要從斷點窗口設(shè)置了。

而這里有個刪除所有斷點的命令，這是為了防止和之前設(shè)置的斷點沖突，所以一次性全部刪除了（事實上，可以刪除某一個斷點，但需要斷點序號，而斷點序號每一次都可能不一樣，所以選擇直接全部刪了方便）。而為了更好的配合這些功能，可以把下面的 Breakpoints 勾選去掉，這樣它就不會保存關(guān)于斷點的設(shè)置了，而為了讓 Toolbox 在關(guān)閉后還能每次自動顯示出來，也可以去掉 Toolbox 的勾選。

另外再說一點，KEIL 支持把某一塊內(nèi)存數(shù)據(jù)保存成文件，這個命令是 SAVE，感興趣的話可以去官網(wǎng)了解一下。

注意事項

上面說了 KEIL 命令調(diào)試的很多優(yōu)點，現(xiàn)在說說它的缺點：

1、KEIL 命令調(diào)試不支持指針，這個已經(jīng)多次強調(diào)了，要實現(xiàn)指針的功能，只能間接使用。

2、對程序運行造成一定的影響（事實上這個不關(guān) KEIL 的事，是調(diào)試系統(tǒng)本身的問題）

前面說過，調(diào)試器可以說是第三方監(jiān)視器，雖然幾乎沒有侵入性（事實上對 CPU 還是有影響的），但是它還是會竊取 CPU 時鐘的，而且在執(zhí)行斷點的時候，雖然由 ini 文件定義的函數(shù)由 KEIL 執(zhí)行了，實際上上執(zhí)行這些函數(shù)也是需要時間的，那這個時間怎么來。

就是通過暫停 CPU 后去執(zhí)行這些代碼，這個你可以通過 DWT 計數(shù)器看出來，因為只有 CPU 執(zhí)行了 DWT 才會計數(shù)，但是你會發(fā)現(xiàn)在執(zhí)行這些代碼時，DWT 是沒有進行計數(shù)的（在 KEIL 函數(shù)的前后獲取 DWT 計數(shù)，可以發(fā)現(xiàn)計數(shù)值不變）：

也就是說 CPU 和 KEI 是在交替使用系統(tǒng)時鐘的。平常來看，由于 KEIL 執(zhí)行速度很快，看不出來問題，但到中斷的時候卻會出現(xiàn)問題。

情況是這樣的，驅(qū)動步進電機時，魚鷹使用了這種調(diào)試方法打印每次進入定時器中斷的時間，發(fā)現(xiàn)即使使用最高精度的情況下（CPU 運行時鐘），每次進入中斷的時間看似都是固定的，但步進電機還是表現(xiàn)出失步情況，也就是說系統(tǒng)內(nèi)部時間看起來每次進入中斷時間一樣，但是實際情況是，已經(jīng)丟失了時間（好好理解這句話），這個時間損耗就在運行這些命令上，而一旦把這些命令輸出刪去，就會發(fā)現(xiàn)電機不再出現(xiàn)失步了。

這是一個比較大的缺陷，但是在一般情況下是不會有多大問題的，因為一般情況下竊取一點 CPU 時間也不會對整個系統(tǒng)有太大影響，前提是你別竊取太多了。

編輯：jq