1. 初遇問題從機發(fā)給主機的數(shù)據(jù)全是 0xFF先說結(jié)論SPI 從機 DMA 模式下連續(xù)輸出 0xFF本質(zhì)上就是“從機根本沒把有效數(shù)據(jù)放到 MISO 線上”。這個問題不是 STM32H7 獨有的F1、F4、G4 系列也會遇到但在 H7 上更容易踩坑原因是 H7 的 SPI 和 DMA 架構(gòu)跟老一代芯片相比做了不少改動網(wǎng)上的老經(jīng)驗很多不能直接套用。我調(diào)試這塊板子時用的是 STM32CubeMX 生成工程SPI 從機配置為主機讀取外部傳感器數(shù)據(jù)的應(yīng)答端。主機 SPI 時鐘 4MHzCPOL Low、CPHA 1Edge數(shù)據(jù)幀 8bitMSB First。從機端開了 DMA 發(fā)送DMA 通道配置為內(nèi)存到外設(shè)方向數(shù)據(jù)長度 256 字節(jié)。結(jié)果一跑起來主機通過 SPI 讀回來的數(shù)據(jù)流是FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ...一眼望過去全是 0xFF而且是穩(wěn)定、連續(xù)、一個有效字節(jié)都沒有的 0xFF。這跟我預(yù)期的“偶發(fā)錯誤”完全不一樣——偶發(fā)錯誤一般會夾雜幾個正確字節(jié)而全 FF 是另一種信號從機根本沒在總線上驅(qū)動數(shù)據(jù)。為什么這么說因為 SPI 總線在沒有設(shè)備驅(qū)動 MISO 的時候線路默認電平取決于外部上拉/下拉電阻。多數(shù)板子的 MISO 線在空閑時是弱上拉主機讀到的就是高電平也就是 0xFF。換句話說MISO 一直是被動的“空”狀態(tài)而不是從機在主動發(fā)送有效數(shù)據(jù)。這個現(xiàn)象特別迷惑人的地方在于你明明配置了 DMA明明調(diào)用了HAL_SPI_Transmit_DMA()函數(shù)返回也是HAL_OK甚至HAL_SPI_TxCpltCallback都在跑——但總線上的數(shù)據(jù)依然全是 FF。這說明問題不在“DMA 有沒有搬數(shù)據(jù)”而在于SPI 外設(shè)的發(fā)送通道根本沒有把數(shù)據(jù)送到 MISO 上去。這一條思路如果能在一開始就建立起來排查方向就不會跑偏。下文按“先從物理層和配置層確認再深入?yún)f(xié)議層和 DMA 架構(gòu)最后結(jié)合軟件棧逐層排雷”的順序把這幾天踩過的坑和解決辦法完整梳理一遍。文章涉及的代碼均在 STM32CubeIDE 1.13 以上版本 STM32CubeH7 1.11 環(huán)境中驗證過SPI 時鐘最高測到 8MHzDMA 數(shù)據(jù)長度從 16 字節(jié)到 1K 字節(jié)都能穩(wěn)定工作。2. 先搞清楚 0xFF 是誰產(chǎn)生的物理層判斷與定位2.1 SPI 空閑電平和 MISO 的“懸空”狀態(tài)SPI 從機不驅(qū)動總線時MISO 引腳通常處于高阻態(tài)Hi-Z。主機側(cè)如果不帶下拉電阻讀到的電平就是不確定的。實際開發(fā)板上MISO 往往被主機內(nèi)部上拉或者板載電阻拉到了高電平于是讀到的字節(jié)就是 0xFF。這個推論可以用一個最簡單的實驗驗證把從機程序停掉或者干脆不初始化 SPI 外設(shè)主機依然能讀回 0xFF。如果停掉從機后主機讀到的還是 FF那就證明 0xFF 并非從機主動產(chǎn)生而是總線空閑電平被讀了出來。所以這里有一個很重要的調(diào)試習慣看到滿屏 0xFF先別急著查代碼邏輯先用“有沒有可能從機壓根沒驅(qū)動 MISO”這個角度去思考。我見過不少同事折騰 DMA 半天最后發(fā)現(xiàn)是 SPI 外設(shè)的 TXE 標志位就沒置位過數(shù)據(jù)根本沒往移位寄存器里送。2.2 如何用示波器確認從機到底有沒有動作排查這類問題強烈建議把示波器探針夾到從機的 MISO 引腳比如 Nucleo-H753ZI 板子的 PA6具體看你自己用什么引腳。觀察點在主機發(fā)起 SPI 傳輸時MISO 上有沒有電平翻轉(zhuǎn)動作。判斷邏輯很簡單觀察到的現(xiàn)象說明什么問題MISO 持續(xù)為高/低完全不翻轉(zhuǎn)SPI 外設(shè)或 DMA 完全沒有發(fā)送動作MISO 在時鐘啟動后有電平翻轉(zhuǎn)但數(shù)據(jù)符號不對數(shù)據(jù)是發(fā)出去了但字節(jié)內(nèi)容有誤MISO 只有 CS 拉低瞬間有電平變化SCK 來了之后沒變化從機沒有被正確選通或者 CS 檢測邏輯有問題MISO 翻轉(zhuǎn)頻率和 SCK 完全對應(yīng)但主機讀的還是 FF波形可能是對的主機側(cè)采樣參數(shù)不匹配如果示波器顯示 MISO 完全沒有翻轉(zhuǎn)那就說明問題出在從機側(cè)的發(fā)送鏈路里跟主機側(cè)怎么配置沒關(guān)系。這時候可以縮小范圍把“SPI - DMA - 內(nèi)存”這條鏈路的每個環(huán)節(jié)單獨拉出來測。2.3 最簡單的“寫寄存器”測試法在深入 DMA 之前建議先做一個最粗暴的試驗不走 DMA直接在 SPI 發(fā)送中斷或者輪詢模式下向 SPI 的發(fā)送數(shù)據(jù)寄存器寫幾個固定字節(jié)。如果這時 MISO 上能出來數(shù)據(jù)說明 SPI 外設(shè)本身沒問題如果還是不輸出那就是 SPI 配置的問題。這個測試在 H7 上特別有效因為 H7 的 SPI 用了新的寄存器組和 F1/F4 系列差異很大不能盲目參考老代碼。我當時的做法是在main()里初始化完 SPI 外設(shè)后把 DMA 相關(guān)代碼全部注釋掉直接調(diào)用一次HAL_SPI_Transmit(hspi1, testData, 8, 1000)。注意這個函數(shù)在從機模式下是“阻塞等待主機時鐘”的主機不發(fā)時鐘函數(shù)就一直卡在那里。如果你在調(diào)試器里看到程序停在函數(shù)內(nèi)部而主機那邊確實沒有發(fā)起讀操作那其實是正?，F(xiàn)象不是死機。當主機發(fā)起一次讀時序后如果 MISO 上能讀到0x01 0x02 0x03 ...這種有規(guī)律的數(shù)據(jù)說明 SPI 硬件鏈路是完全通的。這個時候再把 DMA 加回去如果數(shù)據(jù)又變回 FF那問題就鎖定在 DMA 配置和 SPI-DMA 交互這一層。說到這我想插一句網(wǎng)上很多帖子一上來就讓人查 DMA 的優(yōu)先級、FIFO 閾值、突發(fā)模式這些參數(shù)當然重要但如果物理層都沒通調(diào)這些參數(shù)純屬浪費時間。所以我的默認排查順序永遠是物理層 - 寄存器層 - 外設(shè)配置層 - DMA 層 - 軟件棧層逐層縮小范圍。3. SPI 從機配置的隱形雷區(qū)參數(shù)匹配與 NSS 管理3.1 CPOL/CPHA 主從不匹配數(shù)據(jù)移出但主機讀錯如果物理層已經(jīng)確認 MISO 有翻轉(zhuǎn)但主機的邏輯分析儀讀到的還是 FF那首先要懷疑的就是 CPOL/CPHA 主從不匹配。SPI 有四種模式組合主機和從機必須完全一致否則數(shù)據(jù)移位時機對不上從機發(fā)出去的數(shù)據(jù)主機根本采不到。H7 的 SPI 初始化結(jié)構(gòu)體中有SPI_InitTypeDef關(guān)鍵參數(shù)是hspi1.Init.CLKPolarity SPI_POLARITY_LOW; // CPOL 0 hspi1.Init.CLKPhase SPI_PHASE_1EDGE; // CPHA 0我這次用到的組合是 CPOL Low、CPHA 1Edge。如果你的主機是別的模式從機必須完全對應(yīng)。常見錯誤是把從機配置成 CPHA 2Edge導(dǎo)致主機在第一個邊沿采樣時 MISO 上的數(shù)據(jù)還沒穩(wěn)定讀到的就是 FF。這里有一個實操技巧把 CubeMX 里的 SPI 參數(shù)配置截圖發(fā)給主機的開發(fā)者兩個人對照著確認。因為“時鐘極性低電平”和“第一個時鐘邊沿采集數(shù)據(jù)”這種描述在不同文檔里叫法不太一樣有的叫“Mode 0”有的叫“CPOL0 CPHA0”對照確認可以避免雞同鴨講。3.2 數(shù)據(jù)幀格式位寬、MSB/LSB 和字節(jié)順序H7 的 SPI 支持 4bit 到 32bit 的數(shù)據(jù)幀長度從機和主機的DataSize必須一致。CubeMX 默認是 8bit這塊一般不容易錯。但有一個很容易忽略的點是FirstBit——如果主機是 MSB First從機配成了 LSB First那主機讀到的每一個字節(jié)都會是反序的。比如從機想發(fā) 0x01二進制 0000 0001LSB First 發(fā)出去變成 0x801000 0000主機如果按 MSB 解析讀到的就是 0x80 而不是 0x01。另外H7 的 SPI 還支持FIFO接收/發(fā)送緩沖FIFO 閾值可以通過HAL_SPI_Init()之后的底層配置寄存器調(diào)整。在 DMA 模式下FIFO 閾值會影響 DMA 請求的觸發(fā)時機。默認配置下一般沒問題但如果你的收發(fā)數(shù)據(jù)長度不是 FIFO 深度的整數(shù)倍尾部數(shù)據(jù)可能會卡住。這個后面在 DMA 章節(jié)詳細說。3.3 硬件 NSS 與軟件 NSS選通信號沒拉低從機永遠在“隱身”這是我從機場景里踩得最隱蔽的一個坑。Nucleo-H753ZI 的 SPI 從機如果使用硬件 NSS 模式NSS SPI_NSS_HARD_INPUT從機必須檢測到 NSS 引腳被拉低才會把 MISO 切換為輸出驅(qū)動狀態(tài)。如果你的主機和從機之間沒有連接 NSS 引腳——比如只接了 SCK、MISO、MOSI、GND 四根線——那么從機的 NSS 引腳就懸空或保持高電平從機永遠不會被選通MISO 一直處于高阻態(tài)主機讀到的自然全是 0xFF。解決辦法有兩個方案一使用硬件 NSS。確保從機的 NSS 引腳接到了主機的 CS片選引腳并且在 CubeMX 中把 NSS 配置為硬件模式。硬件 NSS 的優(yōu)點是片選信號完全由主機控制從機硬件自動檢測不需要軟件干預(yù)。缺點是需要多接一根線而且 SPI 外設(shè)的 NSS 引腳一般是固定映射的在 H753ZI 上是 PA4不能隨便換。方案二使用軟件 NSS。把 SPI 的 NSS 配置為軟件模式SPI_NSS_SOFT然后在發(fā)送數(shù)據(jù)前手動拉低 NSS 引腳。不過這里有個容易誤解的地方軟件 NSS 模式下很多教程讓你直接操作 GPIO 拉低 NSS 引腳電平但從機側(cè)真正起作用的是 SPI 外設(shè)內(nèi)部的一個SSIInternal Slave Select位而不是 GPIO 的外部電平。在 STM32H7 上軟件 NSS 的從機配置通常是這樣hspi1.Init.NSS SPI_NSS_SOFT; // ... 初始化 ... // 發(fā)送前使能內(nèi)部從機選擇 SET_BIT(hspi1.Instance-CFG1, SPI_CFG1_SSI);我實測過這個SSI位如果不置 1就算你把外部 GPIO 拉低SPI 從機照樣不會響應(yīng)。這也是很多人明明接對了線從機卻毫無反應(yīng)的原因之一。CubeMX 生成代碼默認不會幫你設(shè)置這個位需要手動加一行。注意軟件 NSS 模式下SSI位的置位時機要在使能 SPI 之前還是之后H7 參考手冊里沒有特別強調(diào)。我反復(fù)試過在__HAL_SPI_ENABLE(hspi1)之后設(shè)置同樣有效而且如果發(fā)送過程中 NSS 被拉高再拉低SSI位不會自動清掉所以不用擔心下次傳輸前要重新置位。3.4 從機模式下的通信時鐘缺失問題還有一個從機模式特有的現(xiàn)象值得單獨提出來從機發(fā)送數(shù)據(jù)是完全依賴主機時鐘的。也就是說即便你把從機的 DMA 配置得再完美如果主機不發(fā)起 SPI 時鐘從機的發(fā)送數(shù)據(jù)就永遠不會從移位寄存器里移出去。這一點在調(diào)試時容易產(chǎn)生誤判你從代碼層面看HAL_SPI_Transmit_DMA()返回了HAL_OK以為數(shù)據(jù)已經(jīng)開始發(fā)了實際上 DMA 只是把數(shù)據(jù)從內(nèi)存搬到了 SPI 外設(shè)的 TX 緩沖區(qū)真正的移位發(fā)送要等主機時鐘來了才會發(fā)生。如果你在從機代碼里打斷點查看 DMA 計數(shù)寄存器可能會發(fā)現(xiàn)計數(shù)從 256 變到了 0但這只代表數(shù)據(jù)進了外設(shè)緩沖不代表已經(jīng)發(fā)出去了。所以排查時一定要確認主機那邊確實在發(fā)起傳輸。我這次就是因為主機程序里讀操作被一個延時卡住了導(dǎo)致主機根本沒發(fā)時鐘從機也就一直在“等待”狀態(tài)看起來像是從機壞了。把主機那邊的邏輯理順之后數(shù)據(jù)馬上正常了。4. H7 的 SPI 與 DMA 交互被低估的架構(gòu)變化4.1 STM32H7 的 DMAMUX請求映射不再是固定綁定這是 H7 系列和老一代 STM32 在 DMA 方面最大的區(qū)別。F1/F4 的 DMA 請求是固定的比如 SPI1_TX 永遠連在 DMA1 的某個通道上你照著參考手冊配置就行。而 H7 引入了 DMAMUXDMA 請求多路復(fù)用器外設(shè)的 DMA 請求可以映射到任意一個 DMA 流stream上通過 DMAMUX 寄存器來指定。CubeMX 生成代碼時這個映射關(guān)系是自動配置的但如果你手動移植老代碼就很容易漏掉這一步。錯誤的表現(xiàn)就是 DMA 配置函數(shù)返回HAL_OK但 DMA 從不會真正被觸發(fā)——因為 DMA 不知道自己該監(jiān)聽哪個外設(shè)的請求信號。用 CubeMX 配置時注意看 DMA Settings 標簽頁里 Request 這一列比如DMA1_Stream0, SPI1_TX, MemoryToPeripheral, High Priority這里的SPI1_TX就是 DMAMUX 的請求源。如果你看到 Request 顯示的是0或者空白那多半是手動修改代碼時把 DMAMUX 配置弄丟了。正確的做法是重新通過 CubeMX 生成初始化代碼或者手動補上__HAL_LINKDMA(hspi1, hdmatx, hdma_spi1_tx); hdma_spi1_tx.Init.Request DMA_REQUEST_SPI1_TX;這句hdma_spi1_tx.Init.Request DMA_REQUEST_SPI1_TX;在 H7 上是必須的沒有它 DMA 就不會響應(yīng) SPI 的請求。而如果你看 F4 的代碼這個字段很可能不存在或者不需要指定。這個差異是移植老代碼時最大的坑。4.2 從機模式下 DMA 傳輸?shù)谋举|(zhì)數(shù)據(jù)先填充、時鐘再移出理解了 DMAMUX 之后再來看從機 DMA 的完整數(shù)據(jù)流調(diào)用HAL_SPI_Transmit_DMA()后HAL 庫使能 SPI 的 TX DMA 請求SPI 外設(shè)的 TXFIFO 空時向 DMAMUX 發(fā)出 DMA 請求DMA 響應(yīng)請求從內(nèi)存讀取一個字節(jié)/半字/字寫入 SPI 的 TXDR 數(shù)據(jù)寄存器TXDR 的數(shù)據(jù)進入移位寄存器主機產(chǎn)生 SCK 時鐘移位寄存器按位移出到 MISO 引腳TXFIFO 空時再次觸發(fā) DMA 請求循環(huán)往復(fù)注意第 2 步和第 5 步是異步的。從機側(cè) DMA 填充數(shù)據(jù)的速度可以比主機時鐘快只要 TXFIFO 里有數(shù)據(jù)SCK 來了就能移出去如果 TXFIFO 為空SCK 來了移出去的就是 0x00 或者 0xFF取決于移位寄存器里殘留的數(shù)據(jù)。在這個流程中有一個關(guān)鍵點經(jīng)常被忽視SPI 從機使能 DMA 發(fā)送之前TXFIFO 必須是空的否則老的殘留數(shù)據(jù)會被先發(fā)出去。H7 的 SPI 在每次傳輸完成后TXFIFO 里可能殘留上一幀的最后幾個字節(jié)。如果你不清理就直接開始下一次 DMA 發(fā)送開頭幾個字節(jié)可能是殘留數(shù)據(jù)然后才是新數(shù)據(jù)。排查時可以通過讀SPI_SR的狀態(tài)位來確認比如RXWNE、TXC這些位。更簡單粗暴的方法是每次發(fā)送前調(diào)用__HAL_SPI_CLEAR_OVRFLAG(hspi1)清除溢出標志同時確認TXC被置位表示上次傳輸已完成。4.3 FIFO 閾值與 DMA 請求觸發(fā)時機H7 的 SPI 內(nèi)部有一個 16 字節(jié)或 8 字具體看數(shù)據(jù)寬度的 TXFIFO。DMA 請求的觸發(fā)策略與 FIFO 閾值相關(guān)。CubeMX 默認配置下閾值為 1 字節(jié)這意味著 FIFO 空出一個字節(jié)的位置就會觸發(fā)一次 DMA 請求。這個配置在大多數(shù)場景下沒問題。但如果你傳輸?shù)臄?shù)據(jù)寬度是 16bit 或 32bit或者打開了 DMA 的突發(fā)模式FIFO 閾值和突發(fā)長度的配合就容易出岔子。比如 DMA 配置為突發(fā) 4 次每次搬 1 字節(jié)但 FIFO 閾值卻設(shè)置為 4 字節(jié)那 DMA 請求就永遠不會被觸發(fā)因為 FIFO 空出來的位置始終不夠 4 字節(jié)。這個問題的典型現(xiàn)象是第一次 DMA 傳輸可能正常之后的傳輸就卡死或者數(shù)據(jù)錯亂。因為第一次傳輸時 FIFO 是空的足夠觸發(fā)突發(fā)條件傳輸結(jié)束之后 FIFO 殘留了部分數(shù)據(jù)下一次閾值判斷就不滿足了。解決辦法是把 DMA 的 FIFO 設(shè)置為 Disable或者把突發(fā)模式改為 Single。對于從機場景我測試下來最穩(wěn)定的配置是DMA 模式 Normal、FIFO Disable、MemDataAlignment Byte、PeriphDataAlignment Byte。這種配置雖然效率不是最高但兼容性最好出問題的概率最小。4.4 一個完整可用的從機 DMA 初始化代碼下面給出一份精簡但完整的配置代碼包含了上面提到的關(guān)鍵處理。CubeMX 生成的初始化用戶代碼區(qū)可以照這個思路調(diào)整/* SPI1 從機配置 */ hspi1.Instance SPI1; hspi1.Init.Mode SPI_MODE_SLAVE; hspi1.Init.Direction SPI_DIRECTION_2LINES; hspi1.Init.DataSize SPI_DATASIZE_8BIT; hspi1.Init.CLKPolarity SPI_POLARITY_LOW; hspi1.Init.CLKPhase SPI_PHASE_1EDGE; hspi1.Init.NSS SPI_NSS_SOFT; hspi1.Init.FirstBit SPI_FIRSTBIT_MSB; hspi1.Init.TIMode SPI_TIMODE_DISABLE; hspi1.Init.CRCCalculation SPI_CRCCALCULATION_DISABLE; hspi1.Init.CRCPolynomial 7; hspi1.Init.CRCLength SPI_CRC_LENGTH_8BIT; hspi1.Init.NSSPMode SPI_NSS_PULSE_DISABLE; HAL_SPI_Init(hspi1); /* DMA 發(fā)送配置 */ hdma_spi1_tx.Instance DMA1_Stream0; hdma_spi1_tx.Init.Request DMA_REQUEST_SPI1_TX; hdma_spi1_tx.Init.Direction DMA_MEMORY_TO_PERIPH; hdma_spi1_tx.Init.PeriphInc DMA_PINC_DISABLE; hdma_spi1_tx.Init.MemInc DMA_MINC_ENABLE; hdma_spi1_tx.Init.PeriphDataAlignment DMA_PDATAALIGN_BYTE; hdma_spi1_tx.Init.MemDataAlignment DMA_MDATAALIGN_BYTE; hdma_spi1_tx.Init.Mode DMA_NORMAL; hdma_spi1_tx.Init.Priority DMA_PRIORITY_HIGH; hdma_spi1_tx.Init.FIFOMode DMA_FIFOMODE_DISABLE; HAL_DMA_Init(hdma_spi1_tx); __HAL_LINKDMA(hspi1, hdmatx, hdma_spi1_tx); /* 使能 SPI 內(nèi)部從機選擇軟件 NSS 必須 */ SET_BIT(hspi1.Instance-CFG1, SPI_CFG1_SSI); /* 啟動 NVIC 中斷 */ HAL_NVIC_SetPriority(SPI1_IRQn, 5, 0); HAL_NVIC_EnableIRQ(SPI1_IRQn); HAL_NVIC_SetPriority(DMA1_Stream0_IRQn, 5, 0); HAL_NVIC_EnableIRQ(DMA1_Stream0_IRQn);發(fā)送數(shù)據(jù)時調(diào)用HAL_SPI_Transmit_DMA(hspi1, txBuffer, bufferLen);如果使用了環(huán)形緩沖區(qū)持續(xù)發(fā)送可以選擇HAL_SPI_Transmit_DMA在傳輸完成后再次調(diào)用或者在HAL_SPI_TxCpltCallback里重新啟動下一次傳輸。這里的注意事項是在回調(diào)里重新調(diào)用前一定要確認上一次傳輸已經(jīng)完全結(jié)束否則會觸發(fā) HAL 庫的狀態(tài)機斷言。5. HAL 庫狀態(tài)機與回調(diào)機制程序“看起來在跑”其實啥也沒干5.1 HAL_SPI_Transmit_DMA 內(nèi)部到底做了什么很多人在排查 DMA 問題時忽略了 HAL 庫本身的狀態(tài)機設(shè)計。HAL_SPI_Transmit_DMA()并不是簡單地“把地址和長度塞給 DMA”它內(nèi)部做了一堆狀態(tài)判斷if (hspi-State HAL_SPI_STATE_READY) { // 設(shè)置狀態(tài)為 BUSY_TX // 配置外設(shè)地址、內(nèi)存地址、數(shù)據(jù)長度 // 使能 SPI 的 TX DMA 請求 // 使能外設(shè)中斷 } else { return HAL_BUSY; }如果 SPI 的狀態(tài)機不在HAL_SPI_STATE_READY函數(shù)會直接返回HAL_BUSY而不會啟動任何 DMA 傳輸。常見的導(dǎo)致狀態(tài)機卡住的原因包括上一次 DMA 傳輸沒有正常完成hspi-State還停在HAL_SPI_STATE_BUSY_TX某個回調(diào)返回了錯誤代碼導(dǎo)致 HAL 庫認為傳輸失敗SPI 發(fā)生 OVR溢出錯誤后沒有調(diào)用HAL_SPI_ErrorCallback狀態(tài)機沒有被重置更隱蔽的情況是你調(diào)用了HAL_SPI_Transmit_DMA()返回HAL_OK但因為之前清除狀態(tài)時沒有正確復(fù)位hspi-ErrorCode導(dǎo)致后續(xù) HAL 庫內(nèi)部檢查到錯誤標志自動中止了 DMA。這種問題從外部看你只會看到“DMA 啟動了但沒有數(shù)據(jù)”查起來特別費勁。5.2 恢復(fù) HAL 狀態(tài)機的標準操作如果你懷疑狀態(tài)機卡住最簡單的辦法是在啟動 DMA 之前手動復(fù)位狀態(tài)hspi1.State HAL_SPI_STATE_READY; hspi1.ErrorCode HAL_SPI_ERROR_NONE;但這個方法只能作為調(diào)試時的臨時手段正式代碼里不建議頻繁手動操作狀態(tài)機字段因為 HAL 庫內(nèi)部有可能有自己的緩存狀態(tài)手動修改容易引起其他字段不一致。更穩(wěn)妥的辦法是調(diào)用HAL_SPI_Abort(hspi1)來中止當前傳輸并復(fù)位狀態(tài)機。注意HAL_SPI_Abort()是阻塞式的如果 DMA 正在傳輸大塊數(shù)據(jù)它會等待 DMA 停止完成才返回。在中斷服務(wù)函數(shù)里調(diào)用要格外小心不要造成死鎖。5.3 中斷優(yōu)先級與回調(diào)執(zhí)行時機另一個容易出問題的點是中斷優(yōu)先級配置。H7 的 NVIC 中斷分組默認是 4全部用于搶占優(yōu)先級SPI 中斷和 DMA 中斷的優(yōu)先級需要合理設(shè)置。如果 DMA 中斷優(yōu)先級設(shè)置得太低而主循環(huán)里的某個高優(yōu)先級中斷頻繁打斷 DMA 傳輸就可能導(dǎo)致 DMA 的傳輸完成中斷延遲響應(yīng)進而影響 HAL 庫狀態(tài)機的更新。從機模式下還有一點特殊SPI 的 RX 溢出中斷OVR和 TX 完成中斷TXC在從機模式下觸發(fā)時機和主機不同。主機是主動控制時鐘的中斷只在特定時刻出現(xiàn)從機是被動響應(yīng)的主機隨時可能發(fā)起時鐘所以中斷有可能在任何時刻觸發(fā)。如果中斷服務(wù)函數(shù)處理時間過長或者優(yōu)先級配置不當就可能丟失中斷事件。我的建議是從機場景下SPI 全局中斷優(yōu)先級不低于 DMA 中斷優(yōu)先級保證事件按順序處理。比如兩個都設(shè)為 5同優(yōu)先級下按自然懸空順序處理也可以接受。但不要把 SPI 中斷優(yōu)先級設(shè)得比 DMA 低否則 DMA 完成后 SPI 的完成標志沒人處理HAL 庫狀態(tài)機就會一直卡在 BUSY。5.4 關(guān)于HAL_SPI_TxCpltCallback的一個容易忽略的細節(jié)很多人在這個回調(diào)里寫了發(fā)送完成后的處理邏輯比如翻轉(zhuǎn)一個 GPIO 指示燈。但注意一個細節(jié)從機模式下TXCTransfer Complete標志是在“SPI 外設(shè)的移位寄存器發(fā)送完畢”時設(shè)置的而不是在“數(shù)據(jù)從內(nèi)存搬運到 SPI 外設(shè)”時設(shè)置的。也就是說即使你看到HAL_SPI_TxCpltCallback被調(diào)用了也不代表 SPI 時鐘已經(jīng)全部結(jié)束——在從機模式下主機的時鐘可能還在繼續(xù)。如果這時候你在回調(diào)里修改了發(fā)送緩沖區(qū)的內(nèi)容可能會影響下一幀數(shù)據(jù)。這個問題在調(diào)試時有一個很典型的表現(xiàn)主機連續(xù)讀多個字節(jié)從機用 DMA 發(fā)送固定緩沖區(qū)前幾個字節(jié)是對的后面的字節(jié)全是 FF。原因就是從機在回調(diào)里提前修改了發(fā)送緩沖區(qū)導(dǎo)致后續(xù) DMA 搬運到的數(shù)據(jù)已經(jīng)被改掉了。解決辦法如果需要更新發(fā)送內(nèi)容只在回調(diào)里設(shè)置一個標志位然后在主循環(huán)里再更新緩沖區(qū)不要直接在回調(diào)里操作。6. 從現(xiàn)象到結(jié)論的完整排查清單與故障速查表6.1 一次完整的診斷走查流程結(jié)合我這幾天排查 H753ZI SPI 從機 DMA 的經(jīng)驗整理一個可以直接照著做的排查清單。這個清單的順序是我實踐后確定的從“看燈”到“摳寄存器”都有覆蓋每一步都有明確的結(jié)論判定不會讓你白干。第一步物理層確認。用示波器或邏輯分析儀同時抓 SCK、CS、MISO 三個信號。觀察主機發(fā)起讀操作時從機的 CS 是否被拉低、SCK 是否持續(xù)翻轉(zhuǎn)、MISO 是否有對應(yīng)的數(shù)據(jù)輸出。如果 MISO 完全不動直接跳轉(zhuǎn)到第三步如果 MISO 有數(shù)據(jù)但主機讀回來的不對跳轉(zhuǎn)到第二步。第二步配置參數(shù)核對。確認主從機的 CPOL、CPHA 一致數(shù)據(jù)幀寬度一致MSB/LSB 順序一致。這兩組參數(shù)只要有一個不匹配就會導(dǎo)致數(shù)據(jù)錯位或者全 FF?？梢越⒁粋€簡單的測試用例從機發(fā)送固定序列0x01 0x02 0x03 0x04...主機讀回來對比能快速定位是位序問題還是電平時序問題。第三步從機選通信號確認。確認 NSS 模式是硬件還是軟件硬件模式檢查接線是否連接正確、主機是否配置了推挽輸出軟件模式檢查CFG1寄存器中的SSI位是否置位。這一步排查完后MISO 應(yīng)該有動作了。第四步DMA 配置確認。打開dma.c或 CubeMX 的 DMA 設(shè)置界面確認 DMA 請求源選擇的是SPIx_TXH7 必須方向是MemoryToPeripheral外設(shè)地址是 SPI 的 TXDR 寄存器。如果這些都對在HAL_SPI_Transmit_DMA()調(diào)用處打斷點觀察hspi-State是否成功從 READY 轉(zhuǎn)為 BUSY_TX。第五步測試“阻塞模式發(fā)數(shù)據(jù)”與“DMA 模式發(fā)數(shù)據(jù)”的差異。如果阻塞模式能正常發(fā)數(shù)據(jù)、DMA 模式全是 FF那問題就鎖定在 DMA 與 SPI 外設(shè)的交互上。這時候可以檢查 DMA 傳輸?shù)挠嫈?shù)寄存器LIFCR、NDTR 等確認 DMA 是否真的把數(shù)據(jù)傳輸?shù)搅?SPI 外設(shè)。第六步禁用所有無關(guān)的中斷優(yōu)先級和 FreeRTOS 調(diào)度使用最簡環(huán)境測試。很多從機問題在裸機環(huán)境下能復(fù)現(xiàn)但加上 RTOS 后行為就變了原因往往是中斷優(yōu)先級和調(diào)度時序發(fā)生了變化。用最簡環(huán)境把問題復(fù)現(xiàn)出來再逐步加入軟件組件能更準確地定位。6.2 這篇文章踩過的坑問題現(xiàn)象、原因、解決方式速查表問題現(xiàn)象根本原因解決方式/調(diào)試要點MISO 完全無翻轉(zhuǎn)主機讀全 FF軟件 NSS 模式下SSI位未置位確認SPI_CFG1_SSI為 1硬件 NSS 模式下檢查連線MISO 無翻轉(zhuǎn)但寄存器配置看似正常DMA 請求源未配置為SPIx_TX檢查hdma.Init.Request確認是 DMAMUX 的正確請求 IDMISO 有翻轉(zhuǎn)但數(shù)據(jù)是錯的CPOL/CPHA 主從不匹配或位序不對主從機參數(shù)逐項對照用0x01 0x02序列測試定位是位序還是電平時序問題前幾個字節(jié)正確后面全是 FF發(fā)送緩沖區(qū)在HAL_SPI_TxCpltCallback里被提前修改回調(diào)中只置標志位數(shù)據(jù)更新移到主循環(huán)主機讀到的不是 FF而是全 0x00MISO 被下拉從機未驅(qū)動總線和全 FF 屬于同類問題只是外部引腳電平不同DMA 第一次傳輸正常后續(xù)不穩(wěn)定FIFO 閾值與突發(fā)傳輸長度不匹配關(guān)閉 DMA FIFO或把突發(fā)模式改為 SingleHAL_SPI_Transmit_DMA 返回 HAL_BUSYSPI 狀態(tài)機卡在 BUSY_TX 未恢復(fù)調(diào)用HAL_SPI_Abort()復(fù)位狀態(tài)機檢查錯誤標志并清除FreeRTOS 環(huán)境下程序卡死DMA 中斷優(yōu)先級設(shè)置過高導(dǎo)致調(diào)度異常合理設(shè)置 NVIC 優(yōu)先級SPI 與 DMA 中斷優(yōu)先級不差兩級以上主機發(fā)時鐘但從機沒數(shù)據(jù)從機 TXFIFO 為空沒有數(shù)據(jù)可移出確認HAL_SPI_Transmit_DMA()已經(jīng)調(diào)用檢查 DMA 計數(shù)是否變化數(shù)據(jù)里有偶發(fā)的錯亂字節(jié)從機被非預(yù)期地重新選通或 NSS 抖動檢查 CS 線上是否有毛刺硬件上可適當加濾波電容6.3 從“全是 FF”到“調(diào)試工具怎么選”調(diào)試 SPI 從機 DMA 這類問題工具選擇直接決定排查速度。我這次用到的工具按優(yōu)先級排列示波器或邏輯分析儀必須要有而且?guī)挷恍枰芨?00MHz 就夠用SPI 協(xié)議分析功能有最好沒有的話用 GPIO 翻轉(zhuǎn)來輔助判斷時序也行。示波器的用法有三個關(guān)鍵點一是抓圖時把 SCK、CS、MISO 三個通道同時打開這樣能整體判斷從機的響應(yīng)時序二是觸發(fā)方式設(shè)置為 CS 下降沿觸發(fā)而不是 SCK 觸發(fā)因為 CS 標志一次傳輸?shù)拈_始三是觀察 MISO 數(shù)據(jù)時要注意從機的數(shù)據(jù)是“在 SCK 上升沿或者下降沿采樣”的要在正確的沿上判斷數(shù)據(jù)電平。如果沒有示波器邏輯分析儀也能湊合但要注意采樣率不能太低。SPI 時鐘 4MHz 時邏輯分析儀的采樣率至少要 20MHz 以上越低越容易在邊沿處采到不確定電平造成誤判。6.4 移植中容易出問題的 GPIO 配置最后提一個很多人會忽略的細節(jié)GPIO 模式配置。SPI 從機的 MISO 引腳必須配置為復(fù)用功能推挽輸出AF Push-Pull而不是開漏輸出。這一點在 Nucleo 板上通常 CubeMX 已經(jīng)幫你配好了但如果你手動從 F1 代碼移植過來就容易把 MISO 配成開漏——因為 F1 的 SPI 從機在某些配置下 MISO 是開漏輸出的H7 的 GPIO 電氣特性不一樣直接照搬就會導(dǎo)致 MISO 電平驅(qū)動能力不足主機讀到的電平異常。另外從機的 SCK 和 NSS 引腳要配置為上拉輸入或者帶上拉的復(fù)用輸入避免引腳懸空時電平抖動導(dǎo)致誤觸發(fā)。CS 引腳如果有長線連接建議在從機端加一個 10kΩ 左右的上拉電阻確保主機未拉低時 CS 保持高電平從機不會被意外選中。7. 寫在最后SPI 從機調(diào)試永遠先問“總線上的電平是誰產(chǎn)生的”這次排查 H753ZI 從機 DMA 全 FF 問題最大的心得可以用一句話總結(jié)調(diào)試 SPI 從機永遠先問“總線上的電平是誰產(chǎn)生的”而不是先問“我的代碼哪里錯了”。0xFF 本身不是錯誤它是總線空閑時 MISO 的自然狀態(tài)真正的問題是你期望從機去驅(qū)動總線但總線沒有被驅(qū)動。所以每當你看到數(shù)據(jù)全是 0xFF先別急著查 DMA 參數(shù)和 HAL 函數(shù)按照“物理層有沒有動作 - 從機選通有沒有生效 - SPI 參數(shù)是否匹配 - DMA 是否真的搬運了數(shù)據(jù) - HAL 狀態(tài)機是否正?！边@個順序逐一排查大部分問題都能在兩小時內(nèi)定位。從技術(shù)演進的角度看H7 的 DMAMUX 架構(gòu)讓 SPI 與 DMA 的搭配更加靈活但也帶來了新的配置門檻。如果你是從 F1/F4 老工程遷移過來的建議先完全刪除 CubeMX 生成的 DMA 配置重新按 H7 的方式生成一次不要手動改老代碼這樣能避免 DMAMUX 請求映射丟失這類隱蔽問題。另外調(diào)試這類問題的時候建議把 CubeMX 的配置文件、主機的 SPI 時序圖、從機的初始化代碼三份材料放到一起對照著看。很多時候主機和從機兩邊各自都覺得自己的配置是對的但就是參數(shù)沒有對齊把關(guān)鍵參數(shù)列成一張表逐項核對比一個人悶頭查快得多。最后再分享一個小技巧在HAL_SPI_Transmit_DMA()啟動之后、數(shù)據(jù)發(fā)送完成之前的這段窗口期從SPI_SR寄存器讀一下TXNP位。如果這個位為 0說明 SPI 外設(shè)正在等待數(shù)據(jù)被移出如果為 1說明 TXFIFO 還有數(shù)據(jù)沒發(fā)完。配合調(diào)試器實時監(jiān)視這個寄存器能非常直觀地看到 DMA 和 SPI 外設(shè)之間的配合是否正常。有時候看到的變化趨勢比任何日志都好用。