1. 項(xiàng)目背景與調(diào)試切入點(diǎn)搞嵌入式開(kāi)發(fā)這些年STM32可以說(shuō)是繞不開(kāi)的一個(gè)平臺(tái)。從剛開(kāi)始拿著開(kāi)發(fā)板點(diǎn)燈到后來(lái)做完整的電機(jī)控制、傳感器采集、通信組網(wǎng)項(xiàng)目幾乎每個(gè)階段都會(huì)碰到各種匪夷所思的問(wèn)題。有些坑是芯片本身的使用姿勢(shì)不對(duì)有些坑純粹是工具鏈用得不熟還有不少坑是代碼邏輯和硬件設(shè)計(jì)糾纏在一起導(dǎo)致的。我一直有記錄調(diào)試筆記的習(xí)慣這次把其中比較有代表性的問(wèn)題整理出來(lái)涵蓋時(shí)鐘配置、串口通信、定時(shí)器中斷、調(diào)試器連接、內(nèi)存管理、電源干擾等幾個(gè)高頻踩坑區(qū)域。文章里涉及的案例都是實(shí)際跑過(guò)的項(xiàng)目不是從文檔里抄出來(lái)的理論每個(gè)問(wèn)題都附帶了現(xiàn)象描述、排查思路和最終的解決辦法。這套經(jīng)驗(yàn)對(duì)剛?cè)腴T(mén)的新手特別有用能幫你少走很多彎路對(duì)已經(jīng)做了一兩年開(kāi)發(fā)的人來(lái)說(shuō)也可以對(duì)照看看有沒(méi)有踩過(guò)類(lèi)似的坑順手補(bǔ)充一些排查技巧。2. 芯片基礎(chǔ)配置階段的常見(jiàn)問(wèn)題2.1 時(shí)鐘樹(shù)配置不當(dāng)引發(fā)的詭異現(xiàn)象時(shí)鐘配置是 STM32 開(kāi)發(fā)的第一個(gè)大坑。很多人習(xí)慣直接照抄參考例程里的 SystemClock_Config 函數(shù)但不同型號(hào)的芯片、不同頻率的外部晶振配置邏輯是有差異的。我遇到過(guò)一個(gè)非常典型的案例某次項(xiàng)目中用了 STM32F103C8T6板子上外部晶振是 8MHz但同事直接復(fù)制了 25MHz 外部晶振的配置代碼。結(jié)果系統(tǒng)上電后串口輸出的數(shù)據(jù)全是亂碼Delay 延時(shí)時(shí)間也明顯不對(duì)用示波器測(cè)量 PWM 波形頻率比預(yù)期值差了整整三倍多。這個(gè)問(wèn)題的本質(zhì)是 PLL 倍頻系數(shù)沒(méi)有根據(jù)實(shí)際晶振頻率調(diào)整。STM32F103 的最高主頻是 72MHz而 PLL 的輸入頻率范圍要求在 2MHz 到 16MHz 之間。用 25MHz 作為 HSE 輸入時(shí)PLL 倍頻系數(shù)是 2 倍也就是 50MHz主頻直接跑低。而用 8MHz 晶振時(shí)需要配置 9 倍頻才能達(dá)到 72MHz。排查這類(lèi)問(wèn)題時(shí)先確認(rèn)兩個(gè)參數(shù)外部晶振的實(shí)際頻率是多少PLL 倍頻系數(shù)是否和目標(biāo)主頻匹配。推薦的做法是在代碼開(kāi)頭加一段 RCC_GetFlagStatus 檢測(cè)確認(rèn) HSE 起振成功后再根據(jù)晶振頻率動(dòng)態(tài)計(jì)算分頻系數(shù)這樣代碼在不同板卡之間移植時(shí)不容易出錯(cuò)。void SystemClock_Config(void) { RCC_OscInitTypeDef RCC_OscInitStruct {0}; RCC_ClkInitTypeDef RCC_ClkInitStruct {0}; RCC_OscInitStruct.OscillatorType RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState RCC_HSE_ON; RCC_OscInitStruct.HSEPredivValue RCC_HSE_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLState RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PLLMUL RCC_PLL_MUL9; // 8MHz * 9 72MHz if (HAL_RCC_OscConfig(RCC_OscInitStruct) ! HAL_OK) { Error_Handler(); } RCC_ClkInitStruct.ClockType RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2; RCC_ClkInitStruct.SYSCLKSource RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider RCC_HCLK_DIV2; RCC_ClkInitStruct.APB2CLKDivider RCC_HCLK_DIV1; HAL_RCC_ClockConfig(RCC_ClkInitStruct, FLASH_LATENCY_2); }順帶提醒一下如果使用內(nèi)部 HSI 時(shí)鐘精度相對(duì)較低做串口通信或者 USB 功能時(shí)容易出現(xiàn)波特率偏差。對(duì)時(shí)序要求嚴(yán)格的應(yīng)用盡量使用外部晶振。2.2 啟動(dòng)文件與芯片型號(hào)不匹配另一個(gè)高頻問(wèn)題是啟動(dòng)文件選錯(cuò)。Keil 工程里 startup_stm32f10x_hd.s、startup_stm32f10x_md.s、startup_stm32f10x_ld.s 分別對(duì)應(yīng)不同容量的芯片很多人圖省事直接復(fù)制整個(gè)工程模板沒(méi)注意芯片容量等級(jí)。這個(gè)問(wèn)題的典型表現(xiàn)是程序下載成功后代碼不跑或者跑起來(lái)后隨機(jī)死機(jī)但編譯時(shí)沒(méi)有任何報(bào)錯(cuò)。原因在于啟動(dòng)文件里定義的堆棧大小、中斷向量表偏移和實(shí)際芯片不匹配導(dǎo)致某些外設(shè)的中斷無(wú)法正確響應(yīng)。我之前還遇到過(guò)一種更隱蔽的情況用了帶 FPU 的 STM32F4 芯片但工程配置里沒(méi)有勾選 Use Single Precision 選項(xiàng)結(jié)果程序一旦執(zhí)行浮點(diǎn)運(yùn)算就進(jìn)入硬件錯(cuò)誤中斷。這類(lèi)問(wèn)題一般出現(xiàn)在 CubeMX 生成的工程被手動(dòng)改動(dòng)過(guò)配置之后解決方法是檢查 C/C 編譯器選項(xiàng)里的目標(biāo)芯片選型和浮點(diǎn)運(yùn)算單元配置。啟動(dòng)文件配置這塊建議花點(diǎn)時(shí)間把不同型號(hào)的差異搞清楚。表格里列一下常用型號(hào)的分類(lèi)方便檢索芯片系列啟動(dòng)文件選擇依據(jù)中斷向量表大小STM32F103C8T6中容量md64 字節(jié)STM32F103RCT6中容量md64 字節(jié)STM32F103ZET6大容量hd128 字節(jié)STM32F407VET6大容量hd128 字節(jié)STM32F429IGT6大容量hd128 字節(jié)實(shí)際上對(duì)于 F4 系列啟動(dòng)文件通常統(tǒng)一用 startup_stm32f40xx.s但部分型號(hào)需要對(duì)應(yīng)到 startup_stm32f429xx.s搞混了就會(huì)出現(xiàn)莫名其妙的啟動(dòng)異常。2.3 Keil 工程配置的幾個(gè)隱蔽選項(xiàng)Keil 雖然用的人最多但里面的坑也不少。最常見(jiàn)的三個(gè)問(wèn)題編譯器優(yōu)化等級(jí)設(shè)置不當(dāng)。有些代碼在 -O0 下正常運(yùn)行一旦把優(yōu)化等級(jí)調(diào)到 -O2 或更高就出現(xiàn)變量莫名被清零、循環(huán)多跑少跑的情況。這是典型的 C 語(yǔ)言未定義行為和編譯器優(yōu)化沖突。比如很多人寫(xiě)延時(shí)函數(shù)時(shí)喜歡用空循環(huán)像一個(gè)簡(jiǎn)單的變量遞減循環(huán)在 -O2 下會(huì)被編譯器整體優(yōu)化掉導(dǎo)致延時(shí)直接失效。解決辦法是定義一個(gè) volatile 變量或者改用 HAL_Delay。另一個(gè)是 MicroLIB 的坑。Keil 里默認(rèn)勾選了 Use MicroLIB 選項(xiàng)它裁剪了標(biāo)準(zhǔn)庫(kù)的一部分功能最典型的影響就是 printf 的浮點(diǎn)輸出。如果代碼里有用 printf 輸出 float 類(lèi)型數(shù)據(jù)勾選 MicroLIB 后可能輸出不了或者輸出錯(cuò)誤的字符而取消這個(gè)選項(xiàng)后固件體積會(huì)大不少。我之前在 F103C8T6 上遇到過(guò) Flash 不足的問(wèn)題就是因?yàn)槿∠?MicroLIB代碼體積從 32KB 漲到了 48KB。后來(lái)是靠調(diào)整 printf 的重定向方式解決的保留 MicroLIB 的同時(shí)用__io_putchar手動(dòng)實(shí)現(xiàn)單字符輸出。還要注意 Include Path 的配置。工程拷給別人后編譯報(bào)錯(cuò)基本都是頭文件路徑缺失導(dǎo)致的。CubeMX 生成的新版工程會(huì)把驅(qū)動(dòng)代碼放在 Drivers 目錄下如果中途手動(dòng)改過(guò)目錄結(jié)構(gòu)一定要同步更新 C/C 選項(xiàng)卡里的 Include Paths。3. 串口通信調(diào)試的實(shí)戰(zhàn)經(jīng)驗(yàn)3.1 打印日志的正確姿勢(shì)串口打印是嵌入式開(kāi)發(fā)最常用的調(diào)試手段但很多人第一步就把路走歪了。我用過(guò)的最省心的方案是重定向 printf 到串口配合串口調(diào)試助手查看輸出。重定向的核心代碼如下不同編譯環(huán)境下略有差異#ifdef __GNUC__ #define PUTCHAR_PROTOTYPE int __io_putchar(int ch) #else #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f) #endif PUTCHAR_PROTOTYPE { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }這里有個(gè)小注意點(diǎn)HAL_UART_Transmit的最后一個(gè)參數(shù) Timeout 不要設(shè)置太短。如果主循環(huán)里頻繁調(diào)用 printf超時(shí)時(shí)間太短會(huì)導(dǎo)致高波特率下丟數(shù)據(jù)。但設(shè)置過(guò)長(zhǎng)又會(huì)在串口被占用時(shí)卡死整個(gè)主循環(huán)。我一般用 100ms 這個(gè)值調(diào)試時(shí)夠用也不會(huì)明顯影響響應(yīng)。另外一個(gè)容易忽視的地方是 GPIO 的復(fù)用功能配置。用了 STM32CubeMX 生成代碼的話它會(huì)自動(dòng)把 PA9、PA10 配置為 USART1 的 TX、RX 引腳。但如果自己寫(xiě)寄存器很多人只配置了 GPIO 模式忘了開(kāi)啟復(fù)用功能串口怎么調(diào)都調(diào)不出來(lái)。檢查 GPIO_InitStruct.Alternate 是否正確賦值這是 F4 系列特別容易犯的錯(cuò)。3.2 串口 DMA 接收的環(huán)形緩沖設(shè)計(jì)項(xiàng)目里如果用串口收發(fā)不定長(zhǎng)數(shù)據(jù)輪詢(xún)接收方式效率太低中斷接收方式在數(shù)據(jù)量大時(shí)又容易丟字節(jié)這時(shí)候就得用 DMA 空閑中斷的方式。關(guān)于空閑中斷老一點(diǎn)的庫(kù)用的是USART_IT_IDLEHAL 庫(kù)則是__HAL_UART_CLEAR_IDLEFLAG。我自己的調(diào)試項(xiàng)目里設(shè)計(jì)了一個(gè)簡(jiǎn)易的環(huán)形緩沖區(qū)來(lái)處理不定長(zhǎng)串口數(shù)據(jù)#define RX_BUFF_SIZE 256 uint8_t rx_buff[RX_BUFF_SIZE]; volatile uint16_t rx_tail 0; volatile uint16_t rx_head 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_tail RX_BUFF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); } } void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { __HAL_UART_CLEAR_OREFLAG(huart); HAL_UART_Receive_DMA(huart, rx_buff, RX_BUFF_SIZE); } }主循環(huán)里處理數(shù)據(jù)時(shí)將rx_head向后移動(dòng)當(dāng)rx_head追上rx_tail時(shí)說(shuō)明數(shù)據(jù)已經(jīng)全部處理完畢。這個(gè)設(shè)計(jì)的核心思路是 DMA 持續(xù)不斷地往緩沖區(qū)寫(xiě)數(shù)據(jù)而 CPU 這邊按自己的節(jié)奏取數(shù)據(jù)兩邊互不阻塞。實(shí)際調(diào)試中遇到的坑是 DMA 半傳輸中斷和傳輸完成中斷的處理不清導(dǎo)致數(shù)據(jù)被重復(fù)讀取。要么在回調(diào)里加保護(hù)標(biāo)志要么直接將 DMA 循環(huán)模式配置為DMA_CIRCULAR且不啟用半傳輸中斷。我第一次做這個(gè)設(shè)計(jì)時(shí)啟用半傳輸中斷后數(shù)據(jù)總是丟一半排查了半天才發(fā)現(xiàn)是回調(diào)里誤操作了緩沖區(qū)指針。3.3 串口調(diào)試助手的選擇與踩坑串口調(diào)試助手這類(lèi)工具市面上一抓一大把但不同工具之間的行為差異很大。某些調(diào)試助手發(fā)送十六進(jìn)制數(shù)據(jù)時(shí)自動(dòng)添加回車(chē)換行如果協(xié)議對(duì)幀格式要求嚴(yán)格這個(gè)自動(dòng)添加的字節(jié)就會(huì)導(dǎo)致協(xié)議解析失敗。我的做法是準(zhǔn)備兩個(gè)工具一個(gè)是在線調(diào)試輔助工具適合快速看數(shù)據(jù)亂不亂另一個(gè)是本地安裝的經(jīng)典工具適合需要發(fā)送自定義幀格式的場(chǎng)景因?yàn)榭梢允謩?dòng)控制發(fā)送的每一個(gè)字節(jié)。另外調(diào)試 USB 虛擬串口時(shí)Windows 驅(qū)動(dòng)偶爾會(huì)出問(wèn)題表現(xiàn)為設(shè)備管理器中識(shí)別到設(shè)備但無(wú)法打開(kāi)串口。這種情況一般需要重新安裝 USB 轉(zhuǎn)串口驅(qū)動(dòng)或者更換一根帶屏蔽層的數(shù)據(jù)線嘗試。USB 虛擬串口VCP這塊有個(gè)很有意思的現(xiàn)象值得單獨(dú)提出來(lái)。很多人第一次用 STM32 自帶的 USB 模塊做虛擬串口時(shí)用串口助手打開(kāi)發(fā)送數(shù)據(jù)一切正常但用自己寫(xiě)的上位機(jī)代碼打開(kāi)同一個(gè)串口卻發(fā)現(xiàn)無(wú)法通信。這可能不是串口配置的問(wèn)題而是上位機(jī)請(qǐng)求的串口參數(shù)波特率、校驗(yàn)位等與固件端 USB 描述符不匹配導(dǎo)致的。虛擬串口本質(zhì)上不依賴(lài)物理波特率但很多上位機(jī)軟件在打開(kāi)串口時(shí)會(huì)發(fā)送波特率設(shè)置請(qǐng)求固件若未正確處理這個(gè)請(qǐng)求設(shè)備就會(huì)處于無(wú)法收發(fā)數(shù)據(jù)的狀態(tài)。在 STM32 的 USB 庫(kù)中處理CDC_SetLineCoding請(qǐng)求時(shí)建議直接忽略參數(shù)內(nèi)容始終按 8N1 方式處理數(shù)據(jù)這樣可以避免這類(lèi)問(wèn)題。4. 定時(shí)器、中斷與實(shí)時(shí)性的坑4.1 定時(shí)器中斷處理耗時(shí)導(dǎo)致的溢出定時(shí)器中斷處理函數(shù)里做太多事情是嵌入式開(kāi)發(fā)最常見(jiàn)的實(shí)時(shí)性問(wèn)題來(lái)源。我之前做一個(gè)步進(jìn)電機(jī)控制的調(diào)試項(xiàng)目時(shí)用 TIM3 的中斷做脈沖計(jì)數(shù)中斷服務(wù)函數(shù)里放了一個(gè)阻塞式的 LCD 刷新操作?，F(xiàn)象是電機(jī)轉(zhuǎn)速稍微一快脈沖計(jì)數(shù)就開(kāi)始丟步整個(gè)系統(tǒng)響應(yīng)變得卡頓。排查后發(fā)現(xiàn)LCD 刷新一次需要大約 8ms而定時(shí)器中斷周期是 1ms。中斷還沒(méi)處理完下一次中斷請(qǐng)求就已經(jīng)到了觸發(fā)定時(shí)器更新中斷溢出。中斷標(biāo)志位沒(méi)有被及時(shí)清除導(dǎo)致計(jì)數(shù)丟失。這類(lèi)問(wèn)題的最佳實(shí)踐是中斷服務(wù)函數(shù)只做標(biāo)記和輕量級(jí)數(shù)據(jù)處理把繁重的工作放到主循環(huán)里處理。用狀態(tài)機(jī)配合一個(gè)event_flag變量中斷里只置位標(biāo)志主循環(huán)檢測(cè)到標(biāo)志后再做耗時(shí)操作。volatile uint8_t event_flag 0; void TIM3_IRQHandler(void) { if (TIM_GetITStatus(TIM3, TIM_IT_Update) ! RESET) { TIM_ClearITPendingBit(TIM3, TIM_IT_Update); event_flag | 0x01; } } void Main_Loop(void) { if (event_flag 0x01) { event_flag ~0x01; LCD_Refresh(); // 耗時(shí)操作放到這里 } }如果確實(shí)需要在中斷里做高優(yōu)先級(jí)處理也要嚴(yán)格控制中斷服務(wù)函數(shù)內(nèi)部的耗時(shí)時(shí)長(zhǎng)。一般建議控制在 20 微秒以?xún)?nèi)超過(guò)這個(gè)量就要考慮用 DMA 或者拆到多個(gè)時(shí)間片去執(zhí)行。4.2 編碼器模式與定時(shí)器輸入捕獲的沖突STM32 的高級(jí)定時(shí)器和通用定時(shí)器功能很豐富能配置成編碼器模式、輸入捕獲模式、PWM 輸出模式等。但同一個(gè)定時(shí)器的多個(gè)通道在某些模式下是有資源沖突的。我在電機(jī)測(cè)速項(xiàng)目里用 TIM2 的編碼器模式讀取 AB 相正交編碼器信號(hào)同時(shí)又想用 TIM2 的通道 3 做一個(gè)頻率測(cè)量。結(jié)果無(wú)論如何配置通道 3 的捕獲值都是亂的頻率測(cè)量結(jié)果完全不可用。查了參考手冊(cè)才明白編碼器模式下定時(shí)器的時(shí)鐘源和計(jì)數(shù)方向完全由編碼器信號(hào)決定此時(shí)定時(shí)器本身已經(jīng)不能再承擔(dān)普通的定時(shí)計(jì)數(shù)功能了通道 3 自然無(wú)法正常工作。正確的方案是編碼器模式獨(dú)占一個(gè)定時(shí)器頻率測(cè)量換用其他定時(shí)器。如果引腳資源不足用外部中斷加 GPIO 模擬測(cè)頻也是一種辦法但要注意外部中斷持續(xù)觸發(fā)時(shí)對(duì) CPU 的占用。4.3 中斷優(yōu)先級(jí)配置不當(dāng)導(dǎo)致系統(tǒng)鎖死中斷優(yōu)先級(jí)這個(gè)坑比想象中隱蔽得多。Cortex-M 內(nèi)核的 NVIC 支持搶占優(yōu)先級(jí)和子優(yōu)先級(jí)如果配置不當(dāng)兩個(gè)中斷之間可能產(chǎn)生不可預(yù)知的嵌套行為。我遇到過(guò)最嚴(yán)重的一次死機(jī)現(xiàn)象開(kāi)啟兩個(gè)外部中斷 EXTI0 和 EXTI1兩個(gè)中斷的搶占優(yōu)先級(jí)設(shè)置成相同數(shù)值但子優(yōu)先級(jí)不同。當(dāng)兩個(gè)中斷同時(shí)觸發(fā)時(shí)系統(tǒng)沒(méi)有按照預(yù)期的順序執(zhí)行而是進(jìn)入了死鎖狀態(tài)。后來(lái)參考了勘誤手冊(cè)和論壇上的討論才意識(shí)到問(wèn)題出在把兩個(gè)中斷的搶占優(yōu)先級(jí)設(shè)為相同值但子優(yōu)先級(jí)設(shè)為不同值這會(huì)導(dǎo)致中斷通道無(wú)法正確響應(yīng)。實(shí)際項(xiàng)目中我的配置原則是需要搶占的中斷優(yōu)先級(jí)必須不同子優(yōu)先級(jí)只在同一搶占級(jí)別內(nèi)部有意義。例如電機(jī)控制中的過(guò)流保護(hù)中斷搶占優(yōu)先級(jí)設(shè)為 0串口接收中斷設(shè)為 1按鍵中斷設(shè)為 2這樣即使在調(diào)試中斷里執(zhí)行長(zhǎng)操作過(guò)流保護(hù)也能立刻打斷。4.4 精準(zhǔn)延時(shí)的幾種實(shí)現(xiàn)方式很多項(xiàng)目需要在跑操作系統(tǒng)的任務(wù)中做微秒級(jí)延時(shí)比如傳感器時(shí)序、通信時(shí)序這時(shí)HAL_Delay明顯不夠用它的精度只有毫秒級(jí)而且被中斷打斷后誤差很大。我在編寫(xiě)超聲波測(cè)距項(xiàng)目的調(diào)試代碼時(shí)就面臨這個(gè)問(wèn)題。超聲波模塊需要一個(gè)至少 10 微秒的觸發(fā)脈沖之后等待回波信號(hào)。如果用HAL_Delay(1)來(lái)驅(qū)動(dòng)觸發(fā)脈沖的寬度就變成了 1ms雖然模塊也能工作但檢測(cè)精度受到了影響。比較可靠的方案是用 DWT 模塊做微秒級(jí)延時(shí)Cortex-M3/M4 內(nèi)核自帶這個(gè)模塊不需要額外占用定時(shí)器static volatile uint32_t *DWT_CYCCNT (uint32_t *)0xE0001004; static volatile uint32_t *DWT_CONTROL (uint32_t *)0xE0001000; static volatile uint32_t *SCB_DEMCR (uint32_t *)0xE000EDFC; void DWT_Delay_Init(void) { *SCB_DEMCR | (1 24); // 使能 TRCENA *DWT_CONTROL | (1 0); // 使能 CYCCNT *DWT_CYCCNT 0; } void DWT_Delay_Us(uint32_t us) { uint32_t start *DWT_CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((*DWT_CYCCNT - start) ticks); }這套方案的好處是精準(zhǔn)度直接取決于系統(tǒng)主頻不占用外設(shè)定時(shí)器資源在 RTOS 環(huán)境中也不會(huì)被調(diào)度器影響。需要注意的是如果主頻很高us * (SystemCoreClock / 1000000)的計(jì)算結(jié)果可能溢出用 uint64_t 做中間變量會(huì)更保險(xiǎn)。5. 調(diào)試下載環(huán)節(jié)的疑難雜癥5.1 連接不上目標(biāo)板的排查思路玩 STM32 的都知道最絕望的時(shí)刻是點(diǎn)擊下載按鈕后Keil 提示 Cannot access Target然后板子就再也沒(méi)有反應(yīng)了。這個(gè)問(wèn)題新手遇到的概率最大原因也是五花八門(mén)。先從最簡(jiǎn)單的排除確認(rèn)調(diào)試器ST-Link 或者 J-Link有沒(méi)有被電腦識(shí)別設(shè)備管理器里能看到對(duì)應(yīng)的端口。然后檢查接線SWD 接口的四個(gè)信號(hào)線是必須的SWDIO、SWCLK、GND、VCC。有時(shí)候 VCC 沒(méi)接也會(huì)導(dǎo)致無(wú)法連接芯片。接下來(lái)在 Keil 的 UTILITIES 選項(xiàng)卡里看 Flash Download 配置是否正確芯片型號(hào)選錯(cuò)也會(huì)報(bào)同樣錯(cuò)誤。如果硬件連接和工程配置都沒(méi)問(wèn)題那還有一個(gè)可能性是芯片已經(jīng)被鎖死。之前調(diào)試時(shí)因?yàn)閷?duì)芯片做讀保護(hù)之后想重新下載程序Keil 便提示無(wú)法連接。解決辦法是按住板子的復(fù)位鍵在點(diǎn)擊下載按鈕的同時(shí)松開(kāi)復(fù)位利用芯片啟動(dòng)瞬間的短暫時(shí)間窗口擦除整個(gè) Flash。ST 官方工具 ST-Link Utility 有整片擦除功能直接用它可以解鎖芯片。但 ST-Link Utility 這個(gè)軟件現(xiàn)在更新得比較慢了在 Windows 11 系統(tǒng)上偶爾會(huì)碰到驅(qū)動(dòng)兼容問(wèn)題。這種情況下可以考慮用 STM32CubeProgrammer它新一些功能也齊全還支持命令行操作方便集成到自動(dòng)化腳本里。5.2 調(diào)試器接口速率與信號(hào)完整性SWD 接口的最高速率能達(dá)到 10MHz但對(duì)于常規(guī)調(diào)試尤其是連接線較長(zhǎng)的情況下跑這個(gè)速率很容易出現(xiàn)連接不穩(wěn)定的問(wèn)題。表現(xiàn)為代碼能下載但程序開(kāi)始運(yùn)行后調(diào)試器偶爾就斷開(kāi)連接重新連接后又恢復(fù)正常。有一次我自己做的一個(gè)項(xiàng)目里用杜邦線連接 ST-Link 和板子接線長(zhǎng)度大概 20 厘米調(diào)試器速率設(shè)置成 10MHz每次跑幾分鐘就斷連。把速率降到了 1MHz 之后跑了一整天也沒(méi)再斷過(guò)。如果你的目標(biāo)板硬件設(shè)計(jì)允許推薦在 SWDIO 引腳上加一個(gè) 100 到 220 歐姆的串聯(lián)電阻在 SWCLK 上加一個(gè) 4.7k 歐姆的下拉電阻這樣可以顯著提升 SWD 接口的抗干擾能力。當(dāng)然最簡(jiǎn)單有效的方法還是縮短杜邦線長(zhǎng)度或者直接用帶有屏蔽層的一體化調(diào)試線。5.3 Win11 環(huán)境下的驅(qū)動(dòng)兼容問(wèn)題Windows 11 系統(tǒng)對(duì)舊版本調(diào)試器驅(qū)動(dòng)的兼容性不太好。ST-Link V1 版本在 Win11 上偶爾會(huì)被系統(tǒng)識(shí)別為未知設(shè)備導(dǎo)致 Keil 無(wú)法找到目標(biāo)芯片。解決方法是使用更新的 ST-Link 驅(qū)動(dòng)或者給 ST-Link V2 單獨(dú)安裝驅(qū)動(dòng)包。需要注意的是Win11 對(duì)驅(qū)動(dòng)的數(shù)字簽名校驗(yàn)很?chē)?yán)格某些自簽名驅(qū)動(dòng)無(wú)法正常安裝。這種情況下可以在開(kāi)機(jī)啟動(dòng)時(shí)選擇禁用驅(qū)動(dòng)簽名強(qiáng)制或者在系統(tǒng)設(shè)置 — 恢復(fù) — 高級(jí)啟動(dòng)中進(jìn)入啟動(dòng)設(shè)置選擇禁用驅(qū)動(dòng)程序強(qiáng)制簽名。J-Link 的情況類(lèi)似老版本的 J-Link 驅(qū)動(dòng)在 Win11 上有已知問(wèn)題表現(xiàn)為連接速度極慢或者頻繁超時(shí)。升級(jí)到新版驅(qū)動(dòng)后基本都能解決。5.4 下載調(diào)試中的代碼優(yōu)化陷阱Debug 模式下程序跑得好好的Release 模式下程序就跑飛了。這個(gè)問(wèn)題我在做編碼器程序調(diào)試時(shí)遇到過(guò)。原因很簡(jiǎn)單調(diào)試模式下編譯器默認(rèn)降低優(yōu)化等級(jí)Release 模式默認(rèn)是高優(yōu)化等級(jí)代碼里某些未定義行為在高優(yōu)化下暴露出來(lái)了。典型例子是volatile關(guān)鍵字的缺失。如果某個(gè)全局變量在中斷函數(shù)和主循環(huán)中同時(shí)被訪問(wèn)但不加volatile修飾編譯器在某些優(yōu)化策略下會(huì)把它加載到寄存器里導(dǎo)致主循環(huán)反復(fù)使用同一個(gè)舊值中斷更新后的值被忽略。// 錯(cuò)誤示例 uint8_t uart_flag 0; void UART_IRQHandler(void) { uart_flag 1; } void main_loop(void) { // 編譯器優(yōu)化后可能永遠(yuǎn)看不到 uart_flag 變成 1 if (uart_flag) { ... } } // 正確示例 volatile uint8_t uart_flag 0;這個(gè)問(wèn)題的本質(zhì)是 C 語(yǔ)言標(biāo)準(zhǔn)中規(guī)定對(duì) volatile 變量的訪問(wèn)不能被優(yōu)化掉每次讀取都必須從內(nèi)存地址重新加載。只要記住中斷和主循環(huán)共享的變量、DMA 緩沖區(qū)相關(guān)標(biāo)志、寄存器映射的結(jié)構(gòu)體指針這三個(gè)場(chǎng)景下用 volatile 是硬性要求。6. 電源、布線與硬件聯(lián)調(diào)6.1 電源紋波導(dǎo)致的 ADC 采樣跳變ADC 采樣值跳變有時(shí)不是代碼的問(wèn)題而是電源紋波在搗鬼。某次我用 STM32F407 做一個(gè)電流采樣項(xiàng)目ADC 采樣值在空載時(shí)就有 ±30 個(gè) LSB 的跳動(dòng)怎么說(shuō)都不對(duì)。用示波器測(cè)量了 3.3V 電源軌紋波高達(dá) 120mV遠(yuǎn)超 ADC 參考電壓的穩(wěn)定要求。解決方式是增加 π 型濾波電路串聯(lián) 10Ω 電阻并聯(lián)兩個(gè) 10μF 鉭電容和 0.1μF 陶瓷電容的組合然后將濾波后的電壓?jiǎn)为?dú)供給到芯片的供電引腳或 MCU 的電源輸入引腳。如果模擬和數(shù)字部分共用一個(gè)電壓源還要考慮在 PCB 上用磁珠或 0Ω 電阻將模擬地和數(shù)字地做星形連接。ADC 采樣本身也可以軟件補(bǔ)償多次采樣取平均值是最容易實(shí)現(xiàn)的方案。但要注意如果信號(hào)本身變化很快過(guò)度的軟件濾波會(huì)帶來(lái)滯后這時(shí)候優(yōu)先解決硬件紋波才是正途。6.2 通信接口的上下拉電阻設(shè)計(jì)STM32 的 I2C 接口屬于開(kāi)漏輸出必須外接上拉電阻才能正常工作。很多人把一個(gè) I2C 傳感器接上去之后發(fā)現(xiàn)通信失敗讀不到寄存器數(shù)據(jù)排查到最后發(fā)現(xiàn)是上拉電阻沒(méi)焊接。關(guān)于上拉電阻阻值的選取有個(gè)經(jīng)驗(yàn)區(qū)間標(biāo)準(zhǔn)模式 100kHz 時(shí)用 10kΩ快速模式 400kHz 時(shí)用 2kΩ 到 4.7kΩ 比較合適。阻值太大上升沿過(guò)緩傳輸速率上不去阻值太小靜態(tài)功耗增大而且驅(qū)動(dòng)能力不夠時(shí)會(huì)把電平拉低。CAN 總線也有類(lèi)似講究CAN_H 和 CAN_L 之間需要接一個(gè) 120Ω 的終端電阻而且是在總線的兩端各接一個(gè)。做 CAN 通信調(diào)試時(shí)如果只在板子上留了一端電阻長(zhǎng)距離通信會(huì)出現(xiàn)波形反射導(dǎo)致數(shù)據(jù)錯(cuò)誤或總線直接進(jìn)入錯(cuò)誤狀態(tài)。6.3 晶振布局與起振失敗外部晶振不起振或者振蕩不穩(wěn)定是新手很容易碰上的一個(gè)硬件問(wèn)題?，F(xiàn)象是程序下載成功但芯片不運(yùn)行程序。如果嘗試斷電重新上電偶爾又能正常工作。原因通常是晶振電路的設(shè)計(jì)不符合規(guī)范。兩個(gè)負(fù)載電容的容值必須和晶振手冊(cè)要求的負(fù)載電容匹配。一個(gè) 8MHz 晶振通常要求 12pF 到 22pF 的負(fù)載電容選錯(cuò)容值會(huì)造成起振困難。此外晶振引腳下面盡量不要走其它信號(hào)線這個(gè)區(qū)域要保持干凈的地平面。調(diào)試時(shí)用示波器測(cè)量晶振引腳的波形可以看到正旋波是否穩(wěn)定。如果波形幅度很小或者頻率明顯偏移優(yōu)先減小負(fù)載電容容值。還有一個(gè)技巧晶振附近的 PCB 走線盡量短實(shí)測(cè)下來(lái)線長(zhǎng)超過(guò) 10mm 后抗干擾能力明顯下降。7. 常用工具鏈搭配的探索與對(duì)比7.1 Keil、STM32CubeMX 與 VSCode 的聯(lián)用方式現(xiàn)在搞 STM32 開(kāi)發(fā)工具鏈的選擇已經(jīng)非常多樣了。我日常的習(xí)慣是先用 STM32CubeMX 生成外設(shè)初始化代碼然后在 Keil 里做編譯調(diào)試偶爾也會(huì)用 VSCode 看代碼、做代碼分析。CubeMX 生成代碼的優(yōu)勢(shì)很明顯外設(shè)時(shí)鐘樹(shù)、GPIO 復(fù)用、中斷優(yōu)先級(jí)這類(lèi)繁瑣事它會(huì)自動(dòng)處理人工配置出錯(cuò)的概率大幅降低。不過(guò)也有它的副作用每次重新生成代碼時(shí)用戶(hù)添加的自定義代碼會(huì)被覆蓋。CubeMX 里保留了用戶(hù)代碼區(qū)USER CODE BEGIN / END 之間的內(nèi)容一定要把自定義初始化代碼放進(jìn)這個(gè)區(qū)域里。VSCode 搭配 EIDE 插件或 CMake 工具鏈可以實(shí)現(xiàn)更順暢的代碼編寫(xiě)和 Git 集成體驗(yàn)代碼補(bǔ)全、格式化、靜態(tài)檢查都比 Keil 自帶的編輯器舒服不少。但是編譯調(diào)試還是可以回到 Keil兩邊互補(bǔ)使用。7.2 從 STD 庫(kù)遷移到 HAL 庫(kù)老工程師基本都是從標(biāo)準(zhǔn)外設(shè)庫(kù)STD 庫(kù)過(guò)來(lái)的現(xiàn)在官方主推 HAL 庫(kù)。兩者風(fēng)格差異很大STD 庫(kù)是直接操作寄存器的方式HAL 庫(kù)封裝程度更高提供了更上層的 API。遷移過(guò)程中最需要適應(yīng)的是初始化方式。STD 庫(kù)里寫(xiě) GPIO 配置需要自己構(gòu)造 GPIO_InitTypeDef 然后調(diào)用 GPIO_Init而 HAL 庫(kù)需要先使能時(shí)鐘再調(diào)用 HAL_GPIO_Init 并傳入 GPIO 引腳、模式、速度等參數(shù)。邏輯類(lèi)似但函數(shù)名和參數(shù)結(jié)構(gòu)變化很大。我從 STD 庫(kù)遷移到 HAL 庫(kù)時(shí)有幾個(gè)體會(huì)。第一不要在中斷回調(diào)里做耗時(shí)處理HAL 庫(kù)的 UART 接收中斷是需要重新觸發(fā)下一次接收的忘了重新調(diào)用 HAL_UART_Receive_IT 的話數(shù)據(jù)就停在那里不動(dòng)了。這個(gè)坑很多從 STD 庫(kù)轉(zhuǎn)過(guò)來(lái)的人都踩過(guò)。第二熟悉 HAL 庫(kù)的句柄結(jié)構(gòu)體對(duì)排查問(wèn)題幫助很大很多問(wèn)題的根源都在句柄配置錯(cuò)誤上。7.3 調(diào)試打印的輕量級(jí)實(shí)現(xiàn)方案printf 雖然好用但有體積和性能的代價(jià)。如果你用的是 Flash 和 RAM 都比較緊張的芯片就要考慮輕量級(jí)日志方案了。一種方式是用snprintf格式化字符串到局部緩沖區(qū)然后一次性通過(guò)串口 DMA 發(fā)送。相比逐字符發(fā)送DMA 方式可以大幅降低 CPU 占用率。如果調(diào)試信息不需要在正式固件中出現(xiàn)還可以用宏定義做條件編譯#ifdef DEBUG_ENABLE #define LOG_INFO(fmt, ...) printf([INFO] fmt \r\n, ##__VA_ARGS__) #define LOG_ERROR(fmt, ...) printf([ERROR] fmt \r\n, ##__VA_ARGS__) #else #define LOG_INFO(fmt, ...) #define LOG_ERROR(fmt, ...) #endif這種方式在調(diào)試階段可以很方便地打開(kāi)正式發(fā)布時(shí)把DEBUG_ENABLE宏注釋掉日志代碼就全部從二進(jìn)制中移除不會(huì)占用任何資源。8. 通信協(xié)議調(diào)試的實(shí)用技巧8.1 狀態(tài)機(jī)解析與幀同步恢復(fù)串口通信的協(xié)議解析最好用狀態(tài)機(jī)來(lái)實(shí)現(xiàn)而不是簡(jiǎn)單的字符判斷堆疊。我之前做一個(gè)基于 STM32 的傳感器采集項(xiàng)目時(shí)用了一個(gè)簡(jiǎn)單的 State-Action-Response 狀態(tài)機(jī)來(lái)處理幀結(jié)構(gòu)typedef enum { FRAME_IDLE, FRAME_HEADER, FRAME_LENGTH, FRAME_DATA, FRAME_CHECK } frame_state_t; frame_state_t state FRAME_IDLE; uint8_t frame_buff[64]; uint8_t frame_len 0; void UART_Parse_Byte(uint8_t data) { switch (state) { case FRAME_IDLE: if (data 0xAA) state FRAME_HEADER; break; case FRAME_HEADER: frame_len data; frame_buff[0] data; if (frame_len 64) state FRAME_IDLE; else state FRAME_DATA; frame_len 0; break; case FRAME_DATA: frame_buff[frame_len] data; if (frame_len frame_buff[0]) state FRAME_CHECK; break; default: state FRAME_IDLE; break; } }這類(lèi)狀態(tài)機(jī)實(shí)現(xiàn)有幾個(gè)細(xì)節(jié)要處理好。幀頭校驗(yàn)不能只判斷第一個(gè)字節(jié)一個(gè)好的設(shè)計(jì)會(huì)加入幀頭和幀尾的雙重校驗(yàn)。接收到的數(shù)據(jù)長(zhǎng)度要嚴(yán)格控制防止惡意數(shù)據(jù)包導(dǎo)致緩沖區(qū)溢出。校驗(yàn)失敗的處理邏輯很重要不要簡(jiǎn)單丟棄然后回空閑態(tài)更好的方式是記錄錯(cuò)誤計(jì)數(shù)并嘗試在下一個(gè)可能位置重新同步。幀同步恢復(fù)是我實(shí)際調(diào)試中踩過(guò)的一個(gè)大坑。通信鏈路偶爾出現(xiàn)一個(gè)字節(jié)的錯(cuò)誤后續(xù)所有幀數(shù)據(jù)都解析失敗表現(xiàn)為主機(jī)一直收不到有效數(shù)據(jù)包。原因是狀態(tài)機(jī)在收到錯(cuò)誤數(shù)據(jù)后跳轉(zhuǎn)到空閑態(tài)時(shí)沒(méi)有正確消耗掉當(dāng)前字節(jié)導(dǎo)致接下來(lái)的正確數(shù)據(jù)無(wú)法被識(shí)別為幀頭。修正方式是在空閑態(tài)收到非幀頭數(shù)據(jù)時(shí)繼續(xù)停留空閑態(tài)等待而不是直接退出整個(gè)解析流程。8.2 串口數(shù)據(jù)丟幀的排查流程串口通信不定期丟數(shù)據(jù)可以從下面幾個(gè)方向排查波特率誤差。STM32 的 USART 波特率發(fā)生器是有一個(gè)分頻公式的當(dāng)所需波特率不是整數(shù)倍分頻時(shí)會(huì)存在誤差。對(duì)于 115200 波特率在 72MHz 主頻下理論誤差很小但如果你把主頻通過(guò) PLL 設(shè)置為非標(biāo)準(zhǔn)頻率誤差就會(huì)明顯增大。接收中斷處理時(shí)間過(guò)長(zhǎng)。如果在 UART 接收中斷里做太多工作可能導(dǎo)致下一字節(jié)到達(dá)時(shí)中斷還沒(méi)來(lái)得及退出硬件的接收寄存器被覆蓋數(shù)據(jù)丟失。用 DMA 接收是更穩(wěn)妥的方案。線材質(zhì)量。長(zhǎng)距離串口通信用普通杜邦線抗干擾能力很差。改用屏蔽雙絞線后可以減少很多隨機(jī)丟幀的問(wèn)題。更重要的是在軟件上做好接收緩沖保護(hù)。我之前調(diào)試時(shí)在接收中斷里直接處理協(xié)議解析業(yè)務(wù)導(dǎo)致業(yè)務(wù)邏輯稍微一卡就丟數(shù)據(jù)。后來(lái)改成中斷只做數(shù)據(jù)入隊(duì)把協(xié)議解析放到主循環(huán)的任務(wù)里執(zhí)行丟幀的問(wèn)題就消失了。8.3 網(wǎng)絡(luò)通信與 UDP 調(diào)試的注意點(diǎn)很多 STM32 項(xiàng)目開(kāi)始用以太網(wǎng)功能了用 W5500 這類(lèi)芯片實(shí)現(xiàn) UDP 通信調(diào)試時(shí)又有一批新坑。UDP 本身是無(wú)連接協(xié)議調(diào)試起來(lái)比 TCP 簡(jiǎn)單但也正因?yàn)闊o(wú)連接出現(xiàn)問(wèn)題時(shí)更難排查。我在調(diào)試時(shí)遇過(guò)的一個(gè)典型問(wèn)題STM32 的 UDP 客戶(hù)端發(fā)送數(shù)據(jù)給上位機(jī)軟件上位機(jī)能收到數(shù)據(jù)但上位機(jī)發(fā)送數(shù)據(jù)給設(shè)備時(shí)設(shè)備端完全沒(méi)反應(yīng)。排查后發(fā)現(xiàn)設(shè)備端雖然綁定了正確的本地端口號(hào)但上位機(jī)發(fā)送的源端口號(hào)不在設(shè)備的允許接收范圍內(nèi)。UDP 通信中設(shè)備端需要知道上位機(jī)的 IP 和端口才能回復(fù)數(shù)據(jù)如果上位機(jī)每次用不同端口發(fā)送設(shè)備端在初始化時(shí)只綁定了一次通信端點(diǎn)后續(xù)就無(wú)法收到來(lái)自新端口的數(shù)據(jù)。解決辦法是設(shè)備端動(dòng)態(tài)記錄收到的最后一個(gè)數(shù)據(jù)包的源 IP 和端口回復(fù)時(shí)用這個(gè)地址?；蛘哂脧V播模式配合端口約定來(lái)規(guī)避這個(gè)問(wèn)題。以太網(wǎng)物理層調(diào)試最容易出現(xiàn)的問(wèn)題是網(wǎng)口變壓器的中心抽頭電平不匹配。DP83848 這類(lèi) PHY 芯片對(duì)差分信號(hào)的共模電壓有要求如果中心抽頭接錯(cuò)就會(huì)導(dǎo)致鏈路始終起不來(lái)。這個(gè)問(wèn)題的排查特征是網(wǎng)口指示燈不亮或者閃個(gè)不停用示波器測(cè)量 RMII 接口的 TX 時(shí)鐘可以發(fā)現(xiàn)根本沒(méi)有時(shí)鐘輸出。9. 常見(jiàn)問(wèn)題排查速查表為了便于快速定位問(wèn)題我把這些年調(diào)試中遇到的典型失敗模式整理成了表格方便大家直接對(duì)照問(wèn)題現(xiàn)象可能原因排查方向程序下載后無(wú)法運(yùn)行啟動(dòng)文件與芯片容量不匹配檢查工程所用啟動(dòng)文件型號(hào)程序下載后無(wú)法運(yùn)行外部晶振未起振示波器測(cè)量 OSC_IN / OSC_OUT芯片無(wú)法連接調(diào)試器芯片進(jìn)入讀保護(hù)狀態(tài)ST-Link Utility 整片擦除芯片無(wú)法連接調(diào)試器SWD 線序接反檢查 SWDIO / SWCLK 接線串口輸出亂碼時(shí)鐘頻率與初始化配置不一致確認(rèn) HSE 頻率與 PLL 倍頻系數(shù)串口輸出亂碼波特率誤差過(guò)大用示波器實(shí)測(cè)發(fā)送端波形串口輸出亂碼調(diào)試助手發(fā)送設(shè)置不符檢查 HEX / ASCII 發(fā)送模式ADC 采集跳動(dòng)大電源紋波過(guò)高示波器測(cè)量電源軌ADC 采集跳動(dòng)大采樣時(shí)間設(shè)置過(guò)短增加采樣周期時(shí)間ADC 采集跳動(dòng)大參考電壓不穩(wěn)定檢查 VREF 引腳濾波電路定時(shí)器計(jì)數(shù)不準(zhǔn)中斷處理時(shí)間過(guò)長(zhǎng)縮短中斷服務(wù)函數(shù)代碼定時(shí)器計(jì)數(shù)不準(zhǔn)定時(shí)器分頻配置錯(cuò)誤核對(duì) PSC / ARR 數(shù)值中斷觸發(fā)無(wú)響應(yīng)NVIC 優(yōu)先級(jí)配置沖突檢查搶占優(yōu)先級(jí)設(shè)定DMA 傳輸卡死未使能 DMA 中斷或未重新觸發(fā)檢查 DMA 中斷配置浮點(diǎn)運(yùn)算死機(jī)未開(kāi)啟 FPU檢查編譯選項(xiàng)與啟動(dòng)文件I2C 通信失敗上拉電阻缺失或阻值不對(duì)檢查外部電路SPI 讀數(shù)據(jù)全 FF時(shí)鐘極性和相位不匹配檢查 CPOL / CPHA 配置CAN 無(wú)法通信終端電阻缺失檢查總線兩端 120Ω 電阻10. 幾個(gè)值得養(yǎng)成的調(diào)試習(xí)慣文章的最后分享幾個(gè)我這些年總結(jié)出來(lái)的、能實(shí)實(shí)在在提升調(diào)試效率的小習(xí)慣。第一調(diào)試時(shí)把工程里的優(yōu)化等級(jí)固定在 -O0等所有功能測(cè)試通過(guò)后再調(diào)整為需要的優(yōu)化等級(jí)做驗(yàn)證。不要在調(diào)試階段就開(kāi)高優(yōu)化不然代碼出問(wèn)題后還要糾結(jié)是不是優(yōu)化器的問(wèn)題排查成本直接翻倍。第二寫(xiě)日志時(shí)統(tǒng)一加上時(shí)間戳或者幀計(jì)數(shù)。這樣在分析日志時(shí)可以清楚地看到數(shù)據(jù)發(fā)生的時(shí)間間隔定位問(wèn)題是周期性出現(xiàn)的還是偶發(fā)性的。我一般用系統(tǒng)滴答定時(shí)器作為時(shí)間基準(zhǔn)在日志初始化和串口初始化后每次打印前更新那個(gè)計(jì)數(shù)變量這樣每個(gè)日志條目前都能顯示精確到毫秒的時(shí)間。第三做硬件調(diào)試時(shí)養(yǎng)成先測(cè)電源的習(xí)慣。很多時(shí)候軟件怎么查都找不到原因的詭異問(wèn)題最后都是硬件電源引起的。上電后第一件事用萬(wàn)用表量每個(gè)電源軌的電壓用示波器看紋波確保不欠壓、不過(guò)壓、紋波在可接受范圍內(nèi)再繼續(xù)調(diào)試其他部分。第四也是最重要的一點(diǎn)遇到問(wèn)題先記錄現(xiàn)象完整復(fù)現(xiàn)之后再做修改。很多人調(diào)試時(shí)發(fā)現(xiàn)一個(gè)可能的問(wèn)題就立刻改代碼改完發(fā)現(xiàn)好了但不知道具體是哪個(gè)改動(dòng)起了作用。我自己的經(jīng)歷證明做調(diào)試筆記、記錄每次修改的內(nèi)容和結(jié)果看起來(lái)費(fèi)時(shí)間實(shí)際上可以大幅減少重復(fù)勞動(dòng)尤其是那種需要來(lái)回嘗試才能定位的疑難雜癥效果非常明顯。11. 個(gè)人調(diào)試體會(huì)與收尾最后再多說(shuō)一點(diǎn)體會(huì)。STM32 調(diào)試這件事與其說(shuō)是在查代碼不如說(shuō)是在做系統(tǒng)性的排查。很多問(wèn)題表面上看是代碼邏輯錯(cuò)誤深入一查發(fā)現(xiàn)是硬件設(shè)計(jì)缺陷再往下挖甚至可能是工具鏈配置問(wèn)題。所以每次遇到問(wèn)題時(shí)先別急著改代碼把問(wèn)題現(xiàn)象記錄完整按類(lèi)別排查把各種可能性按概率排序一條一條確認(rèn)這是最高效的方法。在我調(diào)試過(guò)的所有板子里印象最深的還是第一次用 STM32F103 做串口通信時(shí)被亂碼折騰了整整三天。后來(lái)發(fā)現(xiàn)是 GPIO 復(fù)用功能沒(méi)配置對(duì)一個(gè)函數(shù)調(diào)用的問(wèn)題。從那以后我每次看官方參考手冊(cè)和例程代碼都格外仔細(xì)而且把關(guān)鍵初始化流程都熟記于心。這個(gè)習(xí)慣幫我在后續(xù)的使用中少踩了很多坑。調(diào)試是一個(gè)積累的過(guò)程每一次坑都是經(jīng)驗(yàn)。希望這篇總結(jié)能幫你在 STM32 開(kāi)發(fā)調(diào)試的路上少走一些彎路也歡迎大家在實(shí)際調(diào)試中不斷總結(jié)新的心得。