干嵌入式開發(fā)這些年STM32串口調(diào)試、代碼開發(fā)、硬件聯(lián)調(diào)這些活兒我基本每天都在碰。說實話很多坑根本不是芯片本身的問題而是工具鏈、開發(fā)環(huán)境、協(xié)議細節(jié)這些非技術(shù)因素把人逼瘋的。這篇文章我把那些年踩過的坑整理成一份經(jīng)驗總結(jié)給正在入門或者已經(jīng)上手的兄弟做個參考。內(nèi)容不追求面面俱到只挑那些真正折騰過、在社區(qū)里反復(fù)被問到的典型問題來聊每個坑都會說清楚現(xiàn)象、根因和解決辦法。1. 開發(fā)環(huán)境那些坑從Keil安裝到ST-Link驅(qū)動的連環(huán)翻車1.1 Keil5同時兼容C51和STM32的安裝陷阱先說環(huán)境問題。很多人電腦上裝的是Keil5又想玩8051又想搞STM32于是直接拿一個Keil5安裝包裝完發(fā)現(xiàn)只有ARM編譯器沒有C51編譯器或者反過來。更常見的是——明明裝好了打開工程卻提示找不到芯片、找不到ARMCC。這個問題的根子在于Keil C51和Keil MDK是兩套不同的產(chǎn)品線共用一個IDE外殼但編譯器、芯片支持包、許可證都互相獨立。MDK也就是我們常說的Keil5 for ARM自帶ARMCC/AC6編譯器支持Cortex-M系列C51是另一套Keil 8051工具鏈兩個都裝在同一臺電腦上IDE會合并顯示但工程文件的解析和編譯器的調(diào)用是完全分開的。踩坑點在于很多人不清楚安裝順序和許可證管理。正確做法是先裝C51版Keil再裝MDK版Keil安裝路徑建議用默認路徑否則IDE找不到對應(yīng)的TOOLS.INI配置。裝完之后打開Keil你會看到兩個License Management入口需要分別激活C51和ARM的許可證。如果你用的是同一把正版License有時需要在兩個License管理窗口中分別添加不然編譯8051工程時報License Crack或者Feature not found而編譯STM32工程卻正常。另外一個大坑是芯片支持包Pack版本。很多老工程用的STM32F103芯片Pack版本裝得過高或者過低都會導(dǎo)致一個詭異現(xiàn)象IDE能識別芯片型號也能編譯下載也提示成功但板子跑起來完全不對。后來才發(fā)現(xiàn)是Pack版本更新后默認的頭文件路徑和寄存器定義發(fā)生了變化比如從舊版固件庫切到新版HAL庫工程代碼里混用了新舊兩套API編譯不報錯是因為兩套API都還存在于頭文件中但鏈接順序出了問題。這個問題的排查很費時間我建議直接在工程里打開C/C配置頁檢查Include Paths里面是否混入了多個不同版本的Drivers/CMSIS路徑一旦發(fā)現(xiàn)果斷把舊的刪掉。1.2 ST-Link連接不上的真正原因ST-Link連不上目標板這是所有STM32開發(fā)者的第一個噩夢?，F(xiàn)象一般是Keil里點Download提示No target connected或者Error: Flash Download failed - Target DLL has been cancelled。我第一次遇到時以為是ST-Link壞掉了換了三根USB線都沒解決最后才發(fā)現(xiàn)問題出在ST-Link固件和驅(qū)動不匹配。很多人直接用Windows自動安裝的驅(qū)動或者用某寶送的雜牌ST-Link但驅(qū)動是老版本而Keil使用的CMSIS-DAP調(diào)試框架對新舊版本驅(qū)動有兼容要求。解決辦法是安裝ST官方提供的ST-Link USB Driver并在設(shè)備管理器里確認枚舉出來的是STM32 STLink而不是Unknown Device或Mass Storage。排查順序也很重要別一上來就重裝驅(qū)動。正確鏈路是先看ST-Link的LED狀態(tài)——常亮紅色說明沒識別到目標板閃爍綠色說明固件運行正常然后檢查接線SWD只需要四根線SWDIO、SWCLK、GND、3.3V很多人把SWDIO和SWCLK接反或者漏接GND漏GND時偶爾還能通信但極不穩(wěn)定接著在MDK里選擇Utilities - Settings看能不能讀回目標板的IDCODE。如果能讀回0x1BA01477程序比如F103的ID說明調(diào)試通道是通的問題在Flash下載算法如果讀不到再回頭查線。還有一個容易被忽略的是目標板供電問題。ST-Link可以給目標板供電但F103的開發(fā)板上如果同時接了外部電源兩個電源域電位差可能導(dǎo)致SWD通信異常。尤其USB供電和外部5V適配器都接入時板載LDO的輸出會被拉偏。我后來養(yǎng)成的習慣是調(diào)試時只用一種供電方式ST-Link的3.3V輸出腳能用盡量用避免雙電源串擾。1.3 芯片包安裝失敗的常見連鎖反應(yīng)芯片包Pack安裝失敗網(wǎng)上最常見的現(xiàn)象是Keil提示Pack not found或者安裝時一直卡在某個進度條。很多人以為是網(wǎng)絡(luò)問題實際上多半是Keil的Pack Installer緩存目錄權(quán)限不夠。Windows下Keil默認把Pack緩存放在C:\Users\用戶名\AppData\Local\Arm\Packs如果這個目錄被安全軟件鎖了或者用戶目錄權(quán)限異常Pack安裝就會一直轉(zhuǎn)圈。另外一些公司的辦公電腦有軟件分發(fā)策略C盤部分目錄只讀也會遇到同樣問題。我的處理方式是手動從ST官網(wǎng)下載對應(yīng)芯片的Pack離線安裝包比如STM32F1xx_DFP然后以管理員身份運行Keil在Pack Installer里選擇File - Import直接導(dǎo)入本地Pack。這個方法比在線等穩(wěn)定得多特別是新出的芯片型號在線服務(wù)器有時候還沒有同步最新Pack。Pack安裝失敗還會帶來一個非常隱蔽的問題調(diào)試時能編譯能下載但代碼中的外設(shè)寄存器地址與中斷向量表錯位。原因是有多個不同版本的Pack同時存在于Packs目錄Keil自動選擇版本時邏輯混亂鏈接到了舊版SVD文件。遇到這種子虛烏有的問題建議先清空Packs目錄中同名芯片包的所有版本只保留一個最新的再重新編譯。2. 時鐘樹與定時器所有外設(shè)異常的最隱蔽根源2.1 時鐘樹配置錯誤導(dǎo)致的串口亂碼串口輸出亂碼絕大多數(shù)人第一時間懷疑波特率不對或者檢查電平轉(zhuǎn)換芯片。但我遇到過幾次串口助手里波特率設(shè)得完全正確TTL電平也確實對數(shù)據(jù)愣是亂成一片。最后用示波器看TX引腳的波形發(fā)現(xiàn)每個字節(jié)的位寬都不對——問題出在系統(tǒng)時鐘頻率和庫函數(shù)預(yù)期不一致。STM32的串口波特率是通過系統(tǒng)時鐘分頻得到的如果你用外部8MHz晶振卻把SystemInit里配的PLL倍頻系數(shù)當成了外部25MHz晶振的參數(shù)實際系統(tǒng)時鐘會跑到96MHz而不是72MHz那么串口實際波特率和代碼里設(shè)置的波特率之間就會出現(xiàn)7%左右的偏差。7%的偏差看似不大但對于UART這種用一個位周期采樣的協(xié)議來說已經(jīng)足以導(dǎo)致幀錯誤。排查時鐘樹問題最快的辦法是在調(diào)試會話里打開Peripherals窗口查看RCC時鐘配置寄存器值或者直接在代碼里讀SystemCoreClock全局變量HAL庫里維護著這個值。如果它和預(yù)期不符問題就出在啟動文件的SystemInit調(diào)用鏈上。HAL庫模式下很多人改PLL參數(shù)時只改SystemClock_Config函數(shù)里面的PLLN、PLLM、PLLP但漏掉了stm32f1xx_hal_conf.h中HSE_VALUE的定義——這個宏的值必須和外接晶振頻率一致否則PLL計算值全是錯的。2.2 定時器溢出中斷不觸發(fā)的真相定時器溢出中斷不觸發(fā)一個經(jīng)典原因是定時器時鐘源用的是PCLK1而不是知的分頻系數(shù)。在STM32F1系列上APB1預(yù)分頻系數(shù)如果大于1定時器的時鐘倍頻器會自動把PCLK1乘2作為定時器時鐘。很多人在計算自動重裝載值時忘了這個倍頻導(dǎo)致ARR算的是72MHz的時間但實際定時器跑在36MHz溢出時間變成兩倍。如果你沒有仔細觀察可能只會覺得好像慢了一點點但如果你配置的是極短的時間比如1ms的控制周期那實際變成2msPID控制周期直接錯亂系統(tǒng)表現(xiàn)就完全不對。排查方法也很簡單看 TIMx-PSC 和 TIMx-ARR 的實際值對不對。最好在計算定時器周期時統(tǒng)一走__HAL_TIM_SET_AUTORELOAD這類接口而不要手動改寄存器這樣寄存器值好查代碼也清晰。2.3 定時器PWM輸出莫名消失PWM輸出突然消失排查思路跟上面的定時器中斷類似但多了一個坑PWM輸出引腳的復(fù)用功能AF配錯。STM32的每個定時器通道都有自己的引腳映射比如TIM2_CH1可以映射到PA0也可以映射到PA15重映射。如果你用CubeMX生成代碼這個問題不太容易出現(xiàn)但手動初始化時很容易只配置了GPIO的復(fù)用推挽輸出忘了設(shè)置AFIO的重映射寄存器。最典型的例子是在F103C8T6上想把TIM2_CH1輸出從PA0挪到PA15代碼里沒有打開AFIO-MAPR的TIM2_REMAP位結(jié)果PA15怎么量都沒波形。這個問題多年來不知道害了多少人因為它編譯不會報錯GPIO配置也對但波形就是出不來。我調(diào)試PWM的習慣是先不接負載直接用邏輯分析儀測MCU引腳上的裸波形確認引腳有頻率有占空比再往下接。如果引腳沒波形幾乎可以斷定是GPIO復(fù)用映射或定時器時鐘的問題跟后面的驅(qū)動電路無關(guān)。3. 串口調(diào)試從printf重定向到USB虛擬串口3.1 printf重定向踩過的半主機模式坑串口調(diào)試第一步幾乎都是讓printf通過串口輸出。在Keil MDK環(huán)境里最常見的做法是重定向fputc函數(shù)到USART發(fā)送寄存器但這個過程中有個大坑如果你保留了半主機模式Semihosting相關(guān)的配置程序一跑到printf就死在HardFault或者卡死。半主機模式是ARM調(diào)試器提供的一種機制允許目標板的printf輸出重定向到PC端的調(diào)試器控制臺。在Keil里默認創(chuàng)建的工程可能帶上了半主機支持。你重定向了fputc之后如果還在工程設(shè)置里勾選了微庫MicroLIB并啟用了半主機系統(tǒng)調(diào)用鏈就會走向調(diào)試器而不是你的串口導(dǎo)致單片機在無調(diào)試器狀態(tài)下直接異常。正確重定向printf有幾個關(guān)鍵點在fputc函數(shù)里直接操作USART寄存器不要調(diào)用HAL_UART_Transmit這種可能引起等待計時的函數(shù)否則中斷嵌套會引起死鎖。如果使用MicroLIB需要確保勾選了Use MicroLIB并重定義fputc和fputc依賴的所有底層符號。不勾選MicroLIB時還要實現(xiàn)_sys_exit等函數(shù)避免鏈接器報錯。我自己的習慣是直接用寄存器級發(fā)送單字節(jié)輪詢等待TXE置位簡單可靠int fputc(int ch, FILE *f) { while (!(USART1-SR USART_SR_TXE)); USART1-DR ch; return ch; }寫完之后在main里打印幾行測試字符同時用邏輯分析儀看TX引腳波形確認波特率對應(yīng)關(guān)系正確再繼續(xù)開發(fā)。3.2 USB虛擬串口發(fā)送數(shù)據(jù)的注意事項USB虛擬串口CDC調(diào)試在最新的ST-Link和很多自制調(diào)試板上很常見。這個方式用起來方便但坑也不少。最常見的問題是設(shè)備插入Windows后枚舉為USB輸入設(shè)備而不是COM口。這是因為CDC描述符里缺少了通信類接口的詳細信息或者設(shè)備固件里CDC初始化時序不對。正常初始化流程是USB中斷配置 - 使能USB時鐘 - 調(diào)用CDC_Init - 等D線上拉到低電平再釋放讓主機檢測到設(shè)備插入。很多人用CubeMX生成代碼后發(fā)現(xiàn)枚舉不穩(wěn)定多半是板子上D上拉電阻接到VCC而不是PA0的USB_DISCONNECT引腳控制引腳。F103的USB需要把PA0電平拉高來通知PC有設(shè)備插入如果PA0初始化順序不對插拔后重新枚舉就失敗。還有一個經(jīng)常被忽略的問題是CDC發(fā)送數(shù)據(jù)需要用雙緩沖字節(jié)回傳機制。你把數(shù)據(jù)塞進USB發(fā)送端點后必須等待上一個發(fā)送完成才能填下一個否則端點把數(shù)據(jù)丟棄PC端串口助手就什么都收不到。這個等待其實不是HAL_UART那種輪詢而是HAL_PCD_EP_Transmit返回后緊接著檢查發(fā)送完成標志我一般在主循環(huán)里用一個隊列緩存發(fā)送數(shù)據(jù)發(fā)送完成中斷里再取出下一段。調(diào)試CDC的時候記得用官方串口助手或者Zadig確認驅(qū)動模式Windows自帶的usbser.sys對標準CDC兼容性最好如果設(shè)備枚舉成Unknown Device先別急著改固件試著重裝驅(qū)動。3.3 串口調(diào)試助手的正確打開方式串口調(diào)試助手的選擇和使用看起來很簡單實際上也有不少隱藏問題。很多人一上來就用某個圖形界面串口助手結(jié)果發(fā)現(xiàn)數(shù)據(jù)接收不完整、粘包嚴重以為是程序問題最后發(fā)現(xiàn)是助手的接收緩沖區(qū)配置問題。我把串口調(diào)試工具的使用分成幾個層次簡單應(yīng)用用官方或者第三方的串口調(diào)試助手注意設(shè)置DTR/DSR為默認打開很多嵌入式開發(fā)板的USB轉(zhuǎn)串口芯片比如CH340, 在DTR信號的控制下才會供電。二進制協(xié)議調(diào)試用支持HEX顯示和數(shù)據(jù)保存的助手比如SSCOM、XCOM這類的可以按時間戳保存原始數(shù)據(jù)方便對比收發(fā)時序。復(fù)雜協(xié)議解析用支持腳本或者Lua擴展的工具比如SerialPort Assistant開源版可以在PC端直接解析幀頭、校驗位把解析結(jié)果實時打印極大降低調(diào)試成本。另外網(wǎng)口調(diào)試助手和串口調(diào)試助手是兩個不同的東西很多人做網(wǎng)絡(luò)調(diào)試的時候用串口助手去連TCP端口數(shù)據(jù)發(fā)過去當然沒反應(yīng)。網(wǎng)絡(luò)調(diào)試要用專門的網(wǎng)口助手比如NetAssist、MobaXterm的串口/網(wǎng)絡(luò)會話功能配置好IP和端口才能互發(fā)。我自己調(diào)試數(shù)據(jù)流的時候經(jīng)常同時開兩個工具一個串口助手指向MCU串口一個網(wǎng)口助手指向以太網(wǎng)調(diào)試口這樣可以交叉驗證板子到PC的數(shù)據(jù)鏈路。如果某一個方向的數(shù)據(jù)出現(xiàn)亂碼首先判斷是不是波特率或者TCP包分片問題而不是急著懷疑MCU程序。4. 外設(shè)通訊實戰(zhàn)K210、編碼器與超聲波測距4.1 K210與STM32通訊時的協(xié)議對齊問題K210這種帶AI加速的MCU經(jīng)常和STM32配合用一個做視覺識別一個做控制邏輯。我踩過最深刻的一個坑就是這兩者之間UART通訊明明波特率一樣、電平一樣K210發(fā)過來的數(shù)據(jù)STM32總是解不對。排查發(fā)現(xiàn)K210的UART在某些型號的板子上默認是TTL電平的3.3V但帶K210的開發(fā)板可能集成了電平轉(zhuǎn)換芯片把輸出拉到了5V或者反了信號極性。STM32的GPIO雖然很多是容忍5V的但串口接收引腳如果設(shè)置為浮空輸入電平擺幅過大時可能會觸發(fā)電平檢測的抖動。更重要的坑是字節(jié)序和幀格式。K210的AI框架輸出識別結(jié)果時不同固件打包的協(xié)議差異很大有的用大端法存儲類別ID有的用小端如果你在STM32里用結(jié)構(gòu)體直接解析很容易讀錯字段。我的做法是不直接解析結(jié)構(gòu)體而是先定義一個統(tǒng)一的幀協(xié)議幀頭、長度、數(shù)據(jù)類型、數(shù)據(jù)體、校驗和然后K210端按這個協(xié)議打包STM32端逐字節(jié)解析。這樣即使K210固件更新只要協(xié)議不變主控代碼就不用動。另外K210和STM32之間的UART發(fā)送要特別注意K210的DMA發(fā)送是否需要等待發(fā)送完成。K210的DMA有時候配置了自動循環(huán)模式發(fā)送緩沖區(qū)會被反復(fù)重傳STM32端如果只收一次就會看到重復(fù)的數(shù)據(jù)幀。我的解決方式是在K210端發(fā)完一幀后加一個短延時或者關(guān)閉DMA的循環(huán)模式改用單次發(fā)送。4.2 編碼器讀取亂跳的排查鏈路用STM32的定時器編碼器模式Encoder Mode讀取正交編碼器最煩人的問題就是計數(shù)值亂跳或者靜止時數(shù)據(jù)也在變化。我在項目里遇到過一套電機位置反饋系統(tǒng)編碼器安裝在電機尾部靜止時讀數(shù)在±3個脈沖之間波動噪音非常大。排查鏈路我梳理出了三個層次第一層是電氣干擾。電機驅(qū)動電流變化時會在編碼器線上感應(yīng)出共模噪聲。別看編碼器就幾根線如果和電機電源線綁扎在一起走線噪聲非常致命。解決辦法是編碼器信號使用雙絞屏蔽線屏蔽層單點接地同時加RC濾波器我常用的值是100歐姆串聯(lián)電阻加10nF電容到地把高頻分量壓掉。第二層是計數(shù)器溢出和重載配置。STM32的定時器計數(shù)器是16位如果你配置的編碼器模式是4倍頻計數(shù)高轉(zhuǎn)速下計數(shù)值很快就會溢出。溢出如果不處理計數(shù)值會突然變成負數(shù)或一個很大的正數(shù)上位機看到的就是亂跳。處理方式是用定時器溢出中斷在中斷里對溢出次數(shù)進行累計組成32位的絕對位置。第三層是采樣窗口。很多人直接在主循環(huán)里面讀寄存器值但主循環(huán)的執(zhí)行時間不穩(wěn)定讀取到的位置數(shù)據(jù)看起來就忽大忽小。正確做法是用一個高頻率定時器中斷比如1ms讀取編碼器計數(shù)值并輸出一個穩(wěn)態(tài)值給控制算法。中斷里讀寄存器不會受到主循環(huán)抖動影響讀出來的數(shù)據(jù)才平滑。4.3 超聲波測距不準的調(diào)試日志超聲波測距模塊HC-SR04等和STM32配合使用時最常見的現(xiàn)象是測量值波動大或者偶爾跳變到滿量程。這個問題的根子往往不在代碼而在回波信號質(zhì)量。我在調(diào)試時用邏輯分析儀同時量Trig引腳和Echo引腳對照了真實距離后發(fā)現(xiàn)Trig脈沖寬度對測量的影響比想象中大。HC-SR04要求Trig至少10us的主動高電平如果你用阻塞延時函數(shù)因為主頻不同同樣的延時計數(shù)在STM32F1和F4上差很多發(fā)出的Trig太短模塊根本不會啟動測量。Echo引腳的信號處理也講究。Echo返回的高電平脈寬就是聲波往返時間但如果在環(huán)境嘈雜的車間里Echo引腳可能會收到多重反射產(chǎn)生的虛假信號。我一般不用直接讀引腳電平的阻塞方式而是用定時器輸入捕獲Input Capture模式測量Echo高電平的寬度。輸入捕獲的噪聲過濾功能數(shù)字濾波器能過濾掉短于設(shè)定時間的毛刺實用價值很高。另外值得一提的坑是同一個超聲波模塊供電電壓變化對測距精度影響很大。模塊供電低于5V時發(fā)射功率下降有效測距距離明顯縮短回波信號變?nèi)跞菀壮霈F(xiàn)隨機跳變。我建議用穩(wěn)壓電源單獨給模塊供電不要和舵機或其他大電流器件共用電源。5. 調(diào)試工具與綜合排查從PID調(diào)到VSCode5.1 PID在線調(diào)試的參數(shù)整定思路STM32串口調(diào)試PID很多人在電機控制或者小車上都試過核心痛點就是參數(shù)整定。我先給一個基礎(chǔ)順序先調(diào)比例再調(diào)積分最后調(diào)微分。比例如果過小系統(tǒng)響應(yīng)慢過大會震蕩。積分主要用于消除穩(wěn)態(tài)誤差但積分時間常數(shù)太小會讓響應(yīng)變慢調(diào)節(jié)速度慢微分呢如果濾波沒做好高頻噪聲會放大到輸出端效果非常差。我最推薦的參數(shù)整定流程是先把積分和微分全部置零只給比例從小到大逐次增加觀察響應(yīng)曲線找到臨界振蕩點。記錄臨界振蕩比例和振蕩周期根據(jù)Ziegler-Nichols經(jīng)驗公式初步計算PID參數(shù)。在車上或者電機上驗證把參數(shù)輸入到MCU里通過串口把目標值和實際值發(fā)到PC上的PID在線調(diào)試工具繪制實時曲線。這里要特別提示PID調(diào)試工具不要依賴圖形化的PC軟件做閉環(huán)否則你的調(diào)試結(jié)果和真實嵌入式環(huán)境會有巨大偏差。正確的做法是MCU內(nèi)直接做閉環(huán)PC只負責接收數(shù)據(jù)并繪圖。常見做法是把目標值、實測值、PWM輸出三個變量用結(jié)構(gòu)體打包發(fā)到串口PC端解析后畫曲線。曲線能直觀反映超調(diào)量和響應(yīng)時間比看數(shù)值表格靠譜太多。另外很多人忽略了一個關(guān)鍵點PID的采樣周期必須穩(wěn)定。你在代碼里把采樣周期設(shè)為1ms但如果主循環(huán)里同時處理Display、Key等任務(wù)實際調(diào)用PID的間隔可能浮動到2-3ms控制效果就會不穩(wěn)定。解決方法是把PID控制放在定時器中斷里或者用固定頻率的RTOS任務(wù)讓控制周期嚴格穩(wěn)定。5.2 STM32 VSCode配置的替代方案這兩年大家越來越習慣用VSCode來寫STM32代碼配置Eclipse插件或者PlatformIO但這個過程坑也不少。VSCode加插件后最折磨人的是編譯和下載兩個環(huán)節(jié)的分離VSCode負責編輯代碼底層調(diào)用的還是arm-none-eabi-gcc或者Keil的編譯器你需要額外配置任務(wù)tasks.json和調(diào)試配置launch.json。如果你不想折騰VSCode那套復(fù)雜配置我告訴你一個很務(wù)實的方案用VSCode只做編輯編譯下載依舊交給Keil。在VSCode里裝C/C插件后配置好c_cpp_properties.json的include路徑代碼補全和跳轉(zhuǎn)就非常好用了。需要編譯下載的時候直接用命令行調(diào)用Keil的UV4.exe比如UV4.exe -b project.uvprojx -o build.log這樣可以一鍵完成編譯。下載可以用ST-Link的命令行工具比如ST-LINK_CLI.exe寫一個批處理ST-LINK_CLI.exe -c SWD -p firmware.hex -Rst這套組合下來編輯體驗得到了提升編譯和燒錄又不用放棄Keil的環(huán)境出事的時候回退也方便。如果你確實想用VSCode做全流程開發(fā)用CMake加arm-none-eabi-gcc加上Cortex-Debug插件也算成熟方案但前提是你熟悉CMake語法并且能接受調(diào)試會話里變量監(jiān)視不如Keil方便的現(xiàn)實。5.3 綜合排查方法論高效定位嵌入式問題的思路最后分享一個排查方法論很多人調(diào)試時都是亂猜這里試一下那里試一下效率極低。我總結(jié)的套路是按信號流從源端到宿端逐級排除。比如串口沒數(shù)據(jù)這種問題排查層次是MCU的TX引腳是否有波形 - 電平轉(zhuǎn)換芯片是否正確輸出 - 連接線是否松動 - USB轉(zhuǎn)串口驅(qū)動是否識別 - PC軟件是否接收 - 數(shù)據(jù)協(xié)議是否對齊。每一層都有一個明確的判斷準則用萬用表、示波器、邏輯分析儀逐級確認。這個過程看起來很原始但效率最高比起一上來就懷疑代碼bug先確認物理鏈路和驅(qū)動鏈路都正常能省巨量的時間。另一個重要技巧是善用日志分級。裸機開發(fā)時哪怕沒有RTOS也可以自己做一個極簡的日志系統(tǒng)按錯誤、警告、信息三個等級給日志編號通過串口輸出。調(diào)試時每進入一個函數(shù)就打一條日志定位問題就成了看日志找最后正常點比看代碼邏輯快得多。但注意日志輸出去要減少阻塞等待發(fā)送中斷的日志盡量只記錄關(guān)鍵幀不要每個循環(huán)都刷。最后不要迷信仿真器。很多問題在真實硬件上才會暴露比如上電瞬間的時序、GPIO驅(qū)動的電流、電源紋波對模擬量采樣的影響。仿真器看不出來的問題往往才是整個項目里最致命的問題。所以我的原則是軟件邏輯問題用調(diào)試器看硬件時序和信號完整性問題直接上示波器和邏輯分析儀。最后再分享一個小技巧我調(diào)試STM32時習慣在板子上預(yù)留一個測試點引出PA9/PA10串口和SWD接口旁邊的GND這樣不管程序怎么改只要硬件還在調(diào)試線都能快速接上。這種看似不起眼的細節(jié)在實際項目里能幫你省下大量反復(fù)拆線、焊接的時間。希望這篇文章里記下的這些坑能讓你少走幾步彎路。